Fork Resolution — Heaviest Chain

When two miners produce a block at the same height, the network temporarily disagrees. The fork resolves when one branch grows longer (more cumulative work) than the other.

                      D <- E <- F  (chain via E: more work)
                     /
GENESIS -- A -- B - C
                     \
                      X <- Y       (orphaned)

Nakamoto consensus rule

"Nodes always consider the longest chain to be the correct one and will keep working on extending it." — Bitcoin whitepaper, section 5

More precisely: most cumulative WORK, not most BLOCKS. This matters across difficulty retargets — a low-difficulty chain with more blocks can lose to a shorter high-difficulty chain.

Tie-break

If two chains have equal cumulative work, nodes pick the one they saw first (first-seen rule, not enshrined in the protocol — it's an implementation choice). Some clients add randomness; Bitcoin Core's default is first-seen.

Reorgs

When a longer alternative arrives, the node:

1. Disconnects blocks back to the fork point.
2. Returns those txs to the mempool (they'll be re-mined into the new chain).
3. Connects the new branch.

For deep reorgs (>100 blocks) most clients refuse without user intervention.

Common ancestor

Useful when resolving forks: walk back from each tip until you find a block both chains include. The reorg replaces everything above that ancestor.

This exercise builds a block tree (parent links + per-block work) and answers TIP / HEIGHT / ANCESTORS / COMMON queries.