Bitcoin Chain Reorganizations and Cumulative Work: What Confirmations Mean

Miners work on top of the chain tip they currently know. If two valid blocks are found close together, each can refer to the same parent block. One node may hear about the first block sooner and another node may hear about its sibling first. Both nodes can temporarily show a different block at the same height without either block being invalid.

The block height counts a block’s position after genesis; it is not a unique block identifier. Competing blocks at one height have different header hashes and can include different transactions. Bitcoin’s Block Chain guide describes simultaneous blocks, forks, and stale branches. A short-lived fork is a normal consequence of propagation delay, not proof that the network has split permanently.

A candidate block must meet the proof-of-work target and all applicable consensus rules. Each valid block contributes work based on its target. A chain’s cumulative work is the sum of that work across its blocks, so counting blocks alone can give the wrong answer when branches contain blocks produced at different difficulty targets.

Suppose two branches share a parent and each has one child at the same height. The branches may have equal or slightly different cumulative work; when one branch gains enough valid work to become the strongest candidate, nodes can switch to it. Bitcoin Core exposes the active chain’s total work as chainwork in getblockchaininfo. Compare block hashes and work context, not height labels alone.

Proof of work does not excuse invalid blocks. A full node checks each candidate under its consensus rules, then considers the work on branches that pass those checks. A branch with more hashes behind it cannot make an invalid transaction, an invalid signature, or an excessive coin creation valid to that node.

The phrase “most-work chain” is also local to a node’s information. Nodes learn about headers and blocks from peers, and network delays can make their views differ for a while. If a node is isolated, unsynchronized, or using outdated consensus software, it may not know about the same valid branches as a well-connected, current node. Bitcoin’s peer-to-peer guide explains how peers announce and relay blocks; a node’s own validation and its view of the network are separate concerns.

When a node learns of a stronger valid branch, it finds the point where the branches diverged. It disconnects the active-chain blocks after that common ancestor, then validates and connects the blocks on the selected branch. A one-block reorganization replaces one tip; a deeper reorganization replaces a longer suffix. The selected branch may have the same height as the old one, or a different height, because work—not height—decides.

This is a change to that node’s active chain view. It does not mean every wallet, explorer, merchant, or node updates at the same instant. During propagation, one service may already report the new active tip while another still shows the old branch. Blocks on the displaced branch become stale relative to the selected chain; the underlying block data can still be stored locally for inspection even though it is no longer part of the active chain.

Consider a hypothetical fork after a shared ancestor: one branch contains a payment and another valid branch later gains more cumulative work. A node that learns and validates the stronger branch disconnects the old blocks and connects the competing ones. The payment then loses its block confirmation in that node’s active chain, even if the displayed height happens to match. Its next status depends on whether its inputs remain unspent on the selected branch; mempool re-entry is conditional, and a service that has not caught up may still show the earlier view.

If a transaction was included in a block that is disconnected, it no longer has that block’s confirmation on the node’s active chain. The transaction may return to that node’s mempool if it is still valid, does not conflict with a transaction on the selected branch, and meets that node’s relay and mempool policies. Mempool contents are local and are not a promise that the transaction will be mined again.

A conflicting spend on the selected branch can leave the displaced transaction invalid under the current UTXO state. In other cases, the transaction may be mined again later, remain unconfirmed, or disappear from a particular node’s mempool. Wallets and services should refresh the transaction’s block association and confirmation count after a reorganization rather than treating an earlier notification as permanent. Bitcoin Core’s getchaintips can show known active and competing tips, but it only reports that node’s block tree.

For a transaction in an active block, that containing block is commonly counted as confirmation one; each later block adds another. The number is a convenient measure of how many active-chain blocks build on the transaction’s block. It does not mean that the transaction is protected by a fixed number of blocks regardless of their targets, or that a future reorganization is impossible.

More accumulated work after inclusion generally makes a competing branch need more work to displace the transaction’s block. The exact risk depends on the competing branch, network conditions, attacker resources if an attack is involved, and the validation rules the node applies. There is no universal confirmation count that guarantees safety for every payment or every service. The payment-processing guide explains why merchants choose confirmation policies based on their own risk and payment context.

Two miners can find blocks near the same time, and propagation usually lets one branch gain the next block first. The other branch then becomes stale, often after only one block. This ordinary race can briefly make confirmations differ between nodes and can cause a transaction to be re-counted if its block loses.

A deeper reorganization can follow a network disruption, a delayed release of valid blocks, software or consensus coordination problems, or an attempt to replace prior history. These situations differ in cause and severity. “51% attack” is a common label for an attacker attempting to outpace honest work, but work does not let the attacker force a validating node to accept blocks that violate that node’s consensus rules. Conversely, a node that is cut off from honest peers can be shown an incomplete view, so checking only one remote explorer is not a complete network diagnosis.

On a Bitcoin Core 31.0 node, getblockchaininfo reports the network name, validated block height, header count, best block hash, active-chain chainwork, and synchronization-related fields. getchaintips lists tips in that node’s known block tree, including the active tip and branches with statuses such as valid-fork, valid-headers, headers-only, or invalid. Those fields help distinguish a fully validated side branch from headers a node has not fully processed.

RPC output is a snapshot of one machine, not a network-wide declaration. During initial synchronization or poor connectivity, a node may lag or know less of the block tree. Check the chain name, the latest block hash, validation and sync status, and whether the observed tip remains active. The Core 31.0 RPC reference is version-specific; verify the commands and fields against the Core version you run.

When a service reports a reorganization, identify the transaction ID and the block hash that previously contained it. Query a node you trust for the current active tip and check whether the old block remains on that node’s active chain. Then determine whether the transaction appears in a newly active block, is unconfirmed, or conflicts with a different spend. An explorer’s red or green status is a provider’s view, not a consensus rule.

For a deposit, protocol confirmation count and a recipient’s account-credit policy are separate. The deposit confirmation guide covers exchange credit and asset-support checks; this article explains Bitcoin’s branch selection beneath that status. For node validation, pruning, and the limits of a local node’s view, see the [Bitcoin full-node guide](/learn/bitcoin-full-node-pruning-archive-storage-validation-wallet-trust-explained). Don't rebroadcast or resend solely because a display changed; first establish the transaction’s current status and the service’s instructions.