狭義の Orphan Block は、観測ノードが親を知らないブロックです。広い用法では非アクティブな枝の stale ブロックと混同されるため、名称だけでは有効性も原因も確定しません。
Bitcoin Developer Guide は、親が不明な Orphan Block と競合する枝の Stale Block を明確に区別しています。後者は親が既知で、有効な場合があります。エクスプローラーやプールの報告では、まず作者の用法を確認してください。orphan という語だけでは区別できません。 [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 の AcceptBlockHeader は索引で hashPrevBlock を検索します。項目がなければ prev-blk-not-found、親が無効と記録されていれば bad-prevblk です。両者は異なる結果です。親を取得すると文脈に応じた追加検査が可能になりますが、それだけでブロック全体の受理は保証されません。 [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 は headers-first 同期を導入しました。まずヘッダーを取得し、次にブロックを並列ダウンロードします。そのため、ディスク上に完全な親ブロックがなくても、索引は親ヘッダーを知っている場合があります。本体の欠落を親ヘッダー不明と混同せず、何のデータが欠けているかを確認します。 [Bitcoin Core 0.10.0 — Headers-first synchronization]
getchaintips で Bitcoin Core 29 は active、valid-fork、valid-headers、headers-only、invalid を区別します。valid-fork は完全検証済みの非アクティブな枝です。valid-headers は全ブロックが利用可能でも完全検証前、headers-only は一部ブロックが未取得です。ヘルプの orphaned branches という表現も、これらを一つにまとめる根拠にはなりません。 [Bitcoin Core 29 — getchaintips]
例として、異なるブロック A と B がともに高さ 900000 を持つことがあります。この数値だけでは勝者も一意な識別も決まらないため、hash と previousblockhash を記録します。有効な枝の選択は、RPC で chainwork と記述される累積作業量に従い、高さだけでは決まりません。例の数値は特定の歴史的分岐を主張していません。 [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
Bitcoin Core 29 の getblock は、メインチェーン外のブロックに confirmations = -1 を返します。これは負の再編成深度でも、親の欠落の証明でもありません。ハッシュ、枝の情報、ローカルノードの状態と併せて読んでください。一つのノードの出力は、他のノードが受信したすべてを列挙するものではありません。 [Bitcoin Core 29 — getblock]
Bitcoin Core 29 の COINBASE_MATURITY は 100 です。coinbase 出力の使用をブロック深度で制限し、待機時間の分数ではありません。時間の経過や別の場所での追加ブロックだけでは、アクティブな履歴外にある stale 枝の報酬は復活しません。成熟はチェーンへの組み込みの代わりにはなりません。 [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
記録には getchaintips と getblock を、ブロックハッシュ、親、枝の状態、ノードのバージョン、観測時刻と組み合わせます。観測時刻はヘッダーの time フィールドとは別に記録します。一回の出力だけでは、攻撃、世界全体の孤立ブロック率、特定のネットワーク障害を証明できず、追加の観測が必要です。 [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
理解を深めるには、この項目とあわせて次もお読みください Stale Block, Reorg, Block propagation, Proof of Work. 次の項目からも参照されています Stale Block.