Granularität der Bitcoin-Schwierigkeit

Die Schwierigkeit passt sich durch sehr granulare Prozentsätze an das Ziel für 10-Minuten-Blöcke an. Aber das Hinzufügen einer weiteren Null am Ende der Kette von Nullen aus der Header-Hash-Anforderung für einen gültigen Block würde die Schwierigkeit exponentiell erhöhen. Wie also zielt der Algorithmus nur durch die Verwendung von "Nullen" so genau auf die richtige Schwierigkeit?

Die Anzahl der führenden Nullen wird zu keinem Zeitpunkt berücksichtigt.

Antworten (2)

Die Schwierigkeit wird tatsächlich durch den Zielschwellenwert dargestellt, der im nBitsWert im Blockheader codiert ist. Wo die Schwierigkeit die menschenlesbare Darstellung darstellt ("wie oft müssen wir versuchen, eine Lösung zu finden"), definiert der Zielschwellenwert das Präfix, das ein Block unterschreiten muss, um gültig zu sein. Dies bedeutet, dass der als Zahl interpretierte 256-Bit-Block-Hash kleiner als der Zielschwellenwert sein muss. Obwohl nBitses sich nur um einen 4-Byte-Wert handelt, handelt es sich um eine komprimierte Darstellung einer 256-Bit-Zahl (32-Byte). Das erste Byte definiert den Exponenten, die restlichen drei Bytes ergeben eine 24-Bit-Mantisse für das Ziel.

Während dadurch der größte Teil der 32 Bytes im Zielschwellenwert nur noch aus Nullen besteht, kann die Schwierigkeit viel granularer angepasst werden, als nur führende Nullen hinzuzufügen.

David Harding hat die vollständigen Details in Wie wird der Zielabschnitt eines Blockheaders berechnet? .

Ok, ich verstehe, dass nBits eigentlich das Schwierigkeitsziel ist, das Teil des Headers ist. Ich verstehe immer noch nicht, was dies mit den führenden Nullen des Header-Hashs zu tun hat: Ich nehme an, ein vollständiger Knoten nimmt den Header, verdoppelt ihn und erhält einen Header-Hash, den er mit den nBits vergleicht, um zu sehen, ob er richtig ist. Richtig? Meine Frage ist, wie diese führenden Nullen granularer sind, um den richtigen Hash des Headers zu finden? Ich glaube, ich verpasse hier etwas..
Das Ersetzen einer führenden Eins durch eine führende Null verdoppelt die Schwierigkeit, während das Verringern eines 24-Bit-Präfixes um eine Zahl die Schwierigkeit nur um den Faktor 1,00000006 erhöht.
@zndtoshi Ich denke, Ihre Verwirrung rührt von der üblichen (aber falschen) Aussage her, dass es bei PoW um "die Anzahl der führenden Nullen" geht. Das ist es überhaupt nicht. Die PoW-Regel besagt, dass der Block-Hash, wenn er als Zahl interpretiert wird, unter dem Ziel liegen muss. nBitsist eine kompakte Codierung des Ziels.
OK. Das Ziel wird also von nBits angegeben (was sehr granular ist und das ist perfekt). Aber wenn das stimmt, warum brauchen Sie dann Nullen vor dem Header-Hash? Würden Sie nicht einfach das nBits-Ziel nehmen und überprüfen, ob der Header-Hash korrekt ist? Oder erhöhen die führenden Nullen des Hash-Headers die Schwierigkeit exponentiell?
Ich bin mir nicht sicher, ob ich die Frage verstehe. Das Ziel ist so niedrig, dass es für einen Header-Hash, um es zu unterschreiten, eine Reihe führender Nullen gibt. Wenn Sie Ihre Zahlen immer mit 9 Ziffern darstellen, aber eine unter zweitausend auswählen müssen, haben Sie immer fünf führende Nullen. Aber es ist immer noch ein Unterschied, ob Sie unter 2000 oder unter 1999 getroffen haben.

Als Ergänzung zur Antwort von @Murch möchte ich ein Beispiel aus Grokking Bitcoin zitieren :

Das Ziel wird in den Blockheader als 4 Bytes geschrieben, ABCD; das 32-Byte-Ziel wird als BCD× 2^(8*(A-3)) berechnet. Das ist BCDmit A-3null Bytes danach. Es ist so umständlich, weil wir in der Lage sein müssen, eine breite Palette von Zielen, 1–2^256, mit nur 32 Bit auszudrücken. Das Ziel in Qis Block [ein Zeichen im Buch] wird als geschrieben 1c926eb9, was 926eb9mit 25 Null-Bytes nach ( 1c–3 = 19, Hexadezimalcode für 25) bedeutet.