Bitcoin Transaction Lifecycle: Creation to Confirmation

How a Bitcoin Transaction Works

Every Bitcoin transaction follows a deterministic lifecycle: it is constructed from unspent outputs, signed with a private key, broadcast to the peer-to-peer network, validated and held in the mempool, selected by a miner for block inclusion, and finally confirmed as part of the blockchain. Each stage introduces specific constraints and failure modes that developers, wallet builders, and users should understand.

This guide walks through every stage of the Bitcoin transaction lifecycle with technically precise detail, covering what happens at each step and what can go wrong.

Lifecycle Stage Overview

The following table summarizes each stage, its typical timing, and the primary risks at that point.

Stage 1: UTXO Selection

Bitcoin does not use account balances. Instead, every wallet tracks a set of unspent transaction outputs (UTXOs), each locked by a script that only the wallet's private key can satisfy. To create a new transaction, the wallet must select one or more UTXOs whose combined value covers the intended payment plus the transaction fee.

Bitcoin Core uses three coin selection algorithms and picks the best result using a waste metric measured in satoshis. Branch and Bound (BnB) searches for an exact-match combination that eliminates the change output entirely, saving ~34 bytes. Knapsack uses randomized selection to minimize change. Single Random Draw (SRD) randomly selects inputs and accepts whatever change results. The wallet evaluates candidates from all three and selects the lowest-waste option.

Poor coin control can leak privacy by linking UTXOs from different contexts in the same transaction, a heuristic exploited by chain analysis firms. It can also waste fees by including tiny dust UTXOs that cost more to spend than they are worth. For guidance on managing your UTXO set efficiently, see the UTXO management guide.

Stage 2: Transaction Construction

A Bitcoin transaction is a data structure with five components: a 4-byte version field, a list of inputs (each referencing a previous TXID and output index), a list of outputs (each specifying a value in satoshis and a locking script), witness data (for SegWit transactions), and a 4-byte locktime field. Version 2 transactions (introduced by BIP 68) enable relative timelocks via the nSequence field.

Each output contains a scriptPubKey that defines the spending conditions. For a standard P2WPKH output, this is a 22-byte script containing the hash of the recipient's public key. For a Taproot (P2TR) output, it is a 34-byte script with the recipient's 32-byte x-only public key. The transaction must ensure every output exceeds the dust threshold: 546 satoshis for P2PKH and 294 satoshis for P2WPKH outputs.

The total transaction weight must stay below 400,000 weight units (100,000 virtual bytes) to qualify as a standard transaction that nodes will relay. Non-standard transactions can still be included in blocks directly by miners, but they will not propagate through the default mempool policy.

Stage 3: Signing

Each input requires a digital signature proving that the spender controls the private key associated with the referenced UTXO. Bitcoin supports two signature algorithms, both operating on the secp256k1 elliptic curve.

Schnorr signatures offer two major advantages: fixed-size signatures save space, and linearity enables MuSig2 key aggregation where multiple signers produce a single 64-byte signature indistinguishable from a single-signer transaction on-chain. This provides both efficiency and privacy improvements for multisig setups.

The sighash flag attached to each signature determines which parts of the transaction are covered by the signature. SIGHASH_ALL (the default) commits to all inputs and outputs, preventing any modification after signing. Other flags like SIGHASH_SINGLE and SIGHASH_ANYONECANPAY enable advanced constructions like CoinJoin and crowdfunding transactions.

Warning: ECDSA nonce reuse is catastrophic. If two signatures from the same private key use the same random nonce, the private key can be algebraically recovered by anyone who observes both signatures on the blockchain.

Stage 4: Serialization

Once signed, the transaction is serialized into raw bytes for transmission. Legacy transactions use a straightforward format: version, input count, inputs, output count, outputs, and locktime. SegWit transactions (BIP 144) insert a marker byte (0x00) and flag byte (0x01) after the version field, with witness data appended after the outputs.

The marker byte ensures legacy nodes interpret a SegWit transaction as having zero inputs, which is invalid, causing them to ignore it rather than misparse it. The transaction ID (txid) is computed from the legacy serialization (without witness data), while the wtxid includes the full serialized form. This separation is the core mechanism of segregated witness: by excluding witness data from the txid, SegWit eliminates transaction malleability.

Stage 5: Broadcasting

The serialized transaction is submitted to one or more connected Bitcoin nodes via the P2P network. Each receiving node validates the transaction against its local policy rules before relaying it to its own peers. Under normal network conditions, a transaction reaches the majority of listening nodes within 1-5 seconds.

Transactions can be broadcast through Bitcoin Core's RPC interface (sendrawtransaction), wallet software, or third-party APIs. Some privacy-focused users broadcast through Tor or use their own full node to avoid revealing their IP address to network observers.

Stage 6: Mempool Acceptance

When a node receives a new transaction, it runs a series of validation checks before admitting it to the mempool. These checks include verifying that all referenced UTXOs exist and are unspent, that signatures are valid, that the transaction weight is within standard limits, and that the fee meets the minimum relay threshold.

The default minimum relay fee has historically been 1 sat/vB (1,000 sat/kvB). Bitcoin Core 29.1 (released September 2025) reduced this default to 0.1 sat/vB (100 sat/kvB), though network-wide adoption is gradual. The default mempool size cap is 300 MB. When the mempool fills during periods of high demand, the lowest fee-rate transactions are evicted first. For current fee estimates, see the fee estimator tool.

If the transaction conflicts with an existing mempool entry (spending the same UTXO), it is either rejected or processed as a Replace-By-Fee (RBF) replacement. As of Bitcoin Core 28.0 (October 2024), full RBF is enabled by default, meaning any unconfirmed transaction can be replaced regardless of whether it signals BIP 125. The replacement must pay a strictly higher absolute fee and a higher fee rate. For more on how RBF works, see the RBF and CPFP comparison guide.

Stage 7: Miner Selection and Block Inclusion

Miners construct a block template by selecting transactions from their mempool, prioritizing those with the highest fee rate (satoshis per virtual byte). The goal is to maximize total fee revenue within the block's weight limit of 4,000,000 weight units, which corresponds to a maximum of 1,000,000 virtual bytes.

A block composed entirely of legacy transactions maxes out at 1 MB. With SegWit transactions, raw block sizes can reach approximately 2-4 MB because witness data receives a 75% weight discount (1 weight unit per witness byte versus 4 per non-witness byte). In practice, average blocks contain a mix of transaction types and typically range from 1.5 to 2.3 MB.

Bitcoin's difficulty adjustment targets one block every 10 minutes, recalculating every 2,016 blocks (approximately two weeks). This means a transaction paying a competitive fee rate should be included in the next block within roughly 10 minutes. During fee spikes, lower-fee transactions may wait hours, days, or remain unconfirmed until fees drop or the transaction is replaced via RBF or boosted with Child-Pays-For-Parent (CPFP).

Stage 8: Confirmation Depth

Once a transaction is included in a valid block, it has one confirmation. Each subsequent block adds another confirmation, increasing the computational cost an attacker would need to reverse the transaction via a chain reorganization. The following table shows industry standards for confirmation requirements.

The 6-confirmation standard was referenced in the original Bitcoin whitepaper as providing a negligible probability of reversal by an attacker controlling less than 50% of network hashrate. No successful double-spend attack has ever been observed against confirmed transactions on the Bitcoin mainnet.

For applications requiring faster finality, layer 2 solutions like the Lightning Network and Spark provide near-instant settlement by moving transactions off-chain and only settling the final state to the base layer. See our research article on Bitcoin transaction mechanics for a deeper analysis.

Transaction Size by Type

Transaction size directly determines the fee you pay, since fees are calculated per virtual byte. The following table shows sizes for a standard 1-input, 2-output transaction across different address types.

P2WPKH has the smallest virtual size for single-input transactions, but Taproot inputs are cheaper to spend individually (57.5 vB vs 68 vB per input), making P2TR more efficient for transactions with many inputs. The transaction decoder can break down the exact byte composition of any raw transaction.

Frequently Asked Questions

How long does a Bitcoin transaction take to confirm?

A Bitcoin transaction typically receives its first confirmation within 10 minutes, matching the average block interval. However, this depends on the fee rate paid. During periods of high demand, a low-fee transaction may wait hours or even days. Paying a competitive fee rate (check the fee estimator for current rates) generally ensures inclusion in the next 1-3 blocks, or 10-30 minutes.

What happens if my Bitcoin transaction is stuck in the mempool?

A transaction stuck in the mempool has not yet been included in a block, usually because its fee rate is too low relative to current demand. You have two options: Replace-By-Fee (RBF) lets you broadcast a replacement transaction with a higher fee if the original signaled replaceability (or if nodes support full RBF). Child-Pays-For-Parent (CPFP) lets the recipient create a high-fee child transaction that incentivizes miners to confirm both. Transactions that remain unconfirmed for 14 days are typically purged from most nodes' mempools.

Can a Bitcoin transaction be reversed after confirmation?

Reversing a confirmed transaction requires a chain reorganization where an attacker produces an alternative chain longer than the current one. This requires controlling more than 50% of the network's hashrate, which represents hundreds of billions of dollars in mining infrastructure. No successful reversal has ever occurred on the Bitcoin mainnet. After 6 confirmations (~60 minutes), a transaction is considered practically irreversible.

What is the difference between txid and wtxid?

The txid is a SHA-256d hash of the transaction data excluding witness fields. The wtxid hashes the complete serialized transaction including witness data. Before SegWit, third parties could modify the signature encoding without invalidating the transaction, changing the txid. By excluding witness data from the txid, SegWit eliminated this transaction malleability issue, which was critical for enabling reliable second-layer protocols like the Lightning Network.

What is the minimum fee for a Bitcoin transaction?

The minimum relay fee determines whether nodes will propagate your transaction. The historical default was 1 sat/vB (1,000 sat/kvB). Bitcoin Core 29.1 (September 2025) reduced this to 0.1 sat/vB (100 sat/kvB), though network-wide adoption depends on how many nodes upgrade. In practice, the fee needed for timely confirmation depends on current mempool congestion and can range from 1 sat/vB during quiet periods to 100+ sat/vB during fee spikes.

How does UTXO selection affect transaction fees?

Each input added to a transaction increases its size and therefore its fee. A P2WPKH input adds approximately 68 virtual bytes, while a P2TR input adds about 57.5 virtual bytes. If your wallet holds many small UTXOs, spending them requires many inputs, making the transaction larger and more expensive. Consolidating UTXOs during low-fee periods and using coin control to select inputs deliberately can significantly reduce costs over time.

What is the maximum Bitcoin transaction size?

The maximum standard transaction weight is 400,000 weight units (100,000 virtual bytes). Transactions exceeding this limit are considered non-standard and will not be relayed by default mempool policy, though miners can still include them in blocks. The minimum transaction size is 82 bytes. These limits exist to prevent denial-of-service attacks against the network.

This guide is for informational purposes only and does not constitute financial advice. Transaction parameters, fee thresholds, and mempool policies can change with Bitcoin Core updates. Always verify current network conditions before broadcasting transactions.