Reorg はローカルな chainstate の変更であり、Bitcoin のコンセンサスルールの変更ではありません。Full Node は自身の検証ルールを適用し、それを満たす分岐のうち累積 chainwork が最大のものを有効化します。現在の末端より前で分岐している場合、ノードは切り離したブロックによる UTXO の変更を元に戻し、代替分岐を適用して、影響を受けたトランザクションを mempool に照らして再評価します。
Bitcoin Core は単に高さが最大、または最も人気のある分岐を選ぶわけではありません。候補チェーンは有効化の際にノードのコンセンサスルールを満たす必要があり、chainwork が大きくても無効なブロックが有効になることはありません。FindMostWorkChain は、無効であることがまだ判明していない候補から作業量が最大のものを選びます。これは完全な検証の完了を意味せず、ActivateBestChain でブロックを接続する際にさらに検査が行われます。無効と判明した分岐は除外されます。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
分岐点は、現在のアクティブチェーンと代替分岐が共有する最後のブロックです。Reorg の深さは通常、その共通祖先まで戻るために末端から切り離す必要があるブロック数で表します。1ブロックの Reorg は末端を置き換え、より深い Reorg は複数の確認済みブロックを巻き戻します。深さは個々のノードの状態に対して定まります。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
DisconnectTip と関連する検証処理は、切り離したブロックの影響を逆順に取り消します。使用済みの UTXO が復元され、除外されたブロックが作成した出力は確認済みではなくなります。そのため Bitcoin Core は取り消し用データを保存し、分岐点の UTXO 集合を正確に再構築できるようにしています。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
巻き戻し後、ConnectTip は chainwork がより大きい分岐のブロックを順方向に接続します。各トランザクションは、再構築した UTXO 集合と該当する高さで有効なルールに照らして再検証されます。結果は一つの具体的な履歴に対応する chainstate であり、両分岐のトランザクションを混ぜた状態ではありません。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
切り離したブロック内のトランザクションが必ず消えるわけではありません。Bitcoin Core は条件を満たす coinbase 以外のトランザクションを mempool に戻そうとします。すでに新しい分岐に含まれていたり、競合したり、入力を失ったり、時間条件や mempool ポリシーを満たさなくなったりする場合もあります。したがってウォレットは、Reorg によって確認が取り消される可能性を考慮する必要があります。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Coinbase トランザクションは例外で、切り離し後に mempool へ戻りません。コンセンサスルールでは、高さ h で作成された coinbase 出力を最初に使用できるのはブロック h + 100 です。末端が h + 99 のとき、元のブロックは100確認を持ち、成熟条件は次のブロックへの使用トランザクションの収録を許します。Reorg が coinbase を含むブロックを除外すると、そのブロック報酬はアクティブな chainstate から消えます。除外された履歴に依存する後続トランザクションも無効になる場合があります。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation] [Bitcoin Core v29.0 — coinbase maturity validation] [Bitcoin Core v29.0 — confirmation depth]
確認数には、トランザクションを含むブロックと、そのノードの現在のアクティブチェーン上で後に続くすべてのブロックを含めます。現在の末端にあるトランザクションは1確認です。ブロックが増えるほど通常は履歴の置き換えに必要な作業量が増えますが、有限の確認数で数学的に絶対なファイナリティは得られません。取引所や加盟店は支払額とリスクモデルに応じて確認数の基準を選びます。 [Bitcoin Core v29.0 — confirmation depth] [Bitcoin whitepaper — Sections 5 and 11]
二つのマイナーが競合するブロックをほぼ同時に発見し、ネットワークの異なる部分が一時的に別々の末端を追うと、短い Reorg が自然に起こることがあります。その後、chainwork が小さい分岐はアクティブチェーンから外れます。Double Spend 攻撃は同じ仕組みを意図的に使います。チェーン選択の技術的手順は同じで、原因と経済的目的が異なります。 [Bitcoin Developer Guide — Block Chain] [Bitcoin whitepaper — Sections 5 and 11]
Reorg は一つのルール集合の中で起こり、ノードは有効だと判断する分岐の中から選びます。Hard Fork は有効性のルールを変えるため、古いソフトウェアと新しいソフトウェアはブロックが有効かどうか自体について判断が分かれる場合があります。したがって再編成自体はコンセンサスの変更ではありません。 [Bitcoin Developer Guide — Block Chain]
Bitcoin Core v29.0 では手順が明示されています。FindMostWorkChain は無効と判明していない候補から chainwork が最大のものを探し、ActivateBestChainStep は現在の末端を切り離すことがあります。ConnectTip が代替ブロックを検証して接続し、MaybeUpdateMempoolForReorg が切り離したブロック内のトランザクションを再検査します。有効化の途中で候補の無効性が判明し、別の分岐の探索を続ける場合もあります。大きな Reorg では切り離しと接続を行うブロックが増えるため、ActivateBestChain の処理時間が長くなる可能性があります。 [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
理解を深めるには、この項目とあわせて次もお読みください 承認, Proof of Work, Stale Block, 二重支払い, Full Node, UTXO. 次の項目からも参照されています 承認, 二重支払い, コインベース取引, Soft Fork.