Bitcoin confirmations: how many to wait depending on the context

A Bitcoin transaction moves through stages : 0 confirmations when sent, 1 confirmation after the first block including it (about 10 minutes on average), 6 confirmations after about an hour. This progression is familiar to every user, but it remains mysterious. Why wait, since the transaction is technically "in the blockchain×BlockchainA public, shared ledger that records every Bitcoin transaction in blocks linked together cryptographically. Each participant in the network keeps a copy.See in the lexicon →" from the first inclusion ?

The answer lies in Bitcoin's probabilistic finality. A block can be displaced by a longer concurrent chain (reorganisation). The deeper a transaction is buried under additional blocks, the more prohibitive the economic cost of a reorganisation becomes. One confirmation is enough for a coffee, six for an exchange×ExchangeService that lets you buy, sell and swap cryptocurrencies against fiat money. Examples : Kraken, Coinbase, Bitstamp, Bitvavo. Most are custodial.See in the lexicon → withdrawal, three or six for an apartment depending on the emerging notarial protocols.

This article breaks down what a confirmation is, computes the reorganisation probability at each stage, explains why a merchant can accept zero confirmation (and when it is dangerous), distinguishes Lightning (instant finality by game-theory) from on-chain, and gives practical thresholds per context (coffee, mid-size purchase, large transfer, real estate).

A confirmation, what it is exactly

The word "confirmation" is misleading. It suggests that an authority validates the transaction, the way a bank validates a transfer. In reality, on Bitcoin, a confirmation is a passive fact: it is the number of blocks mined since (and including) the one containing your transaction.

The unfolding is clear in four steps.

• Broadcast (0 confirmation). You sign and broadcast the transaction. It enters the mempool of nodes receiving it. It exists but is not in any block.
• Inclusion (1 confirmation). A miner×MinerComputer or farm of computers that solves the cryptographic puzzle required to add a new block to the blockchain, in exchange for a bitcoin reward.See in the lexicon → finds a valid block including your transaction among ~2,500 others. They broadcast that block to the network. All nodes verify×Don't trust, verifyBitcoiner mantra. Trust no one (bank, government, exchange, influencer), verify on your own through your own node.See in the lexicon → its validity against consensus rules, add it to their chain copy, and mark your transaction as "1 confirmation".
• Stacking (2, 3, ... confirmations). Each block mined after the one containing you adds 1 confirmation. The average pace is 1 block every 10 minutes, but the real distribution is exponential: regularly seeing 1-minute blocks and 40-minute gaps. On average, 6 confirmations take ~60 minutes, but that delay can be 30 minutes or 2 hours depending on luck.
• Automatic verification. Every Bitcoin node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → permanently verifies that its chain copy respects consensus rules: valid signatures, coherent amounts, no double-spend, valid proof-of-work for each block. If a longer chain arrives, the node switches to it. This permanent decentralised verification gives meaning to confirmations.

Three consequences to absorb.

• Nobody grants confirmations. No actor says "OK, I validate". Confirmations are merely a counter: how many blocks were mined since yours. That counter expresses the cumulative computational effort an attacker would have to redo to rewrite history.
• A transaction is never lost in the blockchain×BlockchainA public, shared ledger that records every Bitcoin transaction in blocks linked together cryptographically. Each participant in the network keeps a copy.See in the lexicon →. Once confirmed, it stays forever. The only way to "cancel" it would be for a longer alternative chain, without your transaction, to become the official chain (reorganisation, cf. next section).
• The wallet×WalletSoftware or device that manages your Bitcoin keys and lets you sign transactions. A wallet does not really « hold » your bitcoins, it holds the keys that prove you own them.See in the lexicon → is just a reader. When your wallet shows "3 confirmations", it queries a Bitcoin node (its own or that of Electrum/Mempool×MempoolWaiting area where Bitcoin transactions sit before being included in a block. The fuller the mempool, the higher the fees required.See in the lexicon →/your provider) which answers "your transaction is in block 875,432, the current block is 875,435, hence 3 confirmations". If the wallet is disconnected or the node lies, the display is wrong, but the blockchain itself remains authoritative.

Why to wait: chain reorganisation

If a confirmation is just a block mined after yours, why wait for 6 or 100? For one reason: chain reorganisation, or "reorg×Reorg (reorganisation)Rare event in which a longer chain replaces the most recent blocks. Affected transactions have to be re-mined. This is why you wait for several confirmations.See in the lexicon →". Understanding this mechanism is understanding all Bitcoin security.

The base scenario is simple. Two miners find a valid block almost simultaneously, 30 seconds apart, in different parts of the world. For a few seconds, two versions of the blockchain×BlockchainA public, shared ledger that records every Bitcoin transaction in blocks linked together cryptographically. Each participant in the network keeps a copy.See in the lexicon → coexist: chain A (containing Tokyo miner×MinerComputer or farm of computers that solves the cryptographic puzzle required to add a new block to the blockchain, in exchange for a bitcoin reward.See in the lexicon →'s block) and chain B (containing São Paulo miner's block). Each node×NodeComputer that runs the Bitcoin software and takes part in the network by validating blocks and transactions. A « full node » keeps a complete copy of the blockchain.See in the lexicon → adopts the first one it receives. The network is temporarily "split".

The Bitcoin consensus rule resolves this ambiguity: the valid chain is the one accumulating the most work (proof-of-work). At the next block, a miner somewhere extends chain A or chain B. Say they extend A. Now chain A is one block ahead. By the rule, all nodes switch to A. Chain B's block is "orphaned". The transactions it contained, if they were not also in chain A, go back to the mempool×MempoolWaiting area where Bitcoin transactions sit before being included in a block. The fuller the mempool, the higher the fees required.See in the lexicon →.

That is a reorg. Concretely, four consequences.

• If your transaction was only in the orphan block, it becomes unconfirmed again. It is still valid, will stay in the mempool, will be included in a future block. But the "confirmation" you had has evaporated.
• If your transaction was in both blocks (most frequent case in practice, since miners pick from the same mempool), no change. It is confirmed in the winning chain.
• A malicious actor can intentionally cause a reorg: that is the "51 %" or "double-spend" attack. The attacker secretly mines a parallel longer chain that excludes their own outgoing transaction. When they publish it, the network switches. The victim, believing they had received a confirmed payment, sees the transaction cancelled.
• The more confirmations a transaction has, the more expensive a reorg to cancel it. To reverse a 1-confirmation transaction, you must secretly mine 2 blocks. For 6 confirmations, mine 7 faster than the rest of the network mines its 6. For 100 confirmations, mine 101 faster. With each extra confirmation, the effort grows geometrically.

In practice, reorgs on Bitcoin are extremely rare and always shallow. Since 2013, no reorg has exceeded 1 or 2 blocks. Tools like mempool.space count them in near real time. The last 6-block reorg on the main network dates from 2010, before Bitcoin had real economic value. Since then, miners are too numerous, too well distributed and too invested for such depth to be reachable.

Reorg probabilities by attacker hashrate

Satoshi Nakamoto×Satoshi NakamotoPseudonym of the creator (or collective) behind Bitcoin. Active on forums from 2008 to 2011, then vanished without revealing any identity. Holds roughly 1.1 million BTC that have never moved.See in the lexicon → computed in section 11 of the whitepaper×Whitepaper (white paper)Nine-page founding document published by Satoshi Nakamoto on 31 October 2008, "Bitcoin: A Peer-to-Peer Electronic Cash System". It describes how the network works, ahead of its launch in January 2009.See in the lexicon → (2008) the probability that an attacker holding fraction q of total hashrate×HashrateTotal computing power deployed by miners, measured in hashes per second (EH/s, exahashes). The higher the hashrate, the more expensive the network is to attack.See in the lexicon → can rewrite n blocks. The calculation is rigorous (Poisson distribution) and remains valid in 2026. The table below gives practical probabilities.

Three important readings of this table.

• For a small attacker (10 % of hashrate, that is ~75 EH/s in 2026), 6 confirmations make the attack near-impossible (1 chance in 5,000). Beyond 10 confirmations, you enter territories of astronomically small probabilities. That is why the historical "6 confirmations" standard is solid for the vast majority of cases.
• For a medium attacker (25 %, that is ~190 EH/s), one must move up to 10-30 confirmations to reach the same security. No known entity holds 25 % of Bitcoin hashrate in 2026 (the largest pool, Foundry USA, peaks at ~28 % with regular drops, and is anyway not a single actor but a coordination of independent miners).
• For a 40 % attacker, the cost becomes huge even at 100 confirmations, but remains theoretically nonzero. That is why no proof-of-work chain offers 100 % absolute finality. Bitcoin security rests on the economic impossibility of the attack, not its mathematical impossibility.

Three practical additions to interpret these numbers well.

• The opportunity cost of a 51 % attacker is colossal. Attacking at 51 % requires owning or leasing ~380 EH/s of hashrate, i.e. the equivalent of 4 million Bitmain S21 Pro. Capex ~10 billion EUR. During the attack, the attacker no longer mines for the honest network, hence loses block rewards (~3 BTC × 6 blocks/h × 24 h = ~430 BTC per day, ~25 million EUR per day). For a credible attack targeting ~10 confirmations, you need to hold 2 to 3 hours, so ~3 million EUR direct cost. To be added to capex and probable BTC price collapse (market reaction to the attack).
• Satoshi×Satoshi (sat)The smallest unit of bitcoin. 1 BTC = 100 million satoshis. Named after the creator. In 2026, talking in sats becomes common as the price of one BTC rises.See in the lexicon →'s calculation assumes the attacker is honest on the rest. In practice, mining×MiningProcess of validating blocks through proof of work. Consumes electricity by design : that is what secures the network.See in the lexicon → pools are monitored in real time and any suspicious concentration (above 33 %) triggers voluntary hasher migration to other pools. Honest hashrate is therefore self-regulated.
• The table assumes the attacker's transaction is in block 1 of their secret chain. If it is in block 5, the calculation changes: the attacker must not only have 5 blocks in reserve, but also keep mining while the honest chain lengthens. The more recent the targeted transaction on the attacker's side, the more complicated the attack.

Standards by context: how long to wait

Probability theory gives abstract security. Practice answers: how many confirmations for my concrete case? The grid below reflects usage observed in 2026 and crosses four parameters: stake amount, irreversibility of the exchanged good, trust in the counterparty, urgency.

Three useful observations on this table.

• The "6 confirmations" standard is historical but often oversized. It dates from 2010 when hashrate×HashrateTotal computing power deployed by miners, measured in hashes per second (EH/s, exahashes). The higher the hashrate, the more expensive the network is to attack.See in the lexicon → was a few TH/s and a single attacker could theoretically emerge. In 2026, at 750 EH/s spread across 12+ independent pools, 3 confirmations widely suffice for 99 % of common cases. But since the custom is entrenched and the cost of waiting 30 extra minutes is low, 6 remains the conservative norm.
• Risk/cost asymmetry dominates. For a 5 EUR coffee, losing the transaction (double-spend) costs 5 EUR. Waiting for 1 confirmation makes the customer hang around for 10 minutes. The merchant rules for "I accept 0 conf". For a 50,000 EUR withdrawal, losing the transaction costs 50,000 EUR. Waiting 30 more minutes costs almost nothing. The exchange rules for 3 confirmations.
• Knowing the counterparty changes everything. If the P2P seller is your cousin, 0 confirmation suffices (you do not suspect them of double-spend). If it is an unknown LocalBitcoins counterparty, you wait for 3. That "trust" dimension does not appear in any Satoshi×Satoshi (sat)The smallest unit of bitcoin. 1 BTC = 100 million satoshis. Named after the creator. In 2026, talking in sats becomes common as the price of one BTC rises.See in the lexicon → formula, but it dominates in practice for small amounts.

Economic vs cryptographic finality: the real framework

The discussion about confirmations hides a fundamental conceptual distinction: cryptographic finality does not exist on Bitcoin, only economic finality exists. Understanding this nuance avoids many confusions.

Cryptographic finality would be the idea that at a precise moment, a transaction becomes mathematically impossible to cancel. That is what some proof-of-stake chains like Ethereum offer (with "finalized" blocks signed by 2/3 of validators) or BFT chains (Cosmos, Algorand). On Bitcoin, never. The probability of reversing a transaction shrinks exponentially with confirmations, but never strictly reaches zero.

Economic finality is the idea that at a precise moment, attacking a transaction costs more than any reasonable gain. Concretely: if reversing a transaction costs 25 million EUR in sacrificed hashrate×HashrateTotal computing power deployed by miners, measured in hashes per second (EH/s, exahashes). The higher the hashrate, the more expensive the network is to attack.See in the lexicon → and the transaction concerns 50,000 EUR, the attack is economically absurd. Beyond 6-10 confirmations, any transaction below a few million euros is in economic finality. Beyond 100 confirmations, any transaction of a few billion euros is too.

Three practical implications.

• Bitcoin is not inferior to cryptographic-finality blockchains, it makes a different bet. Ethereum says "after 32 validation epochs, it is mathematically final". Bitcoin says "after 6 blocks, it is economically untouchable, and that is enough". The Bitcoin bet is that no rational attacker will pay 25 million to gain 50,000. History has proved it right for 17 years.
• Economic finality evolves with hashrate and price. The higher the hashrate (EH/s), the more expensive an attack. The higher the BTC price, the more expensive the sacrificed rewards during the attack. In 2010, Bitcoin was mathematically vulnerable because hashrate was low. In 2026, it is economically invulnerable to any attack costing less than several tens of billions EUR.
• Lightning offers immediate finality under a different economic guarantee. A Lightning payment is definitive the second the recipient confirms receipt (proof of payment). That finality rests on Lightning channels being secured by multisig×Multisig (multi-signature)Configuration where a transaction must be signed by several independent keys to be valid (for example 2 of 3). Reduces the risk that a single key theft causes loss of funds.See in the lexicon → Bitcoin UTXOs: if someone cheats, the victim can recover their funds via a "justice transaction" within the challenge window (typically 144 blocks, that is ~24 h). It is a conditional but immediate finality, perfect for daily payments where you need to leave fast with the coffee.

Summary table of this philosophical difference.

False scenarios to avoid and historical reorgs

Three erroneous beliefs circulate about Bitcoin confirmations and create as many bad decisions. Dismantling them helps reason rightly.

• False n°1: "0 confirmation is fully safe if I see the transaction in the mempool×MempoolWaiting area where Bitcoin transactions sit before being included in a block. The fuller the mempool, the higher the fees required.See in the lexicon →." False. As long as the transaction is not in a block, the sender can technically broadcast a competing transaction more advantageous to miners (RBF×RBF (Replace-By-Fee)Mechanism that lets you replace an unconfirmed transaction with a new one carrying higher fees, in order to speed it up.See in the lexicon → mechanism, replace-by-fee). That competing transaction is a "double-spend": it spends the same inputs to another address. If it enters a block before yours, you received nothing. Real but limited risk: the sender must be malicious and technically competent. Acceptable for a 10 EUR coffee, dangerous for 5,000 EUR.
• False n°2: "A transaction unconfirmed for 24 h is stuck for good, my funds are lost." False. An unconfirmed transaction is just waiting, either because its fees are too low or because the mempool is saturated. Three outcomes: it gets confirmed later (mempool empties), it gets "bumped" via RBF or CPFP×CPFP (Child Pays For Parent)Alternative to RBF where a high-fee child transaction pulls its stuck parent out of the mempool.See in the lexicon → (cf. fees article), or it expires after ~14 days and nodes drop it, freeing the inputs. In all cases, funds never leave the originating address without a valid signature.
• False n°3: "My exchange×ExchangeService that lets you buy, sell and swap cryptocurrencies against fiat money. Examples : Kraken, Coinbase, Bitstamp, Bitvavo. Most are custodial.See in the lexicon → has confirmed reception, so it is definitive." False with nuance. Most exchanges credit the internal balance before on-chain confirmations to improve UX. But they block withdrawal until their internal threshold is reached (3 or 6 confirmations). In case of reorg×Reorg (reorganisation)Rare event in which a longer chain replaces the most recent blocks. Affected transactions have to be re-mined. This is why you wait for several confirmations.See in the lexicon →, your deposit can be cancelled even if displayed "credited". It happened to Bitfinex users in 2014 and a few exchanges on contested forks. The prudent rule: do not trade / withdraw until the exchange has reached its internal confirmation threshold.

On historical reorgs, two documented episodes on Bitcoin mark minds.

• March 11, 2013 reorg (24 blocks, the worst ever observed). A compatibility bug between Bitcoin 0.7 and 0.8 temporarily split the network. For ~6 h, two chains coexisted. Developers coordinated the rallying to the 0.7 chain. Result: a single fraudulent transaction took advantage of a double-spend (OKPay, ~10,000 USD), which was voluntarily reimbursed a few days later. No final user loss.
• Occasional 1-2 block reorgs (several per year). Mempool.space×mempool.spaceReference open-source Bitcoin explorer in 2026. Visualisation of blocks, fees and the mempool. Launched by Wiz and the mempool.space team.See in the lexicon → stats over 2024-2025: ~5 to 10 single-block reorgs per year, 1 or 2 two-block reorgs per year, 0 reorg of 3 blocks or more. A 1-block reorg only threatens transactions at 0 or 1 confirmation, which is exactly the zone where contextual standards recommend the greatest caution.

Alongside, some proof-of-work chains with less hashrate×HashrateTotal computing power deployed by miners, measured in hashes per second (EH/s, exahashes). The higher the hashrate, the more expensive the network is to attack.See in the lexicon → have suffered deep reorgs in real attacks. Bitcoin Gold experienced a 18 million USD double-spend via a 22-block reorg in 2018. Ethereum Classic suffered 3 51 % attacks in 2020, including one 4,000+ block reorg. These chains share a hashrate much lower than Bitcoin (under 1 %) and the use of the same hashing algorithm as larger chains (which lets one rent hashrate elsewhere to attack). Bitcoin escapes both weaknesses: massive hashrate and SHA-256×SHA-256Hash algorithm used by Bitcoin for proof of work and block hashing. Produces a 256-bit fingerprint (64 hexadecimal characters).See in the lexicon → algorithm where the vast majority of worldwide capacity is dedicated to Bitcoin itself.