Au sens strict, Orphan Block est un bloc dont le nœud observateur ne connaît pas le parent. Un usage plus large le confond avec un bloc stale sur une branche inactive ; le terme seul ne détermine donc ni sa validité ni sa cause.
Bitcoin Developer Guide distingue explicitement un Orphan Block au parent inconnu d’un Stale Block sur une branche concurrente. Ce dernier peut avoir un parent connu et être valide. En lisant un explorateur ou un rapport de pool, identifiez d’abord le sens employé ; le mot orphan ne tranche pas cette distinction. [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 recherche hashPrevBlock dans son index au sein de AcceptBlockHeader. Une entrée absente renvoie prev-blk-not-found ; un parent marqué invalide mène à bad-prevblk. Ce sont des résultats différents. Obtenir le parent permet des contrôles contextuels supplémentaires, mais ne garantit pas à lui seul l’acceptation du bloc entier. [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 a introduit la synchronisation headers-first : les en-têtes d’abord, puis les téléchargements parallèles des blocs. L’index peut donc connaître l’en-tête du parent sans son bloc complet sur disque. Ne confondez pas un corps de bloc absent avec un en-tête parental inconnu ; déterminez les données réellement manquantes. [Bitcoin Core 0.10.0 — Headers-first synchronization]
Dans getchaintips, Bitcoin Core 29 distingue active, valid-fork, valid-headers, headers-only et invalid. valid-fork est une branche inactive entièrement validée ; valid-headers dispose des blocs sans validation complète, tandis que headers-only manque de certains blocs. Même la formule orphaned branches de l’aide ne justifie pas de fusionner ces états. [Bitcoin Core 29 — getchaintips]
Illustration : deux blocs différents A et B peuvent avoir la hauteur 900000. Ce nombre ne désigne ni le gagnant ni un bloc unique ; conservez hash et previousblockhash. La sélection entre branches valides suit le travail cumulé, décrit comme chainwork dans RPC, et non simplement la hauteur. Ce nombre illustratif ne désigne pas une bifurcation historique précise. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
getblock de Bitcoin Core 29 renvoie confirmations = -1 pour un bloc hors de la chaîne principale. Ce n’est ni une profondeur négative de réorganisation ni la preuve d’un parent manquant. Lisez ce résultat avec le hash, les données de branche et l’état local ; la sortie d’un nœud ne recense pas tout ce que les autres ont reçu. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY vaut 100 dans Bitcoin Core 29. Cette règle limite la dépense d’une sortie coinbase selon la profondeur en blocs, pas selon une attente en minutes. Le temps écoulé ou de nouveaux blocs ailleurs ne restaurent pas la récompense d’une branche stale hors de l’historique actif ; la maturité ne remplace pas l’inclusion dans la chaîne. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
Pour votre relevé, associez getchaintips et getblock au hash du bloc, au parent, à l’état de branche, à la version du nœud et à l’heure d’observation. Notez cette heure séparément du champ time de l’en-tête. Une seule sortie ne prouve ni attaque, ni taux mondial de blocs orphelins, ni panne réseau précise ; il faut d’autres observations. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
Pour une vision complète, lisez aussi Stale Block, Reorg, Block propagation, Proof of Work. Cette entrée est également citée par Stale Block.