A Bitcoin payment passes through several states rather than moving directly from one account to another. A wallet constructs and signs a transaction, nodes check and relay it, miners may select it for a candidate block, and later blocks add confidence that the resulting history will remain accepted.
The word confirmed compresses this whole process into one label. It is more useful to ask how many blocks include or follow the transaction, whether an alternative spend was possible before inclusion, what fee conditions affected selection, and what settlement confidence the recipient actually needs for the value at risk.
What you will learn
- Trace a transaction from inputs and signatures to block inclusion
- Distinguish node relay policy from block validity and settlement confidence
- Choose confirmation expectations based on value, urgency, and replacement risk
A wallet assembles a state transition
A wallet chooses one or more unspent transaction outputs as inputs, specifies new outputs for recipients and change, estimates a fee, and produces the required signatures. Inputs must cover outputs plus the fee. Any leftover value not explicitly assigned to an output becomes fee, so correct change construction is critical.
The signed transaction does not contain an instruction to debit a named account. It identifies earlier outputs and supplies data satisfying their spending conditions. This structure allows every node to verify authorization and conservation of value from public history without knowing the real-world identities of sender or recipient.
Broadcast and independent admission checks
The wallet sends the serialized transaction to one or more nodes, which check signatures, input availability, size and script constraints, fee policy, and conflicts with transactions they already know. A node that accepts it may store it in its mempool and announce it to peers, allowing propagation across the network.
Mempool acceptance is not identical to consensus validity. Nodes can apply stricter local relay rules to reduce spam or resource use, while a miner may include a transaction that is valid under consensus but was not relayed by a particular node. Conversely, mempool presence never guarantees eventual block inclusion.
Miners select transactions under constraints
Miners build blocks with limited weight and generally seek fee revenue, so fee rate matters more than absolute fee. Fee rate compares the fee to the transaction's virtual size. A large transaction paying more total satoshis can still be less attractive than a compact transaction paying a higher rate per virtual byte.
Selection is complicated by dependencies. A child transaction cannot be mined before its unconfirmed parent, so miners may evaluate the combined fee and size of a package. They can also apply policies unrelated to fee maximization, and no protocol rule requires a specific miner to include a particular valid transaction.
Confirmations accumulate, but risk is contextual
The first confirmation means a transaction appears in an accepted block. Each block built afterward adds another confirmation and more proof of work over that history. A competing block can occasionally replace the latest block, while replacing a deeply buried transaction generally requires much more sustained work.
Recipients should treat confirmation thresholds as risk controls, not magic numbers. A small in-person purchase, an exchange deposit, and a high-value irreversible sale face different incentives and consequences. They should also consider whether an unconfirmed payment signals replaceability, whether inputs are themselves confirmed, and whether fraud monitoring is available.
Stuck transactions can sometimes be repriced
Replace-by-fee uses a conflicting transaction that spends at least one of the same inputs while satisfying a node's replacement policy. Bitcoin Core 29 makes full-RBF its standard mempool behavior, so the original transaction does not need to signal opt-in replaceability for Core 29 to consider a qualifying replacement. The policy is local rather than a consensus rule, and miners or other node software may make different choices.
Another technique is child-pays-for-parent: someone controlling an output from the low-fee transaction creates a high-fee child. A miner may include both because their combined fee rate is attractive. Availability depends on wallet support, node policy, transaction structure, and whether the relevant output can be spent.
Common misconceptions
“A broadcast transaction is final because every node has seen it.”
Broadcast only distributes a candidate transaction. Before confirmation it may be replaced, conflict with another spend, be evicted from mempools, or remain unmined.
“One confirmation eliminates every possibility of reversal.”
One confirmation materially improves settlement confidence, but shallow chain reorganizations can occur. Appropriate depth depends on the transaction's value and adversarial incentives.
“The transaction with the largest total fee is always mined first.”
Miners usually compare fee rate and package economics under block weight constraints. They retain discretion, and transaction dependencies can alter selection order.
Risks and limitations
- Accepting an unconfirmed transaction as irreversible exposes the recipient to replacement, conflicting spends, propagation differences, and unexpected miner selection.
- Choosing too low a fee during congestion can delay inclusion, while an accidental fee or missing change output can irreversibly overpay miners once confirmed.
- Address or amount errors are generally not reversible by an administrator; recovery depends on cooperation from whoever controls the destination key, if anyone.
- Confirmation counts do not address exchange insolvency, stolen wallet keys, fraudulent counterparties, or legal disputes outside the protocol.
Key takeaways
- Transactions consume earlier outputs and create new recipient and change outputs.
- Nodes validate and relay independently; their mempools are not a single official queue.
- Miners generally compare fee rate and package value under block limits.
- Each additional block increases settlement confidence by adding proof of work.
- Replacement and fee-bumping behavior matters until a transaction is confirmed.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.