IMHO kommen die Schwankungen beim 8-hour auch eher von den Minern, welche ihre Rigs nicht 24/7 laufen haben. Luck hin, Luck her, 8*7.5 Blöcke sind schon eine Menge Holz.
Diese Aussage hat mich zum Rechnen veranlasst.
Mein Bauchgefühl sagt mir nämlich, dass die Schwankungen im 8-Stunden-Durchschnitt
nicht auf den Tag-Nacht-Rhythmus der Miner zurückzuführen sind, sondern einfach nur durch die ganz normale Stichprobenvarianz hervorgerufen werden.
Die Mathematik zeigt, dass ich Recht hatte.
Dazu habe ich zuerst ein paar Variablen eingeführt:
Die nominale Hashrate, d.h. die Hashrate, die den Schwierigkeitsgrad bestimmt:
nominal_hashrateDie tatsächliche Hashrate zu einem bestimmten Zeitpunkt:
actual_hashrateDie Hashrate innerhalb einer Stichprobe:
sample_hashrateAnzahl Hashes in einer Stichprobe:
n_hashesDie nominale Blockrate, d.h. der Erwartungswert der Blockrate bei nominaler Hashrate:
nominal_blockrateAnzahl Blöcke in einer Stichprobe:
n_blocksDie Dauer der Stichprobe:
timeDie Wahrscheinlichkeit, mit einem Hash einen Block zu finden:
probabilityDer Erwartungswert einer Variablen:
expectation(_)Die Standardabweichung einer Variablen:
deviation(_)Die relative Standardabweichung einer Variablen:
relative_deviation(_)Durch das Bitcoin-Netzwerk ist diese Konstante festgelegt:
nominal_blockrate = 1/600
Allgemein gilt:
hashrate = n_hashes/time
blockrate = n_blocks/time
expectation(n_blocks) = n_hashes*probability
variance(n_blocks) = n_hashes*probability*(1 - probability)
deviation(_) = variance(_)^(1/2)
relative_deviation(_) = deviation(_)/expectation(_)
Daraus folgt:
probability = nominal_blockrate/nominal_hashrate
deviation(n_blocks) = (n_hashes*probability)^(1/2)*(1 - probability)^(1/2)
sample_hashrate = n_blocks/probability/time
Wenn man das alles zusammenpackt, ergibt sich:
relative_deviation(sample_hashrate) = (nominal_hashrate/actual_hashrate*600/time)^(1/2)*(1 - 1/600/nominal_hashrate)^(1/2)
Das ist leider eine sehr unhandliche Formel.
Deshalb wird gerundet:
relative_deviation(sample_hashrate) ~= (nominal_hashrate/actual_hashrate*600/time)^(1/2)
Das ist schon besser, aber immer noch unpraktisch, weil man die tatsächliche Hashrate ja gar nicht kennt.
In der Praxis wird man also einen geschätzten Wert eintragen.
Dabei bietet es sich an, die nominale Hashrate zu benutzen, weil sich das ganze dann nochmal vereinfachen lässt:
relative_deviation(sample_hashrate) ~= (600/time)^(1/2)
Das kann man dann auch als Prozentzahl schreiben:
relative_deviation(sample_hashrate) ~= (600/time)^(1/2)*100%
Das heißt:
Wenn man eine Stichprobe macht, die time Sekunden dauert, dann muss man damit rechnen, dass die gemessene Hashrate um (600/time)^(1/2)*100 Prozent von der tatsächlichen Hashrate abweicht.Ein paar Beispielwerte:
- Wenn man nur eine Stunde misst, dann beträgt die Ungenauigkeit der Messung etwa 41 Prozent. Das Ergebnis eignet sich also höchstens um die ungefähre Größenordnung der Hashrate abzuschätzen.
- Wenn man nur 8 Stunden misst, dann hat man immer noch eine Ungenauigkeit von etwa 14 Prozent.
- Bei einer eintägigen Messung ist es schon besser, dann hat man eine Ungenauigkeit von etwa 8.3 Prozent.
- Beim 3-Tage-Durchschnitt hat man eine Ungenauigkeit von etwa 4.8 Prozent.
- Der 7-Tage-Durchschnitt hat eine Ungenauigkeit von etwa 3.1 Prozent und ist wohl der beste Durchschnitt, den man berechnen kann, ohne das Zeitfenster unrealistisch groß zu machen.
Die 14% varianzbedingte Abweichung beim 8-Stunden-Durchschnitt kann man also nicht so einfach mit Minern begründen, die nachts ihre Geräte abstellen.
Das bedeutet auch, dass wenn es bei unserer Wette so knapp wird, dass es auf die 8% ankommt, dann können wir bis zum letzten Tag nicht wissen, wer gewonnen hat; es bleibt also spannend.
