Der Block-Header

Neugier

1. Wie kann sich eine Struktur von gerade einmal 80 Bytes kryptografisch auf Transaktionsdaten im Wert von Millionen Dollar festlegen?
2. Welche spezifischen Regeln verhindern, dass ein Miner das Zeitstempelfeld manipuliert, um einen Vorteil zu erlangen?
3. Warum kann ein Smartphone die Sicherheit des Bitcoin-Netzwerks überprüfen, ohne dessen gesamte Historie herunterzuladen?

Erkunden

1. Jeder Bitcoin-Block beginnt mit einem 80 Byte großen Header, gefolgt von einer Transaktionsliste variabler Länge. Während die Transaktionsliste pro Block bis zu etwa vier Millionen Bytes umfassen kann, wird nur der Header für das Proof-of-Work-Hashing und zur Identifizierung der Kette verwendet. Dieser extreme Größenunterschied bedeutet, dass der Header als kompakter Fingerabdruck für den gesamten Container dient, sodass Nodes Metadaten verarbeiten können, bevor sie die eigentlichen Daten herunterladen.
2. Das erste Feld ist „Version“ und umfasst vier Bytes. Ursprünglich sollte es Software-Iterationen nachverfolgen, heute enthält es Signalisierungsbits für Soft Forks gemäß BIP9. Miner setzen bestimmte Versionsnummern, um vor der Aktivierung ihre Unterstützung für neue Konsensregeln anzuzeigen. Dieses Feld ist außerdem mit Vorgaben verbunden; so verlangte BIP34 von Version-2-Blöcken, die Blockhöhe in das Script der Coinbase-Transaktion einzubetten – ein Beispiel dafür, wie der Header strukturelle Änderungen im gesamten Netzwerk durchsetzt.
3. Der „Previous Block Hash“ (32 Bytes) verbindet jeden Block mit seinem Vorgänger, indem er den doppelten SHA-256-Hash des vorherigen Headers enthält. Ändert man auch nur ein einziges Byte in einem früheren Block, ändert sich dessen Hash, wodurch die Verbindung zu allen nachfolgenden Blöcken unterbrochen wird. Diese Kette von Hashes sorgt dafür, dass historische Daten nicht verändert werden können, ohne die Rechenarbeit für alle folgenden Blöcke erneut zu leisten.
4. Die „Merkle-Root“ (32 Bytes) dient als kryptografischer Fingerabdruck für alle Transaktionen im Block. Sie entsteht durch rekursives Hashen von Paaren von Transaktions-IDs, bis nur noch ein einziger Wert übrig bleibt. Diese Struktur ermöglicht Simplified Payment Verification (vereinfachte Zahlungsverifizierung): Ein Light Client kann die Aufnahme einer bestimmten Transaktion allein mit dieser Root und einer kleinen Anzahl von Geschwister-Hashes nachweisen, statt den vollständigen Block herunterzuladen.
5. Der „Timestamp“ (4 Bytes) gibt die Erstellungszeit in Sekunden seit der Unix-Epoche an. Konsensregeln beschränken dieses Feld, um Manipulationen zu verhindern: Er muss größer sein als die Medianzeit der vorherigen 11 Blöcke, und ein Node lehnt ihn ab, wenn er mehr als zwei Stunden vor der eigenen Uhr dieses Nodes liegt (seit Bitcoin Core 27 gilt die Systemzeit des Nodes; frühere Versionen nutzten eine durch Peers angepasste Zeit). Diese Einschränkungen sorgen dafür, dass die Blockzeiten für die Berechnung der Schwierigkeit hinreichend genau bleiben, lassen aber wegen Verzögerungen bei der Ausbreitung im Netzwerk gewisse Abweichungen zu.
6. Die verbleibenden Felder sind „nBits“ (4 Bytes), eine kompakte Kodierung des Proof-of-Work-Ziels, sowie „nonce“ (4 Bytes), eine beliebige Zahl, die Miner variieren, um einen gültigen Hash zu finden. Da Header klein sind, benötigt das Speichern aller Header seit 2009 weniger als 100 MB Speicherplatz. Ein Light Client kann diese gesamte Historie vorhalten, alle Proof-of-Work-Bedingungen unabhängig überprüfen und, ohne die Transaktionen zu prüfen, davon ausgehen, dass die Kette mit der größten kumulierten Arbeit gültig ist.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Bitcoin Developer Reference: Block Headers
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 11
• BIP9: Version bits-based consensus signalling (GitHub)