Glossar / Mining und Konsens
nBits
Auch bekannt als Compact target, Bits.
- Was ist nBits?
- nBits ist das Vier-Byte-Feld in jedem Blockheader, das das Mining-Ziel in eine kompakte, an Gleitkommazahlen angelehnte Kodierung aus einem Exponenten und einem Drei-Byte-Koeffizienten packt.
Bitcoin braucht ein Ziel mit 256 Bit in einem Header, der dafür keine 32 Byte übrig hat, deshalb speichert es eine gerundete Version in vier Byte. Das erste Byte ist ein Exponent, die übrigen drei sind ein Koeffizient, und das Ziel ist der Koeffizient multipliziert mit 256 hoch dem Exponenten minus drei. Jeder Node berechnet den Wert neu, den er erwartet, deshalb wird ein Header, der ein leichteres Ziel angibt als die Regeln erlauben, sofort abgelehnt.
So funktioniert es
nBits wird als ein Exponenten-Byte gefolgt von einem Drei-Byte-Koeffizienten gelesen, und beide werden zu einer vollständigen Zahl mit 256 Bit zusammengesetzt.
Nehmen Sie den Wert des Genesis-Blocks, 0x1d00ffff. Der Exponent ist 0x1d, also 29, und der Koeffizient ist 0x00ffff, also 65.535. Das Ziel ist daher 65.535 multipliziert mit 2 hoch 208, eine Zahl, die als acht hexadezimale Nullen geschrieben wird, dann ffff, dann Nullen bis 64 Stellen gefüllt sind. Das ist das leichteste Ziel, das das Mainnet zulässt, und es ist die Definition der Schwierigkeit 1.
Zwei Eigenheiten überraschen viele. Die erste ist die Genauigkeit. Ein Koeffizient mit nur 24 Bit kann keine beliebige Zahl mit 256 Bit ausdrücken, deshalb ist das kodierte Ziel immer ein gerundeter Wert, und ein Hin und Zurück vom Ziel zu nBits und wieder zurück liefert nicht immer den Ausgangswert. Die zweite ist das Vorzeichenbit. Ist das höchste Bit des Koeffizienten gesetzt, wird der Wert als negativ behandelt, deshalb verschieben Encoder den Koeffizienten um ein Byte nach unten und erhöhen den Exponenten zum Ausgleich. Deshalb liest sich der Genesis-Wert als 0x1d00ffff und nicht als das naheliegendere 0x1cffff00, und deshalb ist ein führendes Null-Byte im Koeffizienten normal und kein Fehler.
Im serialisierten Header steht das Feld an Byte-Offset 72 und wird Little-Endian geschrieben, deshalb erscheinen diese vier Byte auf der Platte und auf der Leitung als ff ff 00 1d.
Wo es auftaucht
nBits tritt unter mehreren verschiedenen Namen auf, und daher rührt der größte Teil der Verwirrung um das Feld.
Block-Explorer bezeichnen es als "bits" und drucken den Hex-Wert neben einer lesbareren Schwierigkeitszahl. Der RPC-Aufruf getblock von Bitcoin Core gibt es als "bits" zurück, und getblocktemplate übergibt es an Mining-Software als die Anforderung, die ein Kandidaten-Header übertreffen muss. Im Quellcode ist es das Mitglied nBits von CBlockHeader, konvertiert durch arith_uint256::SetCompact und GetCompact. Mining-Pools zeigen es selten überhaupt an: Stratum liefert dieselben vier Byte an die Maschinen innerhalb einer Job-Benachrichtigung, und die Firmware muss nie darüber nachdenken, was sie bedeuten.
Das Feld ändert sich zudem nach einem Zeitplan und nicht fortlaufend. Es ist für ein ganzes Fenster von 2.016 Blöcken fest und nimmt erst bei einem Retarget einen neuen Wert an, deshalb tragen zwei eine Stunde auseinander geminte Blöcke ein identisches nBits-Feld, sofern nicht ein Retarget dazwischen lag.
nBits vs. Zielschwelle
nBits ist die Kodierung; die Zielschwelle ist die Zahl, die es kodiert. Ein Node vergleicht einen Header-Hash nie direkt mit nBits. Er entfaltet die vier Byte zuerst zu einem vollständigen Ziel mit 256 Bit und prüft dann, ob der Hash auf oder unter diesem Wert liegt. nBits selbst als das Ziel zu behandeln, ist im Gespräch in Ordnung und im Code falsch, weil zwei nBits-Werte, die eine einzige Einheit auseinanderliegen, zu Zielen dekodieren, die sich um eine enorme absolute Menge unterscheiden.