Im engeren Sinn ist ein Orphan Block ein Block, dessen Elternblock der beobachtende Knoten nicht kennt. Weiter gefasst wird er mit einem stale Block eines inaktiven Zweigs verwechselt; die Bezeichnung allein bestimmt weder Gültigkeit noch Ursache.
Bitcoin Developer Guide unterscheidet ausdrücklich einen Orphan Block mit unbekanntem Elternblock von einem Stale Block auf einem konkurrierenden Zweig. Letzterer kann einen bekannten Elternblock haben und gültig sein. Klären Sie bei einem Explorer oder Poolbericht zuerst die verwendete Bedeutung; das Wort orphan allein entscheidet diese Frage nicht. [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 sucht in AcceptBlockHeader nach hashPrevBlock im Index. Ein fehlender Eintrag ergibt prev-blk-not-found; ein als ungültig markierter Elternblock führt zu bad-prevblk. Das sind unterschiedliche Ergebnisse. Das Beschaffen des Elternblocks ermöglicht weitere Kontextprüfungen, garantiert aber noch nicht die Annahme des gesamten Blocks. [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 führte die headers-first Synchronisierung ein: zunächst Header, danach parallele Blockdownloads. Der Index kann deshalb den Elternheader kennen, ohne den vollständigen Block auf dem Datenträger zu haben. Ein fehlender Blockkörper ist nicht mit einem unbekannten Elternheader gleichzusetzen; entscheidend ist, welche Daten tatsächlich fehlen. [Bitcoin Core 0.10.0 — Headers-first synchronization]
In getchaintips unterscheidet Bitcoin Core 29 active, valid-fork, valid-headers, headers-only und invalid. valid-fork ist ein vollständig geprüfter inaktiver Zweig; bei valid-headers sind die Blöcke verfügbar, aber nicht vollständig geprüft, bei headers-only fehlen einige. Auch die Hilfeformulierung orphaned branches rechtfertigt keine Zusammenlegung dieser Zustände. [Bitcoin Core 29 — getchaintips]
Beispiel: Verschiedene Blöcke A und B können beide die Höhe 900000 haben. Diese Zahl bestimmt weder den Gewinner noch eine eindeutige Identität; speichern Sie hash und previousblockhash. Zwischen gültigen Zweigen entscheidet die kumulierte Arbeit, im RPC als chainwork beschrieben, nicht allein die Höhe. Die Beispielzahl behauptet keine konkrete historische Verzweigung. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
getblock in Bitcoin Core 29 liefert confirmations = -1 für einen Block außerhalb der Hauptkette. Das ist weder eine negative Reorganisationstiefe noch ein Beweis für einen fehlenden Elternblock. Lesen Sie dies zusammen mit Hash, Zweiginformationen und lokalem Knotenzustand; die Ausgabe eines Knotens erfasst nicht alles, was andere empfangen haben. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY beträgt in Bitcoin Core 29 genau 100. Es beschränkt das Ausgeben eines Coinbase-Ausgangs nach Blocktiefe, nicht nach Wartezeit in Minuten. Verstrichene Zeit oder weitere Blöcke anderswo stellen die Belohnung eines stale Zweigs außerhalb der aktiven Historie nicht wieder her; Reife ersetzt keine Aufnahme in die Kette. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
Kombinieren Sie für Ihre Aufzeichnung getchaintips und getblock mit Blockhash, Elternblock, Zweigstatus, Knotenversion und Beobachtungszeit. Erfassen Sie diese getrennt vom Headerfeld time. Eine einzelne Ausgabe beweist weder einen Angriff noch eine globale Orphan-Rate oder eine bestimmte Netzwerkstörung; dafür sind weitere Beobachtungen nötig. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Veralteter Block, Chain-Reorganisation, Blockausbreitung, Proof of Work. Auf diesen Eintrag verweisen außerdem Veralteter Block.