Nonce

Anna betreibt ein Mining-Gerät, das einen neuen Block mit Transaktionen finden soll. Aus dem Header, einer kompakten Zusammenstellung von Blockdaten, berechnet es mit SHA-256 einen numerischen Fingerabdruck, den Hash. Bitcoin führt diese Berechnung zweimal aus, daher double-SHA-256. Liegt das Ergebnis über dem erlaubten Grenzwert, ändert das Gerät beispielsweise die Nonce von 10 auf 11 und versucht es erneut. Anna muss keine Zahlen erraten; das Gerät erledigt sehr viele Versuche automatisch. Eine höhere Nonce bedeutet dabei weder einen niedrigeren Hash noch einen Fortschritt zum Ziel. Genau derselbe Header ergibt immer denselben Hash. Ihn erneut zu berechnen eröffnet also keine neue Chance. [1] [2]

Für die Nonce sind vier Byte, also 32 Bit, vorgesehen. Darin lassen sich ganze Zahlen von 0 bis einschließlich 4 294 967 295 speichern: insgesamt 4 294 967 296 Möglichkeiten, kurz 2^32. Für Menschen klingt das gewaltig, ein spezialisiertes Mining-Gerät namens ASIC durchläuft diesen Bereich jedoch sehr schnell. Auch alle Werte auszuprobieren garantiert keinen Erfolg. Bleiben die übrigen Headerdaten gleich, wiederholt ein Neustart nur die bisherigen Ergebnisse. Deshalb muss die Software auch andere Header vorbereiten. [1] [5]

Eine Möglichkeit ist die Änderung der Extranonce. Der ähnliche Name kann täuschen: Sie ist kein weiteres Headerfeld, sondern steht in der Coinbase-Transaktion, der ersten Transaktion des Blocks, die die Mining-Belohnung zuweist. Eine Änderung verändert deren Kennung, die txid, und anschließend den Merkle Root, den gemeinsamen Fingerabdruck der Transaktionen im Header. Das Gerät erhält damit eine andere Eingabe. Es kann dieselben Nonce-Werte erneut verwenden, berechnet nun aber die Hashes anderer Header. Auch diese neuen 2^32 Möglichkeiten garantieren keinen Block. [2] [3]

Ein Blockexplorer zeigt vielleicht bei einem Block eine kleine und bei einem anderen eine große Nonce. Die Zahl allein verrät weder, wie schwer der Block zu finden war, noch ob er besser ist. Ein Full Node, ein Programm zur selbstständigen Prüfung von Blöcken und Transaktionen nach den Bitcoin-Regeln, hasht den gesamten Header und vergleicht das Ergebnis mit dem gültigen Target. Dessen kompakte Darstellung steht im Feld nBits. Entscheidend ist ein Hash kleiner oder gleich diesem Grenzwert, nicht die Größe der Nonce. Außerdem muss der Node die Transaktionen und die übrigen Regeln für gültige Blöcke prüfen. [1] [8]

Nonce begegnet Ihnen auch beim Signieren von Transaktionen. Dort kann es eine geheime Hilfszahl bezeichnen, fachlich einen Skalar, den das Verfahren zusammen mit dem Private Key verwendet, dem geheimen Schlüssel zur Freigabe von Ausgaben. Wird diese Zahl fälschlich für verschiedene Nachrichten wiederverwendet, kann der Schlüssel offengelegt werden. Die Mining-Nonce ist dagegen öffentlich; dieselbe Zahl darf in unterschiedlichen Headern vorkommen. Auch die öffentlichen Bestandteile einer Signatur sind nicht mit dieser geheimen Hilfszahl gleichzusetzen. Die Regeln des einen Einsatzes lassen sich daher nicht einfach auf den anderen übertragen. [9]

Wenn viele Geräte in einem Mining Pool zusammenarbeiten, sollten sie nicht alle dieselben Header hashen. Wiederholungen bringen keine neuen Versuche. Der Koordinator weist ihnen deshalb unterschiedliche Daten zu, etwa für Coinbase und Extranonce. Protokolle wie Stratum übertragen die Aufgaben; die angeschlossenen Mining-Einheiten heißen auch Workers. BIP23 beschreibt außerdem den optionalen Parameter noncerange zur Begrenzung des Nonce-Bereichs. Das heißt weder, dass jeder Pool ihn verwenden muss, noch dass ein Pool die Regeln für gültige Blöcke ändern darf. [4] [2]

Ein Merkle Tree verbindet die Fingerabdrücke der Transaktionen schrittweise zu einem gemeinsamen Fingerabdruck, dem Merkle Root. Die Kennung der Coinbase-Transaktion, ihre txid, geht als Blatt dieses Baums in die Berechnung ein. Eine geänderte Extranonce führt daher über eine neue txid zu einem neuen Merkle Root. Die übrigen Transaktionen und der Verweis auf den vorherigen Block können gleich bleiben, während ein anderer Header entsteht. Dabei wird kein bestätigter Block umgeschrieben, sondern ein neuer Blockentwurf verändert, für den noch ein gültiger Proof of Work gesucht wird. [1] [2]

Die Software kann weitere Header erzeugen, indem sie die Zeit nTime innerhalb erlaubter Grenzen oder zulässige Versionsbits verändert. Letzteres heißt version rolling. BIP320 schlägt die allgemeine Nutzung ausgewählter nVersion-Bits vor; der Vorschlag allein erlaubt keine beliebigen Änderungen aller Bits. Die Netzwerkregeln und die Regeln der zugewiesenen Mining-Aufgabe gelten weiterhin. Keine dieser Möglichkeiten umgeht die Anforderung, dass der resultierende Hash das gültige Target erfüllen muss. Der neuere BIP323 schlägt mehr Bits vor und hat weiterhin den Status Draft (Entwurf). [4] [5] [10]

Zum Lesen technischer Dokumentation hilft auch das Format. Der Header besteht aus 80 Byte: Version, Hash des vorherigen Blocks, Merkle Root, Zeit, nBits und der vier Byte langen Nonce. Die Nonce ist eine vorzeichenlose 32-Bit-Ganzzahl vom Typ uint32. Sie wird in little-endian-Reihenfolge gespeichert, mit dem niederwertigsten Byte zuerst. Eine Änderung nur der Nonce verändert den Header und seinen double-SHA-256-Hash, nicht die Transaktionsliste. Software benötigt diese exakte Darstellung; zum Verständnis des Minings muss man sie aber nicht von Hand zusammensetzen können. [1]

Fortgeschrittene können Bitcoin Core mit getblockheader und dem Hash eines bestimmten Blocks abfragen. Die ausführliche Standardausgabe enthält unter anderem nonce, bits und time. Steht der Parameter verbose auf false, liefert der Befehl die exakten 80 Headerbytes in hexadezimaler Form. Daraus lässt sich double-SHA-256 berechnen und das numerische Ergebnis mit dem gültigen Target vergleichen. Eine eigene Implementierung muss Bitcoins Byte-Reihenfolge beachten: Falsch umgedrehte Bytes verändern den Vergleich. Nur die Nonce in einem Explorer abzulesen ersetzt diese Prüfung nicht. [1] [6] [8]