Orphans, Stale Blocks & Reorgs

The chaining and validation rules tell us how a single line of blocks stays honest. But the network is global and messages travel at the speed of light — not instantly. Two miners on opposite sides of the planet can solve the next block at nearly the same moment, each unaware of the other. For a few seconds, there are two valid “next blocks” and the chain has temporarily forked. How the network resolves this — automatically, with no referee — is the final piece of how blocks become a single agreed history, and it’s the reason you’re told to wait for confirmations.

How a fork happens

                          ┌── Block 801a  (found by Miner A)
   ... ─ 799 ─ 800 ───────┤
                          └── Block 801b  (found by Miner B)

   Both are valid. Both build on 800. The network is split:
   nodes near A heard 801a first; nodes near B heard 801b first.

This isn’t an attack and isn’t rare — it’s the normal consequence of propagation delay. Both blocks pass every validation rule; they just disagree about which transactions go next. For a moment, honest nodes hold different tips. The protocol must pick a winner without anyone deciding — and it does, via the most-work rule.

The most-work chain wins

The tie breaks the instant the next block is found. Whichever branch a miner extends first now has more accumulated proof of work than the other:

   ... ─ 800 ─ 801a ─ 802   ← 3 blocks of work on this branch:  WINS
              \
               801b          ← only 1 block of work:  LOSES → stale

Every honest node follows the rule “build on the chain with the most cumulative work” (not literally the longest by count, but the heaviest by total difficulty). So as soon as 802 lands on top of 801a, the 801a branch is heavier, and the whole network converges on it. No vote, no message saying “you lost” — each node independently recomputes which chain has more work and switches if needed.

Term	Meaning
Stale block	A validly-mined block that lost the race and is no longer on the best chain
Orphan block	Loosely, a block whose parent the node hasn’t seen yet (often used interchangeably with “stale”)
Reorg	A node switching its active chain to a different, heavier branch

Stale vs orphan — a muddy word

“Orphan” is used two ways. Strictly, an orphan is a block whose parent is missing from the node’s view, so it can’t yet be attached. A block that simply lost the most-work race is more precisely a stale block. In casual usage the loser of a race is often just called an “orphan.” The key fact is the same either way: it was valid, it cost real energy to make, and it’s no longer part of the agreed chain.

Reorganizations: switching chains

When a node discovers that a different branch now has more work, it performs a reorg (reorganization): it rolls back the blocks on its current tip, returns their transactions to the mempool, and re-applies the blocks of the heavier branch instead.

   Node currently on:   ... 800 ─ 801b
   Hears about:         ... 800 ─ 801a ─ 802   (heavier!)

   Reorg:  disconnect 801b  →  connect 801a, 802
           txs unique to 801b go back to the mempool to be re-mined

Most reorgs are 1 block deep and resolve in seconds — a normal hiccup of a distributed system. Deeper reorgs are progressively rarer, because they require an alternate branch to out-work a chain that the whole honest network is busy extending.

Why you wait for confirmations

Here is the payoff that connects everything. A transaction in the most recent block could still be undone if a competing branch wins the next round — a 1-block reorg would shuffle it back into the mempool. So a transaction’s finality is probabilistic, deepening with every block stacked on top:

   0 confirmations  → in the mempool only; trivially replaceable
   1 confirmation   → in the tip block; a 1-block reorg could still undo it
   3 confirmations  → undoing it needs an attacker to out-work 3 blocks
   6 confirmations  → reversal so expensive it's treated as settled (~1 hour)

Each confirmation is another block of accumulated work an attacker would have to redo and then overtake the honest network to reverse your payment — the same compounding cost we saw in Chaining Blocks. This is also exactly why zero-confirmation transactions are risky: an unconfirmed transaction can be replaced or dropped, as explored in the zero-conf myth. And it is the bridge to 51% attacks: an attacker with majority hash power can deliberately mine a longer hidden branch to force a deep reorg and double-spend — see famous incidents and attacks.

Honest forks vs. malicious reorgs

A natural 1-block fork is nobody’s fault — just two miners and the speed of light. A deep reorg, by contrast, almost never happens by accident; it implies someone amassed enormous hash power to overwrite history. The protocol can’t tell intent apart, but the cost is the defense: a one-block stale block is cheap and routine, while overwriting six blocks means out-mining the planet for an hour.

The thread

How does this help untrusting strangers agree on one ledger? Forks are the moment when agreement is genuinely in doubt — two valid futures, no leader to choose. The most-work rule resolves them with pure arithmetic: every node independently follows the heaviest chain, so the network re-converges on one history within seconds, automatically. Confirmations then turn that convergence into a quantifiable confidence — the deeper your transaction, the more energy an adversary must burn to dislodge it. Strangers don’t need to agree instantly; they need a rule that makes disagreement temporary and reversal exponentially expensive. That rule is what stale blocks, reorgs, and confirmations are all about.

Check your understanding

1. Why do natural forks happen even when every miner is perfectly honest?
2. State the rule honest nodes use to pick the winning branch. Is it about block count or something else?
3. Distinguish a stale block from an orphan block, and describe what happens to the transactions in a block that loses the race.
4. Walk through what a node does mechanically during a reorg.
5. Connect confirmations to reorgs: why is a 6-confirmation transaction considered settled while a 0-confirmation one is risky?