Timechain Wiki

UTXO model and Bitcoin transactions

14 min read

Bitcoin tracks ownership not as account balances but as a set of unspent transaction outputs (UTXOs) — discrete chunks of bitcoin, each locked to a specific spending condition, that can be spent by an authorized party. A transaction is the operation that consumes one or more existing UTXOs as inputs and creates one or more new UTXOs as outputs. The difference between input total and output total is the fee paid to whichever miner includes the transaction. This UTXO model is structurally different from the account-balance model that Ethereum and traditional finance use; the differences shape Bitcoin's parallelizability, privacy properties, fee market dynamics, and developer ergonomics. This note treats the structural mechanics of the UTXO model and the on-chain anatomy of a Bitcoin transaction: what fields it contains, how inputs reference earlier outputs, how fees are computed, how transaction IDs work, and the lifecycle from construction through confirmation. Operational implications (coin selection, fee estimation, replace-by-fee) surface here briefly; deeper operational treatment lives in PSBT and wallet descriptors and Backup strategies for seeds.

Why this note matters

The UTXO model is the load-bearing structural choice in Bitcoin’s transaction layer. Every transaction-level question — how multi-input spends work, why fees are calculated the way they are, what coin selection means, how change outputs leak privacy information, why Bitcoin can be parallelized in ways Ethereum cannot — traces to UTXOs. Notes elsewhere in this discussion (operational, analytical, historical) defer to this one for the underlying mechanics.

The model is also the cleanest expression of Bitcoin’s specific design philosophy: stateless validation, no shared mutable state, minimal protocol-level abstraction. Bitcoin transactions look like discrete events on a tape rather than updates to a global ledger. That structural choice has consequences across every other layer.

What a UTXO is

A UTXO is:

  • A value (denominated in satoshis; 1 BTC = 100,000,000 sat)
  • A locking script (scriptPubKey) that specifies what’s required to spend the UTXO
  • A provenance — implicit; the UTXO came from a specific output of a specific earlier transaction

When the UTXO is consumed by being referenced as input to a new transaction, it ceases to be a UTXO. It’s now a spent output. The set of all UTXOs at any moment is the UTXO set — Bitcoin’s effective state.

The UTXO set in 2026 contains roughly 150-180 million UTXOs across the ~20 million BTC currently in circulation. Average UTXO size is around 0.11 BTC, but the distribution is heavy-tailed (most UTXOs are small; a few large ones hold most of the value).

The UTXO set lives in the chain state maintained by every full node. It is the consensus-critical data structure — every node must agree on which outputs are unspent and at what value. Block validation depends on consulting it.

The structure of a Bitcoin transaction

A modern Bitcoin transaction has the following structure:

- Version: 4-byte field (currently 1 or 2; affects locktime semantics)
- Marker + Flag: 2 bytes (present only for SegWit transactions)
- Input count: variable-length integer
- Inputs: one or more, each containing:
    - Outpoint: 36 bytes (prev txid: 32 bytes + output index: 4 bytes)
    - ScriptSig: variable-length unlocking script (empty for SegWit inputs)
    - Sequence: 4-byte field (used for RBF, locktime, and relative locktimes)
- Output count: variable-length integer
- Outputs: one or more, each containing:
    - Value: 8 bytes (satoshis)
    - ScriptPubKey: variable-length locking script
- Witness: SegWit witness stack, one stack per input (present for SegWit)
- Locktime: 4 bytes (block height or unix timestamp before which the tx is invalid)

A few key details:

Inputs reference earlier outputs by (txid, output_index). Each input names a specific UTXO to consume. The reference is by hash, not by address — the UTXO has a unique location in the transaction graph regardless of which address it pays to.

Outputs are pure (value, script) pairs. They don’t reference each other; they don’t have addresses per se. The “address” is just a human-readable encoding of the lock specified in scriptPubKey.

Inputs and outputs are ordered. The on-chain transaction has a specific input order and a specific output order. This ordering matters for some protocol-level mechanics (BIP-69 lexicographic ordering for privacy; fixed orders for some multisig protocols).

Locktime specifies a minimum block height or timestamp before which the transaction is invalid. Used by Lightning channels, time-locked vaults, and similar constructions.

Sequence numbers were originally intended as a transaction-replacement mechanism that never quite worked; modern protocol reuses the sequence field for replace-by-fee (BIP-125) and relative-locktime (BIP-68) semantics.

How transactions consume and create UTXOs

The basic operation:

  1. Inputs name UTXOs. Each input gives (prev_txid, output_index) plus the data required to authorize spending — typically a signature, possibly a script reveal.
  2. Outputs create new UTXOs. Each output specifies a value and a locking script that future spends must satisfy.
  3. Total input value ≥ total output value. The difference is the fee paid to the miner who includes this transaction in a block.

A simple example: Alice has a UTXO worth 1.0 BTC at her address. She wants to send 0.3 BTC to Bob and keep the rest. Her transaction:

  • 1 input: pointing to Alice’s 1.0 BTC UTXO, with her signature
  • 2 outputs:
    • 0.3 BTC to Bob’s address (Bob’s new UTXO)
    • 0.69999 BTC to Alice’s change address (Alice’s new UTXO; the small loss is the miner fee)
  • Fee: 0.00001 BTC (1000 sat) implicit in the input/output difference

After this transaction is confirmed:

  • Alice’s 1.0 BTC UTXO is gone (consumed)
  • Bob has a new 0.3 BTC UTXO
  • Alice has a new 0.69999 BTC UTXO at her change address
  • The miner of the including block earns the 1000 sat fee

The UTXO set has gained one entry net (1 in, 2 out) and lost some satoshis to fees. Net BTC supply is preserved across the transaction (modulo the new issuance in the coinbase transaction of the including block).

Change outputs

When the input total exceeds the intended payment, the excess must go somewhere — usually back to the sender via a change output. Modern wallets handle this automatically: generate a fresh address, derive a derivation path, send the change there.

The change output is structurally indistinguishable from a payment output. This produces two challenges:

  • Privacy. Chain analysis tries to identify which output is “the payment” and which is “the change” using heuristics: address-reuse pattern, output ordering, value of the round-number output. Successful identification links the sender’s change UTXO to their wallet cluster. See Address reuse and chain analysis for the chain-analysis dimension.
  • Operational. If the wallet generates a change address from a different derivation path than the holder knows about, the holder might not see the change in their wallet. This was a real source of confusion for non-technical holders in Bitcoin’s early years; modern wallets handle it well.

No-change transactions. When the inputs exactly equal the intended payment plus fee, no change output is needed. This is rare in practice but happens for transactions specifically constructed for privacy or for some on-chain protocols (CoinJoin pools, atomic swaps).

Transaction IDs

A transaction has two identifiers:

  • TXID (transaction ID): double-SHA-256 of the non-witness serialization of the transaction. Used for referencing the transaction across inputs of subsequent transactions. Stable; not affected by witness manipulation.
  • WTXID (witness transaction ID): double-SHA-256 of the full serialization including witness data. Used inside the witness commitment in the block header. Differs from TXID only for SegWit transactions.

The split between TXID and WTXID was introduced in SegWit specifically to eliminate signature malleability. Before SegWit, the signature data was part of the TXID computation — meaning an attacker could modify the signature (without invalidating it) to change the TXID. This was a load-bearing problem for protocols that depend on referencing pending transactions, including Lightning Network.

After SegWit, the TXID excludes witness data; signatures can change (in legitimate ways during multi-step signing) without changing the TXID. This is one of SegWit’s most important practical wins.

The transaction lifecycle

A transaction’s life:

  1. Construction. A wallet selects UTXOs (coin selection), creates outputs, signs inputs, and serializes the result.
  2. Broadcast. The transaction is sent to a Bitcoin node, which validates it (sufficient inputs, valid signatures, valid scripts, no double-spend) and propagates it across the peer-to-peer network.
  3. Mempool. Each full node maintains a mempool — the set of valid unconfirmed transactions known to it. The mempool is per-node; nodes do not agree on a global mempool.
  4. Mining. A miner selects transactions from its mempool (typically by fee-rate), constructs a candidate block, and tries to find a valid PoW nonce.
  5. Inclusion. When a miner finds a valid block, the transactions in it become confirmed.
  6. Confirmation depth. Each subsequent block adds another confirmation. The probability of the transaction being reversed via reorg falls exponentially with confirmation depth. See Chain reorganizations.

Replace-by-fee (RBF). A transaction can be replaced before confirmation by a new transaction with a higher fee — the new transaction shares inputs with the old, signaling replacement intent via the sequence number (BIP-125). This lets users bump fees on stuck transactions.

Mempool eviction. Mempools have finite size; low-fee transactions get evicted when the mempool fills. An evicted transaction may eventually disappear and need to be re-broadcast or replaced.

Coin selection

Wallets choose which UTXOs to spend via coin selection algorithms. The choice matters for fees, privacy, and the future-shape of the UTXO set:

  • Largest-first. Spend the largest available UTXOs. Minimizes input count and fee for this transaction but consolidates the UTXO set rapidly.
  • Smallest-first. Spend the smallest UTXOs (akin to making change in cash). Keeps large UTXOs intact; high input count and fee.
  • Branch-and-bound (BnB). Find a combination of UTXOs that exactly (or nearly exactly) covers the spend without change. Maximizes privacy by eliminating change-output identification heuristics.
  • FIFO / LIFO. Spend in the order received. Affects holding-period tax calculations in jurisdictions that track lots.

Most modern wallets use BnB when possible, falling back to other algorithms. The choice is invisible to users in normal operation; it surfaces only when a wallet explicitly exposes coin-control features (e.g., choosing specific UTXOs to spend).

UTXO vs account-balance: the structural divergence

The principal alternative to UTXO is the account-balance model used by Ethereum and most pre-Bitcoin financial systems. Each address has a balance; transactions debit one balance and credit another.

The structural differences:

Parallelizability. UTXO transactions can be validated in parallel — a transaction depends only on the UTXOs it consumes, not on the global state. Two unrelated transactions never conflict. Account-balance transactions read and write the global balance state; serial-only ordering is required. This is part of why Bitcoin validation scales better than Ethereum-style smart-contract systems in raw transactions-per-second.

Stateless verification. A node validating a Bitcoin transaction needs only the UTXO set, not the entire transaction history. The UTXO set is the effective state. (The full chain is still required to reconstruct the UTXO set from scratch; a node can also use assumeUTXO or a trusted snapshot to skip this.)

Privacy. UTXOs are individually pseudonymous; the account-balance model concentrates all activity at a single address. UTXO offers structurally better privacy when used with fresh addresses; account-balance models concentrate all observable activity.

Developer ergonomics. Account-balance models are simpler to build applications on. Track a number per address; allow updates. UTXO requires constructing transactions out of discrete chunks, which is harder for application developers. This is a substantial reason Ethereum chose account-balance for its smart-contract platform.

Reentrancy. Account-balance models can produce reentrancy bugs (the source of the 2016 DAO hack on Ethereum). UTXO is structurally immune — outputs are consumed in one operation; there’s no shared mutable state to reenter.

The UTXO model is part of why Bitcoin’s smart-contract capabilities are limited (intentionally) and why Bitcoin’s privacy story is structurally different from Ethereum’s.

Tradeoffs and design choices

Why UTXO at all? Satoshi’s whitepaper specifies the UTXO model implicitly via the description of transactions as chains of digital signatures. The exact origin of the design choice is unclear — possibly inherited from Hashcash-style designs, possibly chosen for parallelizability properties. Whatever the rationale, the choice has held up well.

The dust limit. Bitcoin enforces a minimum output value (~546 sat for typical P2WPKH) — outputs below this are considered “dust” and won’t be relayed by default. Reasoning: at very low values, the cost of consuming the UTXO (transaction fee) exceeds its value, so creating it would just waste UTXO-set space. The dust limit shifts with prevailing fee rates.

UTXO set growth. The UTXO set grows over time as transactions create more outputs than they consume. This is a long-term concern: a 1-billion-UTXO chain state requires substantial memory. Several proposed extensions (UTREEXO, CSV-based outputs that auto-prune) aim to bound the growth. Operational concern but not a blocking one in 2026.

Privacy via fresh addresses. UTXO’s privacy benefit only materializes if users actually rotate addresses (no address reuse). Real-world adoption of fresh-address discipline is partial; reused addresses give chain analysis substantial linking power. See Address reuse and chain analysis.

Coin selection privacy tradeoffs. Algorithms that consolidate UTXOs (largest-first) reveal more wallet structure to chain analysis. Algorithms that diversify (BnB no-change) preserve more privacy but may produce higher-fee transactions over time. The tradeoff is genuine and operational; not a settled best-practice.

The Lightning Network as UTXO supplement. Lightning channels lock UTXOs to multi-party multisig outputs that are updated off-chain. Lightning is the Layer-2 answer to UTXO model’s transaction-throughput limits — moving frequent payments off-chain entirely. See Scaling and Layer 2.

For substantive engagement with on-chain capacity and the throughput-versus-base-layer-conservatism debate, see Network capacity and fee-market critiques (Criticisms section).

Open questions for further development

  • How does UTXO set growth evolve over multi-decade horizons? Will it remain manageable on commodity full-node hardware, or will accumulator-based optimizations (UTREEXO) become operationally necessary?
  • Should Bitcoin’s dust limit be adjusted programmatically to track fee rates, or kept fixed for predictability? The operational practice has shifted but the protocol-level limits have remained stable.
  • For coin selection: is there a privacy-optimal algorithm that doesn’t sacrifice substantial fee efficiency? BnB is currently the best balance but not provably optimal.
  • How will batch transactions and PayJoin-style cooperative spending affect the long-run shape of the UTXO set?

Canonical sources for this note

Bitcoin Improvement Proposals

  • BIP-69 — Lexicographical indexing of transaction inputs and outputs (privacy-oriented ordering convention).
  • BIP-125 — Opt-in Full Replace-by-Fee Signaling.
  • BIP-141 — Segregated Witness (defines wtxid and witness commitment).

Bitcoin engineering references

  • Mastering Bitcoin, Andreas Antonopoulos (chapter 6: “Transactions”) — the canonical engineering treatment of transaction structure. See Mastering Bitcoin - Andreas Antonopoulos.
  • Programming Bitcoin, Jimmy Song (chapter 5: “Transactions”; chapter 7: “Transaction Creation and Validation”) — working-programmer treatment, including manual serialization and signing.
  • Grokking Bitcoin, Kalle Rosenbaum (chapters 5-6) — accessible treatment for the technically-curious-but-not-developer reader.

Comparative analysis

  • Mastering Ethereum, Antonopoulos and Wood — for the account-balance model comparison. Ethereum is the canonical comparison case.

Graph View

Backlinks