Hash des vorherigen Blockheaders

Jeder Block zeigt rückwärts, nie vorwärts. Weil der Verweis in den 80 Bytes steht, über die der Hash berechnet wird, verändert jede Änderung in einem alten Block dessen Hash und bricht jeden darauf aufgebauten Block, sodass das Rückgängigmachen einer Zahlung von vor einem Jahr bedeutet, ungefähr 52.000 Blöcke Proof of Work erneut zu erledigen. Das, und keine Regel über das Löschen von Daten, ist gemeint, wenn Bitcoin als unveränderlich bezeichnet wird.

So funktioniert es

Der Hash des vorherigen Blockheaders entsteht, indem SHA-256 zweimal über den 80 Byte großen Header des Vorgängers läuft, und er ist die einzige Referenz, die ein Block auf etwas außerhalb seiner selbst behält.

Weil der Header des Vorgängers den Hash seines eigenen Vorgängers enthält, und so weiter bis zum Anfang, legt ein einziges 32 Byte großes Feld die gesamte dahinterliegende Historie fest. Ein Node, der die Spitze verifiziert hat, hat implizit verifiziert, dass die Kette, die dorthin führt, in sich schlüssig ist. Wer eine Transaktion in einem im vergangenen Sommer geminten Block manipuliert, verändert den Hash des Headers dieses Blocks, was bedeutet, dass die Kopie im Kindblock nicht mehr passt, was bedeutet, dass der Kindblock ungültig ist, und ebenso alles danach. Die Behebung des Schadens bedeutet, jeden dieser Blöcke erneut zu minen, bei ungefähr 144 Blöcken pro Tag oder 52.560 pro Jahr.

Der Genesis-Block ist die Ausnahme, und das muss er sein: vor ihm gibt es nichts, also besteht das Feld aus 32 Nullbytes.

Nichts in einem Block zeigt vorwärts. Wenn Bitcoin Core einen nextblockhash meldet, liest die Software den eigenen Index, nicht den Block, und genau deshalb kann sich dieser Wert während einer Reorganisation ändern, während sich der Hash des vorherigen Blockheaders nie ändert. Dass zwei Blöcke denselben Vorgänger benennen, ist ebenfalls kein Fehler. So sieht eine Fork aus Sicht der Daten aus, und das Netzwerk löst sie auf, indem es den Zweig mit der größten angesammelten Arbeit bevorzugt, statt einen der beiden Verweise für falsch zu erklären.

Wo er auftaucht

Der Hash des vorherigen Blockheaders erscheint unter leicht unterschiedlichen Namen, je nachdem, was gerade betrachtet wird.

Bitcoin Core liefert ihn als previousblockhash aus getblockheader und getblock. Für Block 0 fehlt das Feld in der Antwort einfach, weil es keinen Vorgänger zu benennen gibt. Block-Explorer beschriften ihn meist mit Previous Block und machen daraus einen Link, und so funktioniert das Zurückklicken durch die Historie.

Er ist außerdem die ganze Substanz einer Header-Chain-Synchronisierung. Ein Node, der Header herunterlädt, prüft pro Header zwei Dinge: dass dieser den letzten benennt und dass sein Hash das Ziel erfüllt. Erst wenn diese Kette zusammenpasst, fordert er Blockinhalte an. Leichtgewichtige Wallets gehen nie weiter und behalten die Verknüpfungen und die Arbeit und sonst nichts.

Wenn Sie das Feld jemals von Hand bauen, rechnen Sie mit einem Streit mit Ihren eigenen Augen, denn die Bytes im Header stehen nicht in der Reihenfolge, in der der Hash üblicherweise zitiert wird.

Hash des vorherigen Blockheaders vs. interne Byte-Reihenfolge

Der Hash des vorherigen Blockheaders wird in der umgekehrten Byte-Reihenfolge gespeichert, in der ihn alle zitieren, und das bringt fast jeden durcheinander, der einen Header von Hand prüfen will. Block 1 trägt den Hash seines Vorgängers als 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000. Das ist der Genesis-Hash, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, Byte für Byte rückwärts geschrieben. Die führenden Nullen, die der Proof of Work erzeugt, stehen im Rohfeld am Ende. Es ist nichts falsch, wenn die beiden sichtbar nicht übereinstimmen: Drehen Sie die Bytes um, dann stimmen sie überein.