Bitcoin Transaction Lifecycle: From Creation to Confirmation

Every Bitcoin transfer follows the same path: construct, sign, broadcast, wait, confirm. The process seems simple from the outside, but each stage involves cryptographic verification, network propagation, economic incentive alignment, and probabilistic finality. Understanding this lifecycle is essential for anyone building on Bitcoin or debugging stuck transactions.

This article walks through each stage of a Bitcoin transaction, from UTXO selection to block inclusion, covering the technical details that determine whether your transaction confirms in ten minutes or ten hours.

Step 1: Input Selection

Bitcoin does not have account balances. Instead, your wallet holds a set of unspent transaction outputs (UTXOs), each representing a discrete amount of bitcoin locked to your address. To send a payment, your wallet must select which UTXOs to spend as inputs.

Input selection (often called coin selection) is a non-trivial optimization problem. The wallet needs to find a combination of UTXOs that covers the payment amount plus fees, while minimizing waste. Common strategies include:

• Branch and Bound: searches for an exact match to avoid creating change outputs, reducing fees and improving privacy
• Largest-First: greedily selects the biggest UTXOs, simple but often produces large change outputs
• Random selection with multiple iterations: picks random combinations and keeps the best result
• Knapsack: approximates the subset-sum problem, used in Bitcoin Core before Branch and Bound was adopted

Poor coin selection leads to dust outputs that cost more to spend than they are worth, or unnecessarily large transactions that overpay in fees. Wallets tracking many small UTXOs (common with mining payouts or frequent receives) face particular challenges here. The address gap limit in HD wallets also affects which UTXOs your wallet even discovers.

Step 2: Output Construction

Once inputs are selected, the wallet constructs the transaction outputs. A typical transaction has two outputs: one paying the recipient and one returning change to the sender. The output specifies an amount and a locking script (scriptPubKey) that defines the conditions for spending.

Output types

The locking script format depends on the address type. Modern wallets default to SegWit or Taproot outputs, which are more fee-efficient than legacy formats.

The total output value must be less than the total input value. The difference becomes the transaction fee, paid implicitly to miners. There is no explicit fee field in Bitcoin transactions: fee = sum(inputs) - sum(outputs).

Change output ordering: Which output is the payment and which is the change is not labeled in the transaction. Randomizing output order (BIP 69 or random shuffling) prevents trivial change detection by chain analysis firms. Wallets that always place change last leak privacy. Run an address privacy audit to see how much any address exposes.

Step 3: Fee Estimation

Bitcoin block space is a scarce resource. Each block can hold approximately 4 million weight units (about 1 to 1.5 MB of serialized data). When demand exceeds supply, transactions compete for inclusion by offering higher fee rates, measured in satoshis per virtual byte (sat/vB).

Fee estimation involves predicting what fee rate will get your transaction confirmed within a target number of blocks. Bitcoin Core's built-in estimator uses historical data about which fee rates led to confirmation within N blocks. Third-party estimators like mempool.space provide real-time mempool analysis.

The fee market is dynamic and sometimes volatile. During periods of high demand (market events, NFT mints, inscription waves), fee rates can spike from single-digit sat/vB to hundreds. Transactions constructed with low fee rates during these spikes may remain unconfirmed for hours or days.

Transaction size and weight

Fee rates are applied to the transaction's virtual size (vsize), not its raw byte size. The witness data introduced by SegWit receives a 75% weight discount, making SegWit and Taproot transactions cheaper per input. A typical single-input, two-output P2WPKH transaction weighs about 141 vbytes. Adding more inputs increases both the transaction weight and the total fee.

Step 4: Signing

With the transaction structure finalized, each input requires a digital signature proving authorization to spend it. The signing process differs based on the script type:

• Single-key (P2PKH, P2WPKH): the wallet signs with the private key corresponding to the input's address using ECDSA
• Taproot key-path (P2TR): the wallet signs with a Schnorr signature, which is smaller and enables batch verification
• Multisig: multiple parties must sign, either through traditional OP_CHECKMULTISIG or newer approaches like MuSig2
• Hardware wallets: the unsigned transaction is sent to the signing device, which displays the details for user verification before signing

PSBT: Partially Signed Bitcoin Transactions

PSBT (BIP 174) standardizes how unsigned and partially signed transactions are passed between devices and signers. A PSBT bundles the raw transaction with metadata that signers need: UTXO data, derivation paths, redeem scripts. This is critical for cold storage workflows and multisig setups where the signing device is air-gapped from the network.

The workflow follows a create-sign-combine-finalize pattern. The coordinator creates the PSBT, each signer adds their signature, a combiner merges partial signatures, and a finalizer produces the complete transaction ready for broadcast.

Step 5: Serialization and Broadcast

The signed transaction is serialized into a binary format following the BIP 144 serialization (for SegWit transactions, which includes the marker, flag, and witness fields). The serialized transaction is then broadcast to the Bitcoin peer-to-peer network.

Broadcasting means sending the raw transaction to one or more Bitcoin nodes. This can happen through:

• Your own node: connecting directly to the network gives you full control over broadcast timing and privacy
• Wallet provider: most wallets broadcast through their own nodes or partner infrastructure
• Public APIs: services like mempool.space and Blockstream.info offer transaction broadcast endpoints

Each receiving node validates the transaction independently before relaying it further. Invalid transactions (bad signatures, insufficient funds, non-standard scripts) are rejected and not propagated.

Step 6: Mempool Admission

When a node receives a valid transaction, it enters the mempool: an in-memory pool of unconfirmed transactions. The mempool is not a single global data structure: every node maintains its own mempool with its own policies. This means different nodes may have slightly different views of pending transactions.

Validation checks

Before admitting a transaction to the mempool, a node performs extensive validation:

1. Syntactic validity: the transaction parses correctly
2. Input availability: all referenced UTXOs exist and are unspent (or exist in the mempool as outputs of other pending transactions)
3. Script verification: all input scripts execute successfully
4. No double-spend conflicts: no input is already spent by another mempool transaction (with exceptions for Replace-By-Fee)
5. Fee rate above the node's minimum relay fee (default: 1 sat/vB)
6. Transaction size within limits (standard transactions max 400,000 weight units)

Mempool expiry: Transactions that remain unconfirmed are eventually evicted. Bitcoin Core defaults to removing transactions after 336 hours (14 days) in the mempool. During high-fee periods, low-fee transactions may be evicted even sooner as the mempool fills past the default 300 MB limit and the node drops the lowest-fee-rate transactions first.

Step 7: Network Propagation

After mempool admission, the node announces the transaction to its peers using an inventory (inv) message containing the transaction's txid. Peers that do not already have the transaction request it with a getdata message. This gossip protocol propagates the transaction across the network.

Propagation typically reaches most of the network within seconds, but it is not instantaneous and not guaranteed. Factors that affect propagation:

• Network topology: well-connected nodes propagate faster
• Transaction relay policies: some nodes may have stricter relay rules that filter out certain transaction types
• Compact block relay (BIP 152): miners and nodes use compact blocks to speed up block propagation, which works best when miners already have the transaction in their mempools
• Eclipse attacks: an attacker controlling all of a node's connections can prevent it from seeing or propagating transactions

Step 8: Miner Selection and Block Inclusion

Miners (or more precisely, mining pools) construct candidate blocks by selecting transactions from their mempools. The selection algorithm is straightforward in principle: prioritize transactions by fee rate (sat/vB) to maximize total revenue from the block's limited space.

Block template construction

The actual process is more nuanced than simple fee-rate sorting. Miners must account for transaction dependencies: if transaction B spends an output of transaction A, both must be included together. Bitcoin Core's block assembly algorithm groups dependent transactions into "ancestor packages" and sorts by the package fee rate (total fees / total weight of the ancestor chain).

This package-aware sorting is what makes Child Pays for Parent (CPFP) work: a high-fee child transaction can pull a low-fee parent into the next block because the package fee rate is attractive.

Every candidate block begins with a coinbase transaction that pays the block subsidy plus collected fees to the miner. The miner then fills remaining space with the highest-fee-rate transactions (and their ancestors) until the 4 million weight unit limit is reached.

Step 9: Proof of Work and Block Discovery

With a candidate block assembled, miners begin hashing: repeatedly modifying the block header's nonce and computing its SHA-256d hash until the result falls below the current difficulty target. This is a brute-force search that, on average across the entire network, takes about ten minutes to succeed.

When a miner finds a valid hash, they broadcast the block to the network. Other nodes verify the block (checking proof of work, all transactions, and consensus rules) and append it to their chain. Your transaction, included in this block, now has one confirmation.

Step 10: Confirmation and Probabilistic Finality

One confirmation means your transaction is in a block, but it does not mean it is irreversible. Bitcoin's finality is probabilistic: each additional block makes reversal exponentially more expensive, but never theoretically impossible.

The six-confirmation convention dates to Satoshi's whitepaper, which calculated that an attacker with less than 50% hashrate has a vanishingly small probability of reversing a transaction after six blocks. For an attacker with 10% of network hashrate, the probability of catching up after six blocks is approximately 0.0002%.

When Transactions Get Stuck

Fee estimation is imperfect, and fee markets are volatile. Transactions broadcast with fee rates that seemed adequate can become stranded as conditions change. Two mechanisms exist for unsticking transactions:

Replace-By-Fee (RBF)

RBF (BIP 125) allows the sender to replace an unconfirmed transaction with a new version paying a higher fee. As of Bitcoin Core 28.0, full RBF is enabled by default: any unconfirmed transaction can be replaced by a conflicting one with a higher fee rate, regardless of whether the original signaled replaceability.

RBF is the sender's tool. Only the party controlling the inputs can create a valid replacement. The replacement must pay a higher absolute fee and a higher fee rate, and it must not introduce new unconfirmed inputs.

Child Pays for Parent (CPFP)

CPFP allows anyone who can spend an output of the stuck transaction (typically the recipient via the change output, or the receiver) to create a high-fee child transaction. Miners evaluate the parent-child package together, and if the combined fee rate is attractive enough, both transactions get included.

CPFP is particularly useful for recipients who want to accelerate an incoming payment. Anchor outputs in Lightning commitment transactions are specifically designed to enable CPFP fee bumping, using ephemeral dust outputs that anyone can spend for this purpose.

The Zero-Conf Problem

For many use cases, waiting ten minutes (let alone an hour) for confirmation is impractical. Point-of-sale payments, vending machines, and real-time transfers all require faster settlement. This is the fundamental tension of Bitcoin's design: security comes from proof of work, and proof of work takes time.

Accepting unconfirmed (zero-conf) transactions is possible for small amounts, but it carries double-spend risk. Full RBF makes this risk more concrete: any unconfirmed transaction can now be replaced. Merchants accepting zero-conf must account for this, either by accepting the risk on small amounts or by using payment protocols that provide additional guarantees.

Layer 2: Skipping the Queue

Layer 2 protocols exist precisely because the on-chain lifecycle described above is too slow and expensive for many applications. The Lightning Network moves payments off-chain into payment channels, settling to L1 only when channels open and close. This eliminates mempool waiting for most payments but introduces its own complexity: liquidity management, inbound capacity constraints, and the requirement to be online to receive.

Spark takes a different approach. Transfers on Spark change key ownership rather than creating on-chain transactions. There is no input selection, no fee estimation, no mempool, no block confirmation wait. The transfer completes when the signing ceremony finishes, which takes under a second. Finality is instant and deterministic rather than probabilistic.

This difference matters most for applications where the on-chain lifecycle creates friction: point-of-sale payments, remittances, micropayments, and any scenario where users expect the experience to feel like sending a message rather than filing a transaction.

The Full Picture

Understanding the transaction lifecycle reveals why Bitcoin's base layer is not suited for every payment scenario, and why the design tradeoffs are intentional. Proof of work provides censorship resistance and permissionless settlement, but those properties come at the cost of speed and throughput. Every step in the lifecycle, from UTXO selection to probabilistic finality, serves a purpose in maintaining the network's security guarantees.

For developers, the practical takeaways are clear: use SegWit or Taproot outputs to minimize fees, implement robust fee estimation, signal and handle RBF for stuck transactions, and consider Layer 2 solutions for use cases where confirmation latency is unacceptable. The on-chain lifecycle is not going away: it is the settlement layer that everything else builds on.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.