Confirmation

Alice sends a friend 20,000 sat, the smallest units of bitcoin. Her wallet says Sent and the friend can already see an incoming payment, but with zero confirmations. There is no contradiction: news of the payment has spread among nodes, the computers verifying Bitcoin, but it is not yet in a block. A Mempool is a node’s local store of unconfirmed transactions, not a single queue shared by the entire network. Once the payment enters an accepted block, it gains its first confirmation. The next block gives it a second, and the next a third. Alice does not need to send anything again. Broadcasting a transaction is not confirmation, and its identifier, the txid, does not guarantee it either. An unconfirmed transaction may be replaced, for example using Replace-by-Fee (RBF) to raise its fee. Accepting payment without confirmation is called zero-conf and means taking the risk that a different spend of the same funds will confirm instead. [4] [8] [11]

A miner selects transactions for a new block and searches for valid Proof of Work, the result of costly computation required by Bitcoin’s rules. Other full nodes then check the block themselves: are signatures, amounts and spending conditions correct, and are the funds still unspent? This is neither a miners’ vote nor one company’s stamp of approval. A miner cannot make an invalid payment valid by putting it in a block. A node counts it as confirmed only on the chain it accepts. Among valid branches it chooses the one with the greatest accumulated work, called chainwork. Each block refers to its predecessor, so changing earlier history also requires rebuilding what follows it. [2] [7]

Bitcoin targets an average of ten minutes between blocks, not a timetable. A new block can arrive in seconds or much later. Waiting an hour does not itself mean six confirmations. A higher fee rate can improve the chance that a miner selects your transaction, but does not make blocks arrive faster. Some wallets offer RBF, replacing an unconfirmed transaction with one paying a higher fee, or CPFP (Child Pays for Parent): a dependent transaction adds enough fees to make it worthwhile for a miner to include it together with its parent. Availability depends on the wallet and transaction. A low fee can mean a long wait or removal from a node’s Mempool. Treat the wallet’s estimate as an estimate, not a promised deadline. [3] [4]

The recipient or service decides how many confirmations it requires before accepting payment. A small purchase can justify a different risk tolerance from handing over expensive goods irreversibly. If an exchange waits for several confirmations, your transaction may already be on the blockchain while your exchange balance has not yet been credited. That does not automatically mean something went wrong. Check the amount, destination and status in your wallet, and the service’s deposit requirements. The source of information matters too. An attacker can isolate a node and feed it a restricted view of the network; this is called an Eclipse Attack. Appropriate waiting therefore depends on value, possible remedies, trust in the other party and how verification is performed. The confirmation count alone cannot protect against a stolen key. [11] [13]

Think of a payment as a record with more pages of history piling up above it. Changing one old page is not enough: an attacker would need to produce a competing valid continuation with enough accumulated work. Under normal assumptions, additional confirmations make that harder. The outcome also depends on the attacker’s computing power and network conditions. The often-cited six confirmations are a historical guideline, not a consensus rule or a magic boundary of complete safety. There is no single fixed probability of history being rewritten that honestly covers every situation. Nor can more confirmations correct a wrong address or a payment to a scammer. [1] [13]

A short-lived split can occur without an attack when two miners find a block almost simultaneously. A node switching to a different winning branch is called a reorganization. A transaction output records an amount and the conditions for spending it; an input in a later transaction refers to that output and spends it. An unspent output is called a UTXO. If a competing valid branch gains more accumulated work, or chainwork, the node disconnects the final blocks of its original chain and connects the winning branch. A transaction from a disconnected block may return to the Mempool if it remains valid, or it may confirm at a different height. It may also become conflicted if the new branch spends the same output referenced by its input. A negative confirmations value in Bitcoin Core is the wallet’s way of expressing conflict depth. It does not mean a negative number of blocks under consensus rules. [5] [7]

Block height is its position in the sequence, counted from the initial block numbered zero. If the transaction’s block is at height h and the last block of the node’s active chain is at height H, the confirmation count is H − h + 1. The block containing the transaction therefore counts as the first. The result depends on that node’s best validated block and may briefly differ between nodes as new blocks arrive. It is not part of the transaction, does not increase merely with the passage of time and cannot reliably be determined from a timestamp. Bitcoin Core returns data such as blockhash, blockheight and confirmations according to the state known to the relevant wallet or UTXO view. [3] [5] [6]

SPV means simplified payment verification, while RPC is a programmatic interface for querying a node. The difference between verification methods matters even when two applications display the same count. A full node validates the chain and answers according to the current end of its own validated chain. An SPV client checks Proof of Work in block headers and a Merkle proof of transaction inclusion, but does not itself verify every consensus rule. A Merkle proof uses a short set of cryptographic fingerprints to show that a transaction is included in a block without downloading all its transactions. A service that holds funds for users also applies its own rules for crediting payments and managing risk. Even an RPC result from a full node captures the state at a particular moment, which a reorganization can change. Beyond the confirmation count, it therefore matters whose chain view, verification and custody of funds the user trusts. [1] [2] [8]

A Coinbase Transaction is a block’s special first transaction paying the miner’s reward; it is unrelated to the Coinbase exchange. A timelock restricts when funds can be spent. BIP identifies a technical proposal or standard document. Confirmation also starts some protocol waiting periods. A coinbase transaction output is subject to COINBASE_MATURITY = 100: it can first be spent in a block whose height is 100 greater than that of the block containing the coinbase transaction. This is a mandatory waiting period before spending a block reward, not a choice made by the recipient of an ordinary payment. BIP68 relative timelocks derive from confirmation of the output being spent and evaluate its age using block-based or time-based rules. A script is a short program that specifies the conditions for spending an output. The CHECKSEQUENCEVERIFY (CSV) instruction from BIP112 allows this relative condition to be enforced in a script. A transaction spending an unconfirmed output still depends on the transaction that created it. For a dependent transaction to confirm, its ancestors must be included in the same block or an earlier one. [9] [10]

Lightning Network allows payments through channels funded by Bitcoin transactions. BOLT names its technical specifications; this section concerns opening a channel, not waiting for a block for every payment inside it. BOLT 2 allows the party accepting a Lightning channel to specify in minimum_depth how many confirmations the funding transaction should have before sending channel_ready. This requirement accounts for the risk of a double-spend of the funding. A channel opened without confirmation, a zero-conf channel, sets minimum_depth to zero and deliberately relies on trust in the funder and on protocol restrictions. It does not gain immediate irreversible settlement. If the funding transaction itself is a coinbase transaction, BOLT 2 requires the party that is not opening the channel to wait at least 100 blocks. The operator should track the specific funding output, or funding outpoint, its depth in the active chain and reorganizations. A broadcast txid alone does not yet mean the channel is open. [12] [14]