Sollte das Hash-Ziel von Bitcoin nicht eine Potenz von 2 sein?

Aus dem Whitepaper von Bitcoin habe ich entnommen, dass der Hash eines Blocks mit einer bestimmten Anzahl von Nullen beginnen muss. Und dass diese Anzahl von Nullen alle 2 Wochen angepasst wird. Folglich ist das Hash-Ziel eine Zweierpotenz.

Wenn für die Hash-Funktion eine zusätzliche Null erforderlich ist, wird das Hash-Ziel durch 2 geteilt.

In einer anderen Frage zum Austausch ( Wie wird die Schwierigkeit berechnet? ) scheint es, dass die Schwierigkeit mit Brüchen (z. B. 40%) multipliziert werden kann.

Bedeutet das, dass die Hash-Ziele nicht unbedingt Potenzen von 2 sind? Oder wird das Ziel auf die nächste Zweierpotenz gerundet?

Ich bin etwas verwirrt wegen deiner Frage. Warum sollte das Hash-Ziel ein Vielfaches von 2 sein? Führende Nullen sind 0000xxx und nicht xxx0000.
Die Annahme von @robert OP ist nicht korrekt, aber wenn dies der Fall wäre, wäre das Hash-Ziel eine Potenz von 16 (aufgrund der für Block-Hashes verwendeten hexadezimalen Codierung), nicht 2.
@chytrik Im Whitepaper (Abschnitt 4) sprechen sie speziell über Bits (Nullen oder Einsen), nicht Ziffern oder andere Hexadezimalzahlen: "[...] the block's hash the required zero bits" Wenn man also auf das Whitepaper verweisen soll, das Ziel wäre tatsächlich eine Potenz von 2.
@Fred aha! Das stimmt, das hatte ich vergessen, sorry. Bemerkenswert: David Harding hat eine Seite zusammengestellt, die einige „Whitepaper-Errata“ auflistet, die den Hash-Zielfehler „führende Nullbits“ enthält, siehe: gist.github.com/harding/…

Antworten (2)

Entgegen der landläufigen Meinung basiert das Ziel nicht wirklich auf der Anzahl der führenden Nullen. Dies ist eine große Vereinfachung, die verwendet wird, um die allgemeine Idee zu vermitteln, aber nicht wirklich, wie der Code funktioniert. Stattdessen ist das Ziel nur eine Zahl, die durch das Verhältnis zwischen der tatsächlichen Zeit zwischen den Blöcken und der erwarteten Zeit zwischen den Blöcken angepasst wird (mit einem Off-by-1-Fehler, der tatsächlich dazu führt, dass es nicht ganz wie erwartet funktioniert). Die Ziele sind also nicht unbedingt Vielfache von 2.

Es gibt eine zusätzliche Einschränkung – die neue Schwierigkeit kann nur mindestens ein Viertel und höchstens viermal höher sein als die alte Schwierigkeit. Der Multiplikator (das Verhältnis zwischen den Zeiten) muss also zwischen 1/4 und 4 liegen.

Also ist es im Grunde nirgendwo angegeben, außer im Code? Denn das Whitepaper spricht von der Anzahl der Nullen – ohne konkrete Umsetzungsdetails zu nennen …
@ Fred Ja. Das Whitepaper lässt viele spezifische Implementierungsdetails aus, die Sie nur durch Lesen des Codes erfahren können.

Wie Andrews Antwort zeigt, ist die „Anzahl der führenden Nullen“ nur eine Vereinfachung, also dachte ich, ich würde ein Beispiel geben, um dies konkreter zu veranschaulichen:

Block-Hashes werden normalerweise im Hex-Format dargestellt, das den Zeichensatz [0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f] verwendet. Aber der Einfachheit halber können wir einfach einen Zahlensatz zur Basis 10 verwenden [0,1,2,3,4,5,6,7,8,9], es gelten genau die gleichen Prinzipien.

Der Block-Hash ist die Ausgabe einer SHA256-Operation, also eine 256-Bit-Zahl, was eine sehr große Zahl ist. Das bedeutet, dass die Ausgabe der SHA256-Operation eine Zahl im Bereich von 0 bis 2^256 ist. Aber auch hier können wir der Einfachheit halber in unserem Beispiel einen viel kleineren Zahlenbereich betrachten, also verwenden wir stattdessen den Bereich 0 bis 1.000.000.

Stellen wir uns nun vor, das Hash-Ziel ist ≤500, sodass jede ansonsten gültige Blockeingabe, die eine Ausgabe von 0000500oder weniger ergibt, als gültiger Block betrachtet würde. ≤450Stellen wir uns auch vor, dass sich das Hash-Ziel für die nächste Schwierigkeitsperiode ändert , wodurch jede Ausgabe von 0000450oder weniger ein gültiger Block wird.

Beachten Sie, dass diese beiden Ziele "die gleiche Anzahl führender Nullen erfordern würden" , aber ein Block, der hasht, 0000475wäre nur in der früheren Schwierigkeitsperiode gültig und nicht in der späteren. Dies liegt daran, dass das Hash-Ziel eine bestimmte Zahl ist, die Anzahl der führenden Nullen ist nur eine Vereinfachung/ein grober Anhaltspunkt dafür.

Sehr schöne einfache Erklärung, danke. Erinnert mich irgendwie an arithmetische Codierung - behandeln Sie den gesamten 256-Bit-Hash als Float (Mantisse) zwischen [0.0 .. 1.0) und setzen Sie das Ziel auf einen Float-Wert ...