Ein Orphan Block ist im präzisen Sinn ein Block, dessen unmittelbaren Vorgänger der betrachtete Knoten nicht kennt. Umgangssprachlich kann damit auch ein Stale Block außerhalb der aktiven Kette gemeint sein. Keine der Bezeichnungen allein bedeutet Betrug oder einen fehlerhaften Block; zuerst muss klar sein, welche Daten der Knoten hat und welcher Sinn gemeint ist.
Der vorherige Block wird auch Elternblock genannt. Bei einem echten Orphan Block kennt Janas Knoten ihn nicht und kann die Verbindung deshalb nicht abschließend prüfen. Ein Stale Block kann einen bekannten Elternblock haben und vollständig gültig sein; der Knoten folgt lediglich einem anderen Zweig als aktiver Historie. Der Bitcoin Developer Guide unterscheidet diese Bedeutungen ausdrücklich. Liest Jana orphan in einem Blockexplorer, fragt sie zuerst, ob der Vorgänger fehlt oder der Block nur nicht in der Hauptkette geblieben ist. [1]
Der Unterschied zeigt sich auch in Bitcoin Core. Mit dieser Software lässt sich ein Knoten betreiben, der Blöcke und Transaktionen nach den Bitcoin-Regeln prüft. In Bitcoin Core 29 sucht AcceptBlockHeader den Vorgänger über hashPrevBlock, den Verweis auf dessen identifizierenden Fingerabdruck. Fehlt ein Indexeintrag, lautet die Rückgabe prev-blk-not-found. Ist der Elternblock bekannt und als ungültig markiert, heißt sie bad-prevblk. Der erste Fall bedeutet „Mir fehlt der Zusammenhang“, der zweite „Du baust auf einem ungültigen Block auf“. Wird der fehlende Vorgänger nachgereicht, sind weitere Prüfungen möglich; die Annahme des ganzen Blocks ist damit noch nicht garantiert. [2]
Ein Block besteht aus einem Header, einem kurzen Datenabschnitt mit Angaben zu Identität und Verknüpfung, und einem Hauptteil mit Transaktionen. Bitcoin Core 0.10.0 führte die headers-first-Synchronisierung ein: Zunächst werden Header beschafft und geprüft, danach können Blöcke parallel geladen werden. Janas Knoten kann deshalb den Header des Vorgängers kennen, ohne dessen gesamten Block auf der Festplatte zu haben. Ein fehlender Blockkörper ist kein unbekannter Vorgänger. Wer beides verwechselt, könnte gewöhnliches Herunterladen für ein rätselhaftes Problem halten. [3]
Mit getchaintips in Bitcoin Core 29 sieht Jana, welche Zweigenden ihr Knoten kennt. active steht für die aktive Kette, valid-fork für einen vollständig geprüften inaktiven Zweig. valid-headers bedeutet, dass die Blöcke vorliegen, aber nicht vollständig geprüft wurden; bei headers-only fehlen einige Blöcke. invalid kennzeichnet einen Zweig mit einem ungültigen Block. Das ist also keine Liste gleichartiger Probleme. Auch die Formulierung orphaned branches im Hilfetext hebt diese Unterschiede nicht auf. [4]
Stellen wir uns zwei verschiedene Blöcke A und B auf Höhe 900000 vor. Das ist unser eigenes Beispiel, kein Bericht über ein bestimmtes Ereignis. Die Höhe ist eine Position in der Kette, die konkurrierende Blöcke teilen können. Jana unterscheidet sie mit hash, dem identifizierenden Fingerabdruck, und previousblockhash, dem Verweis auf den Vorgänger. Zwischen gültigen Zweigen entscheidet die kumulierte Arbeit, nicht bloß die Höhe. Die RPC-Schnittstelle für Programmbefehle nennt sie chainwork: die aufsummierte erwartete Arbeit entsprechend den Schwierigkeiten der Blöcke. [1] [5]
Fragt Jana mit getblock einen Block außerhalb der Hauptkette ab, kann Bitcoin Core 29 confirmations = -1 melden. Das ist eine besondere Zustandsmarkierung, keine gewöhnliche Bestätigungszahl. Es handelt sich weder um einen Countdown noch um eine negative Tiefe einer Kettenreorganisation. Auch ein fehlender Vorgänger ist damit nicht bewiesen. Jana muss den Wert zusammen mit Blockidentität und Zweigstatus lesen. Ihr Knoten besitzt zudem möglicherweise nicht jeden Block, den andere Teilnehmer jemals gesehen haben. [5]
Die Blockbelohnung entsteht in einer besonderen ersten Transaktion namens coinbase, unabhängig von der gleichnamigen Börse. Ein Transaktionsoutput hält einen Bitcoin-Betrag und die Bedingungen fest, die erfüllt sein müssen, um ihn auszugeben. In Bitcoin Core 29 beträgt COINBASE_MATURITY 100: Ein auf Höhe H erzeugter Output darf erstmals in einem gültigen Block auf Höhe H+100 ausgegeben werden. Entscheidend ist die Höhendifferenz, nicht die Zahl vergangener Minuten. Diese Wartebedingung ersetzt aber nicht die Zugehörigkeit zur aktiven Kette. Solange der Belohnungsblock auf einem inaktiven Zweig bleibt, fehlt sein Output in der aktiven UTXO-Menge, dem Verzeichnis noch nicht ausgegebener Outputs. Zusätzliche Blöcke anderswo bringen das Geld nicht von selbst zurück. [6] [7] [1] [8]
Jana notiert Blockhash, Vorgänger, Zweigstatus und Programmversion. Dazu kommen die Antworten von getchaintips und getblock sowie der Zeitpunkt ihrer Abfrage. Diesen hält sie getrennt vom Headerfeld time fest: Der Zeitstempel im Block ist nicht der Zeitpunkt, zu dem ihr Computer ihn beobachtet hat. Der Datensatz hilft beim Vergleich weiterer Beobachtungen, beweist allein jedoch weder einen Angriff noch einen bestimmten Netzwerkfehler oder eine weltweite Orphan-Rate. Zunächst beschreibt er den Zustand eines Knotens zu einem bestimmten Zeitpunkt. [4] [5]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Stale Block, Reorg, Block Propagation, Proof of Work, Bitcoin. Auf diesen Eintrag verweisen außerdem Stale Block.