The life of a transaction

Wonder

1. Why does a node need to verify a transaction before it even knows if it will be mined?
2. What makes one block more ‘real’ than another when two appear simultaneously?
3. Why did six confirmations become a convention, and when is that too many or too few?

Explore

1. The journey begins in the wallet software. The user selects specific unspent transaction outputs (UTXOs) to cover the payment and fee. The wallet constructs a new transaction object, defining inputs that reference previous outputs via their transaction ID and index, and outputs that assign value to recipient addresses or change addresses. Each input is signed with the private key corresponding to its locking script, producing digital signatures that prove ownership without revealing the key itself.
2. The fully signed transaction is serialized into a binary format and broadcast to connected peers over the peer-to-peer network. Upon receipt, each node performs independent validation against consensus rules: it checks that the inputs cover the outputs, verifies cryptographic signatures, ensures no double-spending of existing UTXOs, and validates script logic. If valid according to policy, the node adds the transaction to its local mempool and announces it to peers with ‘inv’ (inventory) messages; peers that lack it request the full transaction with ‘getdata’.
3. Miners continuously monitor their mempools for profitable transactions. They select a set of high-fee-rate transactions to include in a candidate block template, which also contains the coinbase transaction awarding the current block subsidy and collected fees. The miner then performs proof-of-work, hashing the block header repeatedly until finding a hash that meets the network’s current difficulty target. That work makes the block costly to produce and cheap to verify; once found, the block is broadcast across the network.
4. Nodes receiving the new block verify its proof-of-work and transaction validity before appending it to their local copy of the chain. The transactions within this block are now considered confirmed at depth one. Their inputs are marked as spent in the UTXO set, and their outputs become available for future spending after any required lock-times or maturity periods pass. If a competing block appears at the same height, nodes follow whichever branch accumulates the most work; if a short reorganization replaces a block, its transactions return to the mempool unless the new branch already includes them.
5. Security increases with each subsequent block added on top of the confirming block. The whitepaper’s tables show that an attacker with 10% of the hashing power has less than a 0.1% chance of catching up from five blocks behind. Six confirmations, about an hour, became a common convention from this kind of analysis, though the real risk depends on the attacker’s share and the amount at stake. While some merchants accept zero-confirmation payments for small amounts, larger transfers typically wait for multiple confirmations to mitigate the risk of a double-spend attack via chain reorganization.
6. Coinbase transactions, which create new bitcoin from mining rewards and fees, have a special restriction: their outputs cannot be spent until they have 100 confirmations. The rule exists because a coinbase output vanishes if its block is replaced in a reorganization; the delay keeps such coins from spreading into later transactions that would then become invalid. For standard user-to-user transfers, no such delay exists; once confirmed, the outputs are technically spendable, though waiting for further confirmations is a risk management decision based on the value at stake and trust assumptions.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• S. Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System', Section 11 (2008)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10
• Bitcoin Developer Guide, 'P2P Network' documentation