Confirmation

Broadcast is not confirmation. Each node independently applies policy before admitting a transaction to its mempool, and nodes can have different mempools because of timing, fees, conflicts, package limits or policy. RBF may replace an unconfirmed transaction, and a transaction seen by a merchant can disappear without ever entering a block. Zero-conf acceptance therefore exchanges latency for double-spend and network-view risk; a txid or explorer page is evidence of a candidate transaction, not settlement. [Bitcoin Developer Guide — Transactions] [Bitcoin Core — JSON-RPC consistency] [BIP 125 — Opt-in Full Replace-by-Fee]

A miner may select the transaction for a candidate block, but inclusion becomes a first confirmation only when a validating node accepts that block and it lies on the node's active most-work chain. Full nodes verify proof of work, transaction scripts, input availability, amounts and all other consensus rules; miner publication cannot make an invalid spend valid. The containing block commits to the transaction through its Merkle root, while the previous-block link places it in the accumulated proof-of-work history. [Bitcoin Core — Validation] [Bitcoin Core — validation.cpp]

If the containing block is at height h and the node's current tip is H, confirmations equal H − h + 1: the containing block counts as one, not zero. The number is computed relative to that node's best validated block and can briefly differ across nodes near the tip. It is not stored inside the transaction, does not grow with wall-clock time, and cannot be inferred reliably from a block timestamp. Bitcoin Core exposes blockhash, blockheight and confirmations as wallet or UTXO view data. [Bitcoin Developer Guide — Block Chain] [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — getbestblockhash]

When a competing valid branch accumulates more chainwork, a node disconnects blocks from its former tip and connects the winning branch. A transaction from a disconnected block may return to the mempool if still valid, may be confirmed at another height, or may become invalid because the winning branch spends the same input. Bitcoin Core can report negative confirmations for a conflicted wallet transaction; that is a wallet convention describing conflict depth, not negative blocks in consensus. [Bitcoin Core RPC — gettransaction] [Bitcoin Core — validation.cpp]

More confirmations place more accumulated proof of work after the transaction and generally raise the cost and lower the probability of replacing its history. They do not create deterministic finality. The whitepaper's catch-up calculation and later models depend on assumptions including attacker hashrate, honest network behavior and the recipient's observation. “Six confirmations” is a historical rule of thumb, not a consensus constant or a universal safety threshold, and deep reorganizations remain possible in principle. [Bitcoin whitepaper — Proof-of-Work and Calculations] [Rosenfeld — Analysis of Hashrate-Based Double Spending]

A confirmation requirement belongs to the recipient, exchange or protocol, not to the transaction. A coffee, irreversible high-value delivery, exchange deposit and channel opening have different loss and latency trade-offs. Policy should consider value at risk, reversibility, attacker incentives and hashrate, observed conflicts or RBF, custody and backend trust, eclipse risk and unusual chain conditions. Confirmations mitigate chain-replacement risk; they do not fix a stolen key, wrong address, fraudulent counterparty or compromised wallet. [BIP 125 — Opt-in Full Replace-by-Fee] [Rosenfeld — Analysis of Hashrate-Based Double Spending]

Bitcoin targets an average block interval of roughly ten minutes, but proof-of-work arrivals are stochastic: the next block can arrive seconds or hours later. A higher feerate can improve a transaction's position in miners' selection and RBF or CPFP can improve package economics, but no fee buys a fixed confirmation time and it cannot accelerate block production. Low-fee transactions may wait through many blocks or be evicted from mempools, so estimates are probabilities, not deadlines. [Bitcoin Developer Guide — Block Chain] [Bitcoin Developer Guide — Transactions]

A full node validates the chain and can answer against its own active tip. An SPV client checks proof of work in headers and a Merkle inclusion proof but does not independently execute every consensus rule; a custodial service additionally applies its own crediting and risk systems. Even a full node's RPC result is a snapshot that can change on reorg. The security question is therefore not only “how many confirmations?” but also whose chain view, validation and custody are being trusted. [Bitcoin whitepaper — Proof-of-Work and Calculations] [Bitcoin Core — Validation] [Bitcoin Core — JSON-RPC consistency]

Confirmation also starts other clocks. A coinbase output is subject to COINBASE_MATURITY = 100 and can be spent only after 100 new blocks, a rule distinct from ordinary payment policy. BIP68 relative lock times, enforced by BIP112 CHECKSEQUENCEVERIFY (CSV) scripts, measure age from the confirmed output's block. An unconfirmed parent leaves descendants dependent on it; when a child confirms, all required unconfirmed ancestors must also be included in that block or an earlier one. [Bitcoin Core — consensus.h] [BIP 112 — CHECKSEQUENCEVERIFY]

BOLT 2 lets a Lightning acceptor set minimum_depth for a funding transaction before channel_ready; the number prices its funding double-spend risk. A zero-conf channel deliberately sets minimum_depth to zero and relies on trust in the funder plus protocol constraints, not on magical instant finality. Coinbase-funded channels wait for maturity. Operators should monitor the funding outpoint, active-chain depth and reorgs rather than treating a broadcast funding txid as an opened channel. [BOLT 2 — Peer Protocol] [Bitcoin Optech — Zero-conf channels]