Blockchain Reorganizations (Reorgs): The Anchor Guide to Chain Swaps
Blockchain Reorganizations (Reorgs): The Anchor Guide to Chain Swaps
Executive Summary: A Blockchain Reorganization (Reorg) is the process by which a Bitcoin node switches its current "Active" chain tip to a newly discovered branch that contains more cumulative work. Reorgs occur naturally due to network latency (1-block reorgs) or can be the result of a deliberate attack. During a reorg, blocks on the "Minority" branch are disconnected, and their transactions are returned to the mempool, while the "Majority" branch becomes the definitive history. This mechanism ensures that the entire global network eventually converges on a single version of the truth.
🔍 Why This Module Matters
Reorgs are the "Erasers" of the blockchain. They allow the network to correct mistakes and resolve conflicts without central intervention. However, for users and exchanges, a reorg is a moment of risk: a transaction that looked "Confirmed" can suddenly disappear or be reversed. This module will deconstruct the "Disconnect/Connect" logic of a reorg, explain why "6 Confirmations" is the industry standard, and detail the technical steps a node takes to "Rewrite" its local database.
🏛️ The Anatomy of a Chain Swap
A reorg is not a "Deletion"; it is a "Switch."
1. The Fork Event
Two miners find Block 800,001 at the same time. The network is split.
-
Branch A: The "Iceland" Branch.
-
Branch B: The "Australia" Branch.
2. The Heavier Branch Discovery
A third miner finds Block 800,002 on top of Branch A. When a node on Branch B receives this new block, it realizes its current history is "Lighter" than the incoming news.
3. The Technical Step-by-Step
To align with the truth, the node performs a 4-step sequence:
-
Find Common Ancestor: The node looks back to find the last block both branches share (Block 800,000).
-
Disconnect (Rollback): The node "Undoes" the transactions in its local Block 800,001B. These coins are returned to the "Unspent" state.
-
Connect (Apply): The node applies the transactions from Block 800,001A and then Block 800,002A.
-
Update Tip: The node marks 800,002A as the new "Active Tip."
graph TD
A[Block 800,000] --> B[Block 800,001A]
B --> C[Block 800,002A]
A --> D[Block 800,001B]
C -->|Discover New Tip| E{Is Work Higher?}
E -- YES --> F[Reorg Triggered]
F --> G[Disconnect B]
G --> H[Connect A & C]
H --> I[New Active Tip: C]
style C fill:#9f9,stroke:#333,stroke-width:2px
style D fill:#f66,stroke:#333,stroke-width:2px
⚙️ What Happens to Your Money During a Reorg?
| Scenario | Result | Status |
|---|---|---|
| Transaction is in BOTH branches | No change. | Confirmed |
| Transaction is ONLY in the minority branch | Returned to Mempool. | Pending |
| Transaction is ONLY in the majority branch | Added to Ledger. | Confirmed |
The Double-Spend Risk: If an attacker sends coins to an exchange on the minority branch, but excludes that transaction from the majority branch they are privately mining, the exchange loses money when the reorg happens. This is why you must wait for confirmations.
🛠️ The Confirmation Margin: Why 6 Blocks?
The probability of a reorg drops exponentially as more blocks are added to a chain.
-
1 Block: Natural, common. ~1% chance of reversal.
-
2 Blocks: Very rare. Usually indicates significant network latency.
-
6 Blocks: Effectively impossible for an attacker with less than 50% of the hashrate.
-
Exchange Standard: Most exchanges wait for 3 to 6 blocks before allowing you to withdraw or trade funds.
🛡️ Database Implementation: ConnectBlock vs. DisconnectBlock
In the Bitcoin Core source code (src/validation.cpp), the reorg logic is handled by two primary functions:
-
DisconnectBlock: Removes a block's effects from the UTXO set. It adds spent inputs back to the database and removes the outputs created by the block. -
ConnectBlock: The opposite—it removes inputs (spends them) and adds the new outputs.
This "Transactional" database approach ensures that even if a computer crashes in the middle of a reorg, the blockchain data remains consistent.
🎯 Learning Objectives for this Module
By the end of this module, you will be able to:
-
Define a Blockchain Reorganization and identify its primary cause.
-
Explain the "Disconnect/Connect" sequence of a chain swap.
-
Trace the path of a transaction that is "Orphaned" during a fork.
-
Justify the use of confirmation depths (e.g., 6 blocks) for high-value payments.
-
Understand the role of the "Common Ancestor" in resolving chain divergences.
🗺️ Module Roadmap: What's Next?
Now that we've seen the "Eraser" in action, we will look at the rules that govern it:
-
BIP 34 (Coinbase Height): Why the block height is now mandatory in the coinbase.
-
The Most Work Rule: A deep dive into the math of nChainWork vs. nHeight.
-
Natural Forks & Latency: Why small reorgs are a sign of a healthy network.
-
Python UTXO Reorg Simulator: Writing a script to "Undo" and "Redo" transaction blocks.
🎓 Summary
Reorgs are the "Self-Correction" mechanism of Bitcoin. They ensure that no matter how messy the network gets, it always returns to a single, shared reality. By mastering the mechanics of reorgs, you are understanding the dynamic, living nature of the global ledger and why "Confirmation" is the ultimate measure of finality in the digital age.
TeachMeBitcoin is an ad-free, open-source educational repository curated by a passionate team of Bitcoin researchers and educators for public benefit. If you found our articles helpful, please consider supporting our hosting and ongoing content updates with a clean donation: