How Bitcoin Transactions Work: UTXO, Fees, Mempool and Confirmations

Bitcoin transactions are the fundamental unit of value transfer on the Bitcoin network. This guide explains how Bitcoin transactions work, starting with the UTXO model and moving through inputs and outputs, script behavior, fee calculation, broadcasting to the mempool, and final confirmation in blocks. Understanding Bitcoin transactions helps you evaluate wallet behavior, fee strategies, privacy implications, and how network conditions affect confirmation time. This article focuses strictly on the technical mechanics and operational considerations of Bitcoin transactions without predictions or speculation.

Overview: The UTXO Model vs Account Model

Unlike account-based systems, Bitcoin uses the unspent transaction output or UTXO model. A UTXO is an indivisible chunk of bitcoin created by a transaction output and available to be spent by exactly one subsequent transaction input. Wallets build new transactions by selecting UTXOs they control and creating outputs that send value to destination addresses and optionally return change back to the wallet. This model affects privacy, coin selection, and fee estimation.

Transaction Anatomy: Inputs, Outputs and Scripts

Inputs

Each input references a prior UTXO by transaction id and output index (txid:vout). The input supplies unlocking data that proves the spender is authorized to spend that UTXO. For legacy inputs this is a signature and public key. For SegWit inputs the unlocking data is structured differently and signature data may be segregated from the main transaction body.

Outputs

Each output contains a value (satoshis) and a locking script that specifies spending conditions, typically an address format like P2PKH, P2SH, or P2WPKH. The sum of input values must equal or exceed the sum of output values; the difference is the miner fee. Outputs define new UTXOs that future transactions can consume.

Scripts and Spending Conditions

Bitcoin script is a stack-based, deliberately limited scripting language. ScriptPubKey (locking script) is attached to outputs and ScriptSig/ScriptWitness (unlocking script) is attached to inputs. Standard templates include pay-to-public-key-hash and pay-to-witness-public-key-hash. Scripts enforce authorization rules without Turing completeness, reducing risk and enabling efficient validation.

Transaction Creation and Coin Selection

When you create a transaction, the wallet performs coin selection: choosing which UTXOs to spend to cover the desired amount plus fees. Coin selection strategies impact privacy and fees. Common strategies include smallest-first, largest-first, and algorithms that minimize change outputs. Generating a change output creates a new UTXO returning leftover funds to the sender, which has privacy implications because it can link inputs and outputs.

Example flow

• Wallet selects UTXOs totaling 0.015 BTC.
• Desired payment is 0.01 BTC.
• Wallet creates two outputs: 0.01 BTC to recipient and 0.0049 BTC change back to the wallet.
• Fee equals 0.0001 BTC (calculated from transaction size and fee rate).

Transaction Formats and Segregated Witness

The raw transaction format encodes version, inputs, outputs, locktime, and other fields. Segregated Witness changed how signature data is included: witness data is separated from the main transaction serialization, reducing malleability and lowering fees for equivalent spending conditions by reducing effective size. SegWit transactions use different weight and vsize calculations which most modern wallets and fee estimators account for.

Fees: Calculation, Estimation and Wallet Behavior

Fees are paid to miners and are determined by fee rate (satoshis per virtual byte). The required fee rate depends on network demand and how quickly you want confirmation. Fee estimation algorithms analyze mempool state and recent block inclusion to estimate a fee rate that will likely be accepted within a target number of blocks. Many wallets expose presets like slow, normal, and fast but also permit manual fee rates.

Effective size and weight

Because SegWit separates witness data, Bitcoin uses weight units to compute fees: weight = base_size * 3 + total_size. Virtual size (vsize) = ceil(weight / 4). Fee = fee_rate * vsize. Understanding vsize matters because two transactions with identical non-witness bytes can require different fees depending on witness content and input types.

Broadcasting, the Mempool and Propagation

Once signed, a transaction is broadcast to connected peers and propagated through the network. Nodes initially store transactions in their mempool, a temporary pool of unconfirmed transactions. Mempool size and fee pressure determine how quickly miners pick transactions into blocks. During congestion low-fee transactions may stay in the mempool for hours or longer, and some nodes will evict low-fee transactions to maintain mempool limits.

Transaction relay policies

Nodes enforce relay policies including minimum fee thresholds and standardness rules. A transaction that violates policy may not be relayed. Wallets designed for reliable delivery implement fee estimation and often broadcast via multiple peers or services to improve propagation.

Confirmation, Finality and Reorgs

Miners include transactions in a block and once a block is accepted by nodes the transactions inside gain their first confirmation. Additional blocks built on top increase the confirmation count and the probability that a transaction will remain irreversible. Short chain reorganizations can replace the most recent blocks and temporarily reverse confirmations, but as confirmations accumulate the probability of reversal declines sharply. Confirmation speed is a combination of fee rate, mempool competition, and miner behavior.

Replace-By-Fee and Child-Pays-For-Parent

If a transaction is unconfirmed, there are two common strategies to accelerate confirmation: Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP). RBF allows the sender to broadcast a replacement transaction with a higher fee if the original transaction signaled RBF. CPFP is used by the recipient or a later spender to create a child transaction that pays a high fee, incentivizing miners to include both parent and child together because combined fees make the package profitable.

Transaction Malleability and Security Considerations

Transaction malleability allowed certain parts of a transaction to be modified without invalidating signatures, changing the txid. SegWit largely solved this by removing signatures from the part of the transaction used to compute the txid. Until SegWit adoption was widespread, malleability complicated some wallet and second-layer protocols. Modern wallets and protocols assume SegWit protections, but it remains important to avoid relying on txids for logic in ways that can break under reorgs or malleability in legacy transactions.

Monitoring and Tools

To monitor transaction status, use block explorers, node RPC calls, or wallet APIs. Common RPC commands include getrawtransaction and getmempoolentry when running a full node. Explorers expose mempool state, confirmation counts, and fee rate history. Monitoring helps diagnose long confirmation times, detect double spend attempts, and observe when a transaction has been confirmed and included in a particular block height.

Practical Tips for Users and Operators

• Use SegWit-compatible wallets to reduce fees and improve privacy.
• When sending urgent payments, choose an appropriate fee rate based on mempool conditions instead of default slow presets.
• Avoid unnecessary change outputs; batching payments reduces total fees and on-chain footprint.
• Enable RBF if you may need to increase fees after broadcasting.
• For exchanges and services, implement robust mempool monitoring and consider multiple peers for reliable propagation.

Simple Raw Transaction Pseudocode

1. Gather UTXOs: list of (txid, vout, value, scriptPubKey)
2. Select UTXOs covering amount + estimated_fee
3. Create inputs referencing selected UTXOs
4. Create outputs: recipient_amount, change_amount (if any)
5. Compute transaction size (or weight) to get vsize
6. Estimate fee = fee_rate * vsize
7. Adjust outputs or select different UTXOs if fee changes
8. Sign inputs (produce ScriptSig or Witness)
9. Serialize and broadcast raw transaction hex

When Things Go Wrong: Stuck Transactions and Recovery

If a transaction remains unconfirmed for a long time, options include broadcasting a higher-fee replacement if RBF was enabled, using CPFP if a child can be spent by the recipient, or letting it eventually be evicted from the mempool and replaced by resubmitting with a correct fee. For custodial services and exchanges, clear policies and user-facing guidance reduce confusion when network congestion causes delays.

Conclusion

Bitcoin transactions combine simple primitives into a secure, censorship-resistant transfer mechanism. Mastering inputs, outputs, scripts, fee calculation, mempool behavior, and confirmation mechanics improves operational decisions for users and services. A solid understanding of transaction internals also clarifies tradeoffs between privacy, cost, and speed when using the Bitcoin network.

Frequently Asked Questions

How does the UTXO model affect privacy?

UTXO linking reveals relationships between inputs and outputs. Change outputs can expose the sender's wallet address unless care is taken to use fresh addresses and coin selection strategies that reduce linkability. Coinjoin and other privacy-preserving patterns leverage UTXO structure to mix outputs across participants.

Why did my transaction take a long time to confirm?

Long confirmation times are usually due to low fee rates relative to mempool demand. During congestion many low-fee transactions wait until miners include them. Tools such as fee estimators and mempool visualizers can help choose a fee appropriate to current network conditions.

What is Replace-By-Fee and should I use it?

Replace-By-Fee allows a sender to broadcast a replacement transaction with a higher fee if the original signaled RBF. It offers flexibility to increase fees after broadcast but can complicate trust assumptions for recipients who assume the first broadcast is final. Use RBF when you may need to bump fees and when sending to recipients who accept unconfirmed transactions is not required.

Can a confirmed transaction be reversed?

Confirmed transactions can be reversed by chain reorganizations if alternative blocks replace the block containing the transaction. Deep reorganizations are rare; probability of reversal decreases as more confirmations accumulate. Services typically wait for a number of confirmations before treating a transaction as final.