Überlegen wir mal wie man den Rundungsfehler mit in die Rechnungen einbeziehen kann.
Runden bedeutet der wahre Wert ist entweder etwas größer oder etwas kleiner, das wird uns eine untere und obere Grenze geben.
D.h. Rund 3,4 bedeutet es kann real zwischen 3,351 oder 3,449 schwanken. Ich werde vereinfacht die letzte Kommastelle +/-1 rechnen.
Wir wollen berechnen:
BlockbelohnungWährungX*(MeineHashleistungfürdieWährungX / GesamthashleistungfürdieWährungX) = erwartete Blockausschüttung
Exkurs: 1GH/s = 1/1000 TH/s oder 1 TH/s = 1000 GH/s
Jetzt wird es etwas kniffelig, die beiden Werte im Bruch hinten enthalten die gerundeten Werte, wollen wir also das durch Rundungsfehler denkbare Minimum der erwarteten Blockausschüttung berechnen müssen wir also das Minimum des Nenners nehmen (MeineHashleistungfürdieWährungX) und durch das Maximum des Zählers (GesamthashleistungfürdieWährungX) teilen
Fiktives Beispiel: MeineHashleistungfürdieWährungX = 3,4 => minimum 3,3 maximum 3,5
Ähnlich wird das durch Rundungsfehler denkbare Maximum der erwarteten Blockausschüttung berechnet: das Maximum des Nenners (MeineHashleistungfürdieWährungX) wird durch das Minimum des Zählers (GesamthashleistungfürdieWährungX) geteilt
So ergeben sich die beiden Grenzen, untere Grenze:
BlockbelohnungWährungX*(minimumvonMeineHashleistungfürdieWährungX / maximumvonGesamthashleistungfürdieWährungX) = minimum von erwartete Blockausschüttung
und die obere Grenze:
BlockbelohnungWährungX*(maximumvonMeineHashleistungfürdieWährungX / minimumvonGesamthashleistungfürdieWährungX) = maximum von erwartete Blockausschüttung
Das heißt die Ausschüttung muss in dem Bereich zwischen untere bis obere Grenze liegen. Falls nicht liegt es nicht am Rundungsfehler.
Übrigens ein Mathematiker der in der Fehlerrechnung fit ist könnte euch jetzt noch beweisen das genau diese Überlegungen und Rundungsfehler höchstens für eine Schwankung der erwarteten Blockausschüttung an Nachkommastelle y führen kann. Bei RBC wäre das bei mir die 6. Nachkommastelle, also definitiv nicht die die den Braten fett machen.
Das andere Argument soll wohl sein das die Hashrates ja jederzeit geändert werden können, bzw das es permanent kleine Änderungen gibt. Die Anzeige wird jedoch nur alle 5min aktualisiert, jedoch zur Blockausschüttung 'in Echtzeit' berechnet.
Da wäre mein Ansatz das ich mir einfach die Hashrates über einen Zeitraum von 10minuten notiere, in der Mitte liegt eine Blockausschüttung.
So sehe ich ob sich die Hashrate geändert hat, falls ja muss ich das wiederholen bis die Werte gleichbleiben.
Habt dabei auch einen Blick auf eure Hashrate, falls sich da was ändern kann. Die muss natürlich auch gleich bleiben, wenn wir das als Fehlerquelle ausschließen wollen.
Die Werte die ich rausbekommen habe waren recht ähnlich wie hier, die Stelle wo sich bei mir untere und obere Grenze unterscheiden habe ich mal Fett markiert.
Ich hätte irgendwie die Hoffnung gehabt das die untere Grenze kleiner ist als mein Blockanteil den ich bekomme und die obere drüber. Aber sie sind beide drüber und ein ganzes Stück weg von der Ausschüttung. Die Hashrates waren über min. 15min stabil als ich mir die Zahlen gezogen habe.
Habe ich irgendwas falsch berechnet? Oder habe ich irgendwo einen Logikfehler gemacht?
€: Unter Mediadaten steht übrigens 370,86 TH Gesamthash im Header steht: Netzwerk-Power: 348,56 TH/s. Find ich auch etwas komisch
Runden bedeutet der wahre Wert ist entweder etwas größer oder etwas kleiner, das wird uns eine untere und obere Grenze geben.
D.h. Rund 3,4 bedeutet es kann real zwischen 3,351 oder 3,449 schwanken. Ich werde vereinfacht die letzte Kommastelle +/-1 rechnen.
Wir wollen berechnen:
BlockbelohnungWährungX*(MeineHashleistungfürdieWährungX / GesamthashleistungfürdieWährungX) = erwartete Blockausschüttung
Exkurs: 1GH/s = 1/1000 TH/s oder 1 TH/s = 1000 GH/s
Jetzt wird es etwas kniffelig, die beiden Werte im Bruch hinten enthalten die gerundeten Werte, wollen wir also das durch Rundungsfehler denkbare Minimum der erwarteten Blockausschüttung berechnen müssen wir also das Minimum des Nenners nehmen (MeineHashleistungfürdieWährungX) und durch das Maximum des Zählers (GesamthashleistungfürdieWährungX) teilen
Fiktives Beispiel: MeineHashleistungfürdieWährungX = 3,4 => minimum 3,3 maximum 3,5
Ähnlich wird das durch Rundungsfehler denkbare Maximum der erwarteten Blockausschüttung berechnet: das Maximum des Nenners (MeineHashleistungfürdieWährungX) wird durch das Minimum des Zählers (GesamthashleistungfürdieWährungX) geteilt
So ergeben sich die beiden Grenzen, untere Grenze:
BlockbelohnungWährungX*(minimumvonMeineHashleistungfürdieWährungX / maximumvonGesamthashleistungfürdieWährungX) = minimum von erwartete Blockausschüttung
und die obere Grenze:
BlockbelohnungWährungX*(maximumvonMeineHashleistungfürdieWährungX / minimumvonGesamthashleistungfürdieWährungX) = maximum von erwartete Blockausschüttung
Das heißt die Ausschüttung muss in dem Bereich zwischen untere bis obere Grenze liegen. Falls nicht liegt es nicht am Rundungsfehler.
Übrigens ein Mathematiker der in der Fehlerrechnung fit ist könnte euch jetzt noch beweisen das genau diese Überlegungen und Rundungsfehler höchstens für eine Schwankung der erwarteten Blockausschüttung an Nachkommastelle y führen kann. Bei RBC wäre das bei mir die 6. Nachkommastelle, also definitiv nicht die die den Braten fett machen.
Das andere Argument soll wohl sein das die Hashrates ja jederzeit geändert werden können, bzw das es permanent kleine Änderungen gibt. Die Anzeige wird jedoch nur alle 5min aktualisiert, jedoch zur Blockausschüttung 'in Echtzeit' berechnet.
Da wäre mein Ansatz das ich mir einfach die Hashrates über einen Zeitraum von 10minuten notiere, in der Mitte liegt eine Blockausschüttung.
So sehe ich ob sich die Hashrate geändert hat, falls ja muss ich das wiederholen bis die Werte gleichbleiben.
Habt dabei auch einen Blick auf eure Hashrate, falls sich da was ändern kann. Die muss natürlich auch gleich bleiben, wenn wir das als Fehlerquelle ausschließen wollen.
Die Werte die ich rausbekommen habe waren recht ähnlich wie hier, die Stelle wo sich bei mir untere und obere Grenze unterscheiden habe ich mal Fett markiert.
Ich hätte irgendwie die Hoffnung gehabt das die untere Grenze kleiner ist als mein Blockanteil den ich bekomme und die obere drüber. Aber sie sind beide drüber und ein ganzes Stück weg von der Ausschüttung. Die Hashrates waren über min. 15min stabil als ich mir die Zahlen gezogen habe.
(04.07.2022, 17:40)Flobo schrieb: Berechnet:
0,0007253483
Dein Blockanteil
RBC: 0,00069496
Öhm ja o,O wtf
Rundungsfehler sollte nicht so groß ausfallen?
€: Rechenweg:
Blockanteil*(EigeneHashrate/RBCGesamtHashrate)
Habe ich irgendwas falsch berechnet? Oder habe ich irgendwo einen Logikfehler gemacht?
€: Unter Mediadaten steht übrigens 370,86 TH Gesamthash im Header steht: Netzwerk-Power: 348,56 TH/s. Find ich auch etwas komisch