Chain reorganization

A chain reorganization, or reorg, happens when a node drops the blocks at the top of its chain and switches to a different chain with more work. The dropped blocks become stale. Their transactions are no longer confirmed, but most of them come back in the competing chain, and the rest return to the mempool.

When does a reorg happen?

Most reorgs follow the same pattern. Two blocks are found at nearly the same height. Both are valid, but the network has not yet agreed which one came first. Then the next block is found on top of one of them.

Two blocks are found at once

Two miners find blocks at the same height within seconds of each other. Blocks take time to cross the network, so some nodes receive one block first and others receive the other. Each node keeps the first block it saw at the top of its chain. It also keeps the second one, in case that one matters later.

The next block picks a winner

The next block is built on one of the two. That side now has more work, so nodes on the other side switch to it. Those nodes perform the reorg, and the blocks on the losing side are deactivated.

What is a stale block?

A block deactivated this way is a stale block. People often call it an orphan, but the two words mean different things. A stale block was once part of the chain, so it has a parent. An orphan is a block that arrived before its parent. A node holds it in a waiting pool until the parent shows up.

What becomes of the transactions?

A transaction in a stale block is no longer part of the valid chain. Any transaction that spends one of its outputs is invalid on the new chain. Those coins cannot be spent until the original transaction is mined again.

In practice, little is usually lost. Two competing blocks often hold the same transactions, because both miners built from similar memory pools. A transaction that appears only in the stale block returns to the mempool on your node. It can then be mined into a later block.

Nothing is guaranteed, though. A transaction may take a while to appear again, or a conflicting transaction may be mined first, which kills the original. That is why many people wait for more blocks on top of their payment before they treat it as settled.

Why six confirmations?

A transaction's confirmations count the block that holds it and every block on top of that block. A transaction in the top block has one confirmation. A transaction with six confirmations sits in the sixth block from the tip.

To reverse that transaction, an attacker must replace all six blocks. The Bitcoin white paper, in section 11, gives the math for the chance an attacker with a given share of the hash power can catch up from behind. Replacing the top six blocks gives these chances:

Attacker's share of hash power	Chance to replace the top 6 blocks
10%	0.0065%
20%	0.74%
30%	9.9%
40%	46.2%
50% or more	100%

Six confirmations is a convention, not a law. Against an attacker with 10% of the hash power, the chance is about 1 in 15,000. Against an attacker with 30%, it is close to 1 in 10. Each extra block cuts the chance sharply, which is why big payments often wait for more confirmations. The 51% attack page covers the larger attacks in detail.

Can a reorg be very deep?

By the rules, a reorg can replace any number of blocks, as long as the new chain has more work. Consensus sets no depth limit. Reorgs that happen by chance almost never go deeper than one block, because they come from two blocks found at once. The longest chain page explains how a node picks between two chains. A deep reorg needs someone with most of the network's mining power, which is what the 51% attack page describes.

How do you see reorgs on your node?

bitcoin-cli getchaintips lists the tip of each chain your node knows about. Each entry has a height, a hash, a branchlen (how many blocks the branch has), and a status:

Status	Meaning
active	The chain your node follows now.
valid-fork	A branch your node followed for a time, then dropped after a reorg.
valid-headers	A competing branch whose headers are valid, but which has less work than your active chain, so your node did not fully validate it.
headers-only	Your node knows the headers of a competing branch but not its full blocks.
invalid	A branch with blocks that break the consensus rules.

Your node only records reorgs that happened while it was running. A node that has just downloaded the chain has seen no forks, so the list shows only active. The height page shows how to read a block's height.

Summary

A chain reorganization is a normal part of how a node works. When a node sees a chain with more work, it switches, and the blocks it drops become stale. Their transactions usually reappear in the new chain. Most reorgs touch only the top block. That is why a couple of confirmations is a common rule of thumb, and six is the familiar figure for larger payments.