Chain reorganization

Switching to a competing branch

Nodes receive blocks at different times. When two branches share an ancestor, each node validates the candidate blocks before comparing their accumulated proof of work. A higher height alone does not establish that a branch should replace the current chain.

The node detaches blocks back to the common ancestor and attempts to attach the alternative branch. Its transaction state must change with that switch. Wallets then reconcile their histories with the accepted chain.

References: Monero source: cryptonote_core/blockchain.cpp

Reading a reorganization report

An operator should record the affected heights, block hashes and the depth of the replacement. The daemon can expose alternative-chain information through RPC. One isolated observation does not establish what all other nodes saw.

For a merchant, a transaction in a block provides stronger evidence than a transaction in a local pool. A reorganization can still replace recent blocks. Confirmation policy should reflect the value and reversibility of the purchase.

References: Monero source: cryptonote_core/blockchain.cpp · Daemon RPC reference

Example

Two miners find competing blocks at the same height. Your node first accepts one, then learns of a stronger valid branch extending the other. A payment confirmed only in the replaced block may return to the transaction pool if it remains valid.

References: Monero source: cryptonote_core/blockchain.cpp · Daemon RPC reference

Limits and cautions

A reorganization is not, by itself, evidence of an attack. Confirmation counts can fall, and a conflicting spend can prevent a detached transaction from returning to the pool. No fixed confirmation count guarantees finality.

References: Monero source: cryptonote_core/blockchain.cpp · Daemon RPC reference