A reorg is a local chainstate transition, not a rewrite of Bitcoin's consensus rules. A full node first validates candidate blocks under its own rules, then among valid branches selects the one with the most cumulative chainwork. If that branch diverges below the current tip, the node rolls back UTXO changes from disconnected blocks, applies the alternative branch, and reconciles affected transactions with its mempool.
Bitcoin Core does not choose the numerically tallest or merely most popular branch. A candidate chain must first satisfy every consensus rule enforced by the node. FindMostWorkChain and ActivateBestChain operate on valid candidates; only then does cumulative proof of work determine the preferred branch. An invalid block cannot win by carrying more hash work because it is excluded before chain comparison.
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 active-tip blocks must be disconnected 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.
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.
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.
Transactions from disconnected blocks are not automatically lost. Bitcoin Core collects eligible non-coinbase transactions and attempts to return them to the mempool. A transaction may instead already appear in the new branch, conflict with a transaction there, become non-final, lose required inputs or otherwise fail mempool admission. Wallet software therefore must treat a confirmation as reversible until sufficient depth is reached for its risk model.
A coinbase transaction is special: it cannot be resurrected into the mempool, and its outputs require 100 confirmations before spending under Bitcoin consensus. If a block containing a miner's coinbase is reorganized out, that block reward disappears from the active chainstate. Descendant spends can also become invalid when their assumed confirmation history is removed.
A confirmation counts blocks on the node's currently active chain. Each additional block usually makes replacement economically harder because an alternative branch must accumulate enough work to overtake it, but no finite confirmation count creates mathematical finality in proof-of-work Bitcoin. Merchants, exchanges and custody systems choose confirmation thresholds according to value, attacker incentives and operational tolerance.
Short reorgs can occur naturally when miners find competing blocks close together and propagation causes different nodes to see different tips temporarily; one branch later accumulates more work and the other becomes stale. Deliberate double-spend attacks attempt to use the same mechanism with a privately or strategically mined branch. The mechanism is identical—branch replacement after validity and chainwork comparison—even though the cause and economic meaning differ.
A reorg occurs inside one rule set: the node is choosing between branches it considers valid. A hard fork instead changes validity so upgraded and legacy nodes may disagree about whether the same block is valid at all. Reorgs can happen during protocol incidents or forks, but ordinary reorganization is a chain-selection event, not a consensus-rule change.
Current Bitcoin Core exposes this machinery directly in validation code: FindMostWorkChain identifies the best valid candidate, ActivateBestChainStep may disconnect the current tip, ConnectTip attaches the alternative blocks, and MaybeUpdateMempoolForReorg re-evaluates transactions from disconnected blocks. The code explicitly notes that substantial reorgs can make ActivateBestChain take a long time.
For the clearest picture, read this entry together with Timechain, Confirmation, Stale block, Proof of Work, Nakamoto consensus, Bitcoin. The reverse links also lead from Confirmation, Double-spend, Coinbase transaction, Soft Fork.