A transaction can reach peers before it appears in a block. Seeing it in a wallet or explorer is therefore not the same as seeing it confirmed. The payment-processing documentation distinguishes broadcast transactions from transactions included in the chain. Payment states.
Count the containing block too
Assume the transaction remains in the active chain:
| State | Confirmation count |
|---|---|
| Broadcast, not yet in a block | 0 |
| Included in the current tip block | 1 |
| Two more blocks built after its block | 3 |
| Five more blocks built after its block | 6 |
The count includes the block containing the transaction. It is not simply the number of later blocks. How confirmations are described.
Why a node can change its active chain
Two miners can find competing blocks near the same time. Nodes may initially see different tips. When another valid branch accumulates more work, a node can reorganize onto it, disconnecting blocks from its former branch.
Transactions from a disconnected block may appear in the replacement branch, remain unconfirmed, or conflict with transactions in the replacement history. A reorganization does not create permission to ignore the node’s validation rules. Competing branches and chain selection.
Six is not a magic boundary
Bitcoin’s white paper analyzes an attacker trying to catch up with honest work. Its conclusion depends on assumptions about the attacker and the honest network. Additional confirmations generally increase the work that must be overcome; the paper does not establish absolute finality at a particular count. The security model.
An acceptance policy depends on what is at risk and the surrounding conditions. A displayed count also depends on the chain view supplied by the wallet or service showing it.
For a documented incident involving a deeper software disagreement, read the March 2013 chain split.