Blockchain Reorganizations (Reorgs) and Active Chain Tip Height Tracking

Because Bitcoin is a decentralized, asynchronous network with latency delays across international nodes, it is possible for two competing miners to find a valid block at the same height almost simultaneously. This event creates a temporary split in the chain topology, known as a Fork.

To resolve this conflict, the network relies on a process called a Blockchain Reorganization (Reorg).

This guide details how forks occur, how nodes track and swap their active chain tip, how transaction states are rolled back, and how exchanges mitigate reorg risks.

---

🍴 1. How a Chain Split Occurs

When two valid blocks are mined at the exact same height, different parts of the P2P network will receive different blocks first, resulting in two conflicting views of the ledger.

                             THE GENERATION OF A LEDGER FORK

                             ┌──► [ Block 840,001A (Mined in Tokyo) ]
                             │
    [ Block 840,000 (Tip) ] ─┤
                             │
                             └──► [ Block 840,001B (Mined in London) ]

• Tokyo nodes adopt block 840,001A as their active chain tip.
• London nodes adopt block 840,001B as their active chain tip.
• Both branches are perfectly valid, have equal block height, and carry identical cumulative work. The network waits for the next block to break the tie.

---

🔄 2. Resolving the Fork with a Reorganization

The fork is broken when a miner on either branch successfully mines the next block (e.g., 840,002 on top of 840,001A).

                         RESOLVING A FORK (THE REORG STRIKE)

                               Active Main Chain (Heaviest)
                             ┌──► [ Block 840,001A ] ──► [ Block 840,002 ]
                             │
    [ Block 840,000 (Tip) ] ─┤
                             │   Orphaned Branch (Rolled Back)
                             └──► [ Block 840,001B ] ──► (Dropped)

1. Work Discrepancy: The branch 840,000 -> 840,001A -> 840,002 now represents more cumulative work than the 840,001B branch.
2. The Swap Command: London nodes receive block 840,002 and realize their current tip 840,001B has been outpaced by a heavier branch.
3. The Reorganization: London nodes must perform a Reorg to align with the heaviest chain tip:
   • Step A (Disconnect): They disconnect block 840,001B from their active ledger.
   • Step B (Rollback): All transactions from 840,001B are removed from the ledger database and returned to the local mempool.
   • Step C (Connect): They apply block 840,001A and block 840,002 sequentially.
   • Step D (Prune): They update their active chain tip to block 840,002.

---

🔒 3. Reorg Risks and Exchange Confirmations

If a transaction was included in the orphaned block 840,001B but is not included in the winning branch (840,001A or 840,002), that transaction effectively disappears from the blockchain history, returning to a "pending" mempool state.

This temporary rollback introduces the risk of Double-Spending Attacks: * An attacker sends coins to an exchange on the weaker branch (840,001B), waits for the exchange to credit their account, and withdraws alternative assets. * The attacker privately mines a heavier branch that excludes the deposit transaction. * Once the attacker broadcasts their heavier branch, a reorg occurs. The exchange's deposit block is disconnected and discarded, leaving them with nothing.

To eliminate this threat, exchanges enforce strict confirmation margins based on block height:

$$\text{Confirmation Margin } (C) \ge 6 \text{ blocks}$$

Statistically, the probability of an attacker maintaining a private, heavier fork for $6$ consecutive blocks against the rest of the global mining hashrate is effectively zero, securing payments against reorg rollback risks.