Bitcoin confirmations: what they mean, why six became the convention, and why none is final

Count the containing block as the first confirmation

If a transaction is in block 900,000 and the observed tip is 900,005, it has six confirmations: 900,005 − 900,000 + 1. Five blocks are above it; its own containing block counts as one.

The count describes the chain accepted by the observer at that time. A reorganization can change the transaction’s location or remove that inclusion. More depth generally improves settlement confidence under stated assumptions, but the count is not an unconditional guarantee.

Why six became the number

Section 11 of the white paper works out the odds. It imagines an attacker who has paid a merchant and then secretly mines a rival chain in which the payment never happened, hoping to overtake the honest chain and release it. The paper limits what such an attacker can do: “An attacker can only try to change one of his own transactions to take back money he recently spent.” It then models the race as a gambler’s ruin problem: with an attacker holding less hash power than the honest miners, the probability of ever catching up from z blocks behind falls exponentially as z grows.

The paper prints the numbers. With q = 0.1, meaning the attacker has a tenth of the network’s hash power, the chance of catching up once the merchant has waited for 5 blocks after the block containing the transaction is 0.0009, under a tenth of a percent. Solving for that threshold across attacker sizes gives z = 5 at 10%, z = 24 at 30%, and z = 340 at 45%. The transaction’s own block plus five more is six confirmations. That is where the number comes from.

The wiki records the assumption in one sentence: six “was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable.” The original client displayed a transaction as unconfirmed until it was six blocks deep. The developer guide keeps the convention: “software handling high-value transactions, or otherwise at risk for fraud, should wait for at least six confirmations before treating a payment as accepted.” The wiki also notes the obvious caveat: six is more than enough against a casual attacker and not enough against one with a large share of the network, which is what our 51% attack article covers.

A reorg is the network changing its mind about the last few blocks

Two miners sometimes find a block at nearly the same moment. The white paper describes what happens: nodes “work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.” The developer guide gives the modern rule: nodes “always follow the most difficult chain to recreate and throw away stale blocks belonging to shorter forks.” Stale blocks, it adds, are “also sometimes called orphans.”

That switch is a reorganization. A transaction from a displaced block may already be included on the new branch, may become pending again if its inputs remain available, or may conflict with a spend now confirmed there. Inspect the accepted chain rather than assume that every displaced transaction simply returns to the same queue.

A reorg does not edit a block. The old block still exists; the network simply stops building on it. The site’s dossier on how the blockchain works walks through what a node does at that moment: disconnect the losing blocks, reverse their changes to the set of spendable outputs, and connect the winners.

It has happened at scale: the March 2013 fork

The best-documented deep reorg was not an attack. In March 2013, as BIP50, the post-mortem written by Gavin Andresen, records, a block that was valid under the rules turned out to be unprocessable by older software: “Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but otherwise valid blocks.” Nodes running version 0.8 accepted the block; older nodes rejected it. Two chains grew side by side, each with confirmations of its own.

The resolution was deliberate. “In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block.” That “placed majority hashpower on the chain without the larger block, thus eventually causing the 0.8 nodes to reorganise to the pre-0.8 chain.” Every confirmation on the abandoned branch evaporated. BIP50 also notes that “during this time there was at least one large double spend,” which it attributes to someone experimenting rather than stealing.

The lesson for anyone counting confirmations is that the count assumes everyone agrees on the rules. When software disagrees, blocks can pile up on a branch that is later thrown away. The site’s consensus incidents dossier sets this event beside the 2010 overflow bug and the 2015 BIP66 fork and explains what each one taught.

Why Bitcoin has no absolute finality

Some newer systems mark a block as final, after which their rules forbid replacing it. Bitcoin has no such flag. The rule is always the same: among the chains a node considers valid, follow the one with the most accumulated work. A block that is a thousand deep could in principle be replaced by a heavier chain that excludes it. What protects it is not a rule but a cost: redoing a thousand blocks of work faster than the entire network adds new ones. The white paper’s phrase is that the attacker’s chances “become vanishingly small as he falls further behind,” not zero.

The design is deliberate, and the paper’s abstract says why: nodes “can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.” A node that has been offline needs no one’s permission to catch up; it just follows the work. A finality flag would need someone to set it.

The protocol’s own caution shows in one rule. The wiki notes that “freshly-mined coins cannot be spent for 100 blocks,” and that some older clients did not show them as confirmed until 120; the developer guide gives the consensus rule as “at least 100 blocks.” Even the network’s own reward waits far longer than six. For a payment between people, six confirmations, about an hour at the average block time, is the convention. For what a confirmation actually secures, see our articles on proof of work and double spending.