Transactions, Change and Fees

The UTXO model

Bitcoin does not keep account balances. It keeps unspent transaction outputs, or UTXOs: coins with locks on them.

• A UTXO is a specific amount locked to a spending condition.
• Your wallet’s “balance” is the sum of the UTXOs it can spend.
• Full nodes keep the set of all UTXOs, so they can check a new transaction without replaying every block.

Inputs and outputs

A transaction consumes old outputs and creates new ones.

• Inputs point at earlier outputs and unlock them, usually with a signature and a public key.
• Outputs create new locks, each with an amount.
• Inputs are spent whole, never partially. Send 1 BTC from a 5 BTC coin and the wallet adds a change output back to you.
• Whatever the outputs do not claim becomes the miner fee.

What a transaction contains

Here is the payment from the worked example below, decoded field by field. Blue is what is spent, green is what the recipient gets, purple is your change, and red is the fee.

Scripts are the locks

Each output carries a script that says who can spend it. “Sending to an address” is shorthand for creating an output with a particular lock; the ledger enforces the script, not a name or an account.

• P2WPKH: one signature from the key that matches the committed public-key hash.
• Multisig: M of N signatures, such as any 2 of 3 keys or 3 of 5.
• Taproot: a key path, plus an optional tree of script paths.
• The spending input supplies the witness data that satisfies the script.

Fees are a rate, not a flat amount

Miners are paid for block space, not for the amount of bitcoin moved.

• Size is measured in virtual bytes (vB). Inputs, outputs and witness data all add size.
• Fee rate is quoted in satoshis per virtual byte (sat/vB).
• Fee = size × fee rate. A simple 1-input, 2-output segwit transaction is about 140 vB; at 10 sat/vB that is 1,400 sats.
• More inputs mean a bigger transaction and a higher fee at the same rate.

The mempool and confirmation targeting

Valid unconfirmed transactions wait in each node’s mempool: a waiting room, not a single shared queue.

• Miners fill a candidate block with the highest fee rates first.
• When blocks are full, a low-fee transaction can wait a long time.
• Stuck? Replace it with a higher-fee version (replace-by-fee, RBF; full-RBF is the Bitcoin Core default since version 28), or spend one of its outputs in a child that pays extra (CPFP).

What a mempool entry contains

Each node keeps its own record of every waiting transaction. These are the fields Bitcoin Core reports for one entry, and where it sits in the queue.

Fee estimation in practice

Wallets estimate a fee rate from recent blocks and the current mempool.

• A “fast” target uses a higher rate than an “economy” target.
• Paying more is not a tip; it is a bid for scarce block space.
• When the mempool clears, the same transaction could have confirmed for less. When blocks are full, a low bid can wait for hours.
• Good wallets show the tradeoff in time, not just in satoshis.

A worked example

You have one UTXO of 0.5 BTC and send 0.1 BTC. Your wallet picks 8 sat/vB and estimates 140 vB.

Privacy and failure modes

Change outputs and address reuse make transactions linkable. Coin control lets you choose which UTXOs to spend, which matters for privacy and for not dragging a large coin into a small payment. Common ways a payment goes wrong:

• It never propagates to other nodes.
• It sits below the current fee floor.
• It is replaced by a higher-fee version.
• It is evicted when mempools fill up, or Bitcoin Core drops it from its own mempool after about two weeks. It is not cancelled: it can be rebroadcast and still confirm.
• “Unconfirmed” is not a promise. More confirmations generally reduce reversal risk, but no fixed count guarantees finality; the receiver picks a threshold for the amount at stake.