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

A transaction in the current accepted Bitcoin chain has one confirmation at inclusion and another for every block built above it. Reversing it requires a competing valid chain with more accumulated proof of work. More confirmations generally reduce reversal risk under stated attacker assumptions; no fixed number provides an unconditional guarantee. Six is a common convention for some payments, not a universal safety threshold.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html)

Canonical: https://degreesofsatoshi.com/encyclopedia/bitcoin-confirmations/
Published: 2026-09-23
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:26:58.075Z

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **One confirmation:** The transaction is in the latest block; each later block adds one ([Confirmation](https://en.bitcoin.it/wiki/Confirmation))
- **Average block time:** 10 minutes, with wide variation from block to block ([Confirmation](https://en.bitcoin.it/wiki/Confirmation); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html))
- **Six-confirmation convention:** Six is a payment convention. The white paper’s simplified model makes risk conditional on attacker hash share and block lead ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html))
- **Developer guidance:** High-value or fraud-prone software should wait for at least six confirmations ([Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html))
- **Bigger attackers:** In the paper’s model, z = 24 at q = 0.30 and z = 340 at q = 0.45 bring catch-up probability below 0.1%; this is not an unconditional payment guarantee ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf))
- **Newly mined coins:** Cannot be spent for at least 100 blocks ([Confirmation](https://en.bitcoin.it/wiki/Confirmation); [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html))
- **A real deep reorg:** March 2013: version 0.8 nodes reorganized onto the 0.7-compatible chain after pools downgraded (BIP50) ([BIP 50: March 2013 Chain Fork Post-Mortem](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0050.mediawiki))

## 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.

Evidence: [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html)

## 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](/encyclopedia/51-percent-attack/) article covers.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Confirmation](https://en.bitcoin.it/wiki/Confirmation); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html)

## 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](/history/how-bitcoin-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.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html)

## 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](/history/bitcoin-consensus-incidents/) sets this event beside the 2010 overflow bug and the 2015 BIP66 fork and explains what each one taught.

Evidence: [BIP 50: March 2013 Chain Fork Post-Mortem](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0050.mediawiki)

## 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](/encyclopedia/proof-of-work-explained/) and [double spending](/encyclopedia/double-spending/).

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Confirmation](https://en.bitcoin.it/wiki/Confirmation); [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html)

## Questions

### How long does one Bitcoin confirmation take?

About 10 minutes on average for a transaction paying a sufficient fee, according to the developer guide. The average hides a lot of variation: blocks are found at random, so two can arrive within a minute and then none for an hour. A low fee can leave a transaction waiting through many blocks.

Evidence: [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html); [Confirmation](https://en.bitcoin.it/wiki/Confirmation)

### How many confirmations does a Bitcoin transaction need?

The protocol sets no number for ordinary payments. Six is the convention, derived from the white paper’s calculation for an attacker with 10% of the hash power, and the developer guide recommends at least six for high-value transactions. Newly mined coins are the exception: they cannot be spent for 100 blocks.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html); [Confirmation](https://en.bitcoin.it/wiki/Confirmation)

### Can a confirmed Bitcoin transaction be reversed?

Its inclusion can be displaced by a reorganization onto another branch the node accepts. Additional work generally reduces reversal risk under specified attacker assumptions, but no fixed confirmation count is an unconditional guarantee.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html)

### What does unconfirmed mean?

The transaction is not included in the observer’s accepted chain. It may be pending in a node’s mempool, dropped, unknown to that observer or not yet broadcast. An unconfirmed spend can conflict with another transaction.

Evidence: [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html)

### What is an orphan or stale block?

A valid block that lost the race. When two blocks are found at about the same height, nodes follow whichever branch gains more work and, in the developer guide’s words, “throw away stale blocks belonging to shorter forks.” The guide notes such blocks are also sometimes called orphans.

Evidence: [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html)

## Claims and scope

### bitcoin-confirmations-quick-answer

A transaction in the current accepted Bitcoin chain has one confirmation at inclusion and another for every block built above it. Reversing it requires a competing valid chain with more accumulated proof of work. More confirmations generally reduce reversal risk under stated attacker assumptions; no fixed number provides an unconditional guarantee. Six is a common convention for some payments, not a universal safety threshold.

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-one-confirmation

One confirmation: The transaction is in the latest block; each later block adds one

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-average-block-time

Average block time: 10 minutes, with wide variation from block to block

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-six-confirmation-convention

Six-confirmation convention: Six is a payment convention. The white paper’s simplified model makes risk conditional on attacker hash share and block lead

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-developer-guidance

Developer guidance: High-value or fraud-prone software should wait for at least six confirmations

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-bigger-attackers

Bigger attackers: In the paper’s model, z = 24 at q = 0.30 and z = 340 at q = 0.45 bring catch-up probability below 0.1%; this is not an unconditional payment guarantee

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-newly-mined-coins

Newly mined coins: Cannot be spent for at least 100 blocks

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-confirmations-fact-a-real-deep-reorg

A real deep reorg: March 2013: version 0.8 nodes reorganized onto the 0.7-compatible chain after pools downgraded (BIP50)

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

## Sources

- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) — bitcoin.org. Section 4 on redoing work, section 5 on competing branches, and section 11 with the attacker-catch-up table: at q=0.1, z=5 gives P=0.0009; for P under 0.1%, z=5 at 10%, 24 at 30% and 340 at 45%. Locator: Section 4 on redoing work, section 5 on competing branches, and section 11 with the attacker-catch-up table: at q=0.1, z=5 gives P=0.0009; for P under 0.1%, z=5 at 10%, 24 at 30% and 340 at 45%.. Retrieved: 2026-10-02T15:04:11.761440+00:00.
- [Confirmation](https://en.bitcoin.it/wiki/Confirmation) — Bitcoin Wiki. Defines confirmations, records that six was chosen assuming an attacker under 10% of hash rate and 0.1% acceptable risk, notes the 10-minute average is not exact, and gives the 100-block rule for mined coins with 120 in older clients. Locator: Defines confirmations, records that six was chosen assuming an attacker under 10% of hash rate and 0.1% acceptable risk, notes the 10-minute average is not exact, and gives the 100-block rule for mined coins with 120 in older clients.. Retrieved: 2026-10-02T14:48:41.372118+00:00.
- [Payment Processing: Verifying Payment](https://developer.bitcoin.org/devguide/payment_processing.html) — Bitcoin developer guide (developer.bitcoin.org). States that zero-confirmation transactions need risk analysis, that one confirmation takes 10 minutes on average, that high-value software should wait for at least six, and that programs should enter safe mode if a fork exceeds two blocks. Locator: States that zero-confirmation transactions need risk analysis, that one confirmation takes 10 minutes on average, that high-value software should wait for at least six, and that programs should enter safe mode if a fork exceeds two blocks.. Retrieved: 2026-10-02T14:48:41.373881+00:00.
- [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) — Bitcoin developer guide (developer.bitcoin.org). States that nodes follow the most difficult chain and discard stale blocks, also called orphans, and that a coinbase output cannot be spent for at least 100 blocks. Locator: States that nodes follow the most difficult chain and discard stale blocks, also called orphans, and that a coinbase output cannot be spent for at least 100 blocks.. Retrieved: 2026-10-02T14:48:36.834850+00:00.
- [BIP 50: March 2013 Chain Fork Post-Mortem](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0050.mediawiki) — Bitcoin Improvement Proposals (github.com/bitcoin/bips). Records the Berkeley DB lock limit in pre-0.8 nodes, the pool downgrade to 0.7, the resulting reorganization of 0.8 nodes onto the pre-0.8 chain, and at least one large double spend during the split. Locator: Records the Berkeley DB lock limit in pre-0.8 nodes, the pool downgrade to 0.7, the resulting reorganization of 0.8 nodes onto the pre-0.8 chain, and at least one large double spend during the split.. Retrieved: 2026-10-02T15:04:15.104316+00:00.

## Revision history

- 2026-09-23: Initial Bitcoin encyclopedia entry at this permanent URL.
- 2026-10-02: Revised direct answer to preserve source scope and qualifications. Corrected key fact: Six-confirmation convention Corrected key fact: Bigger attackers
- 2026-10-02: Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification.
- 2026-10-02: Expanded explanation: Count the containing block as the first confirmation. Worked examples are illustrative; source checks and independent verification are recorded separately.

## Cite this entry

Degrees of Satoshi editorial project. “Bitcoin confirmations: what they mean, why six became the convention, and why none is final.” Published 2026-09-23; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/bitcoin-confirmations/