Reorg

Anna receives 20,000 satoshi, the small units of bitcoin. Her wallet shows one confirmation: the payment is in a block her node has accepted. The node then learns of a competing valid branch that does not yet contain her payment. Once that branch represents more accumulated mining work, the node switches to it. Replacing part of the history this way is called a Reorg. Anna’s payment may be waiting for confirmation again without anyone having stolen her keys or changed its signature. The deciding measure is neither a vote nor simply a block count, but chainwork: the sum of the work each block demonstrates according to its difficulty. A node rejects an invalid branch even if it has more work. [1] [4]

What Anna sees next depends on the new branch. If it also contains her payment, the payment remains confirmed, although its confirmation count may change. Otherwise, Bitcoin Core may try to return it to the mempool, its temporary list of unconfirmed transactions waiting for a block. Return is not guaranteed. An output from an earlier transaction records an amount and the conditions for spending it. The new branch may already spend the same funds in another transaction; a previous output being spent may be missing, or timing and other admission conditions may not be met. A payment waiting again is therefore different from one the new history no longer allows. [1]

One confirmation means the block containing the payment. Each block after it adds another confirmation and more work for a competing branch to overcome. A payment in the latest block thus has one confirmation; the deeper it sits in the accepted history, the harder replacing that history generally becomes. But no finite confirmation count creates mathematical finality: it never guarantees that replacement is impossible. Merchants and exchanges therefore set their waiting requirements according to payment value and the risk they accept. [3] [5]

A Reorg alone is not evidence of an attack. Two miners can find blocks with the same predecessor almost simultaneously. News does not travel through the network instantly, so nodes may briefly follow different ends of the chain. Once one valid branch accumulates more work, nodes switch to it; the abandoned block is a Stale Block. The same mechanism can, however, be exploited in a Double Spend attack: an attacker tries to establish a history in which the same funds were paid elsewhere. Assessing an event therefore means asking why the switch happened and which payments it changed. [4] [5]

During a Reorg, a node keeps the same rules and chooses between histories that satisfy them. A Hard Fork changes validity rules so that old and new software may judge the same block differently. An ordinary reorganization is not a consensus-rule change and does not by itself create a new currency. The following chapters explain how a node carries out that change of history. [4]

The tip is the latest block in the currently accepted branch. The fork point is the last block shared by the current active chain and the alternative branch. Reorg depth is commonly described by how many blocks must be disconnected from the end of the active chain to reach that common ancestor. A one-block reorg replaces the tip; a deeper reorg rolls back several confirmed blocks. Depth is node-relative because a node reorganizes from the chain it currently considers active. [1]

A Full Node checks the rules for itself. The function names below describe their implementation in Bitcoin Core. Bitcoin Core does not simply choose the tallest or most popular branch. A candidate chain must satisfy the node’s consensus rules during activation; more chainwork cannot make an invalid block valid. FindMostWorkChain selects the candidate with the most work that is not known to be invalid. This does not yet mean full validation: further checks occur while blocks are connected in ActivateBestChain. Known invalid branches are excluded. [1]

A UTXO is an unspent transaction output; the UTXO set is the collection of these available outputs. Undo data records what is needed to reverse a block’s effects. DisconnectTip and related validation logic undo each disconnected block in reverse order. Spent outputs are restored and outputs created by the removed block cease to be confirmed. This is why chainstate requires undo data: the node must be able to reconstruct the UTXO set corresponding to the fork point before applying the competing branch. [1]

Rollback here means returning to the state before the disconnected blocks; chainstate is the node’s working state for its accepted history. After rollback, ConnectTip applies blocks from the more-work branch in forward order. Every transaction is validated against the reconstructed UTXO set and the consensus rules appropriate to that height. The result is a new active-chain tip and a chainstate consistent with that exact history, not a blend of transactions from both branches. [1]

The Coinbase Transaction is the block’s first transaction, which assigns the miner’s reward. Height h denotes a block’s position in the chain. A coinbase transaction is an exception: it does not return to the mempool after disconnection. Under consensus rules, a coinbase output created at height h can first be spent in block h + 100. With the tip at h + 99, the source block has 100 confirmations and the maturity condition permits inclusion of the spend in the next block. If a reorg removes the coinbase block, that block’s reward disappears from the active chainstate. Descendant transactions that relied on the removed history can also become invalid. [1] [2] [3]

These are function names from a particular program version, not additional steps a wallet user needs to perform. In Bitcoin Core v29.0, the steps are explicit: FindMostWorkChain finds the candidate with the most chainwork that is not known to be invalid, ActivateBestChainStep may disconnect the current tip, ConnectTip validates and connects alternative blocks, and MaybeUpdateMempoolForReorg rechecks transactions from disconnected blocks. Activation may discover that a candidate is invalid and continue searching for another branch. A large reorg requires processing more disconnected and connected blocks, so it can prolong ActivateBestChain processing. [1]