Bitcoin's UTXO Model: Why Bitcoin Doesn't Have Account Balances

Two Ways to Track Money

Every blockchain must solve the same fundamental accounting problem: track who owns what, and prevent double spending. There are two primary approaches. The account model — used by Ethereum, Solana, and most modern smart contract platforms — is familiar to anyone who thinks about bank accounts: each address has a balance, and transactions debit one balance and credit another.

Bitcoin uses a fundamentally different model: Unspent Transaction Outputs (UTXOs). In the UTXO model, there are no balances. There is no "account" with a number attached to it. Instead, Bitcoin's state is a set of discrete, unspent coins — each one the output of a previous transaction that has not yet been spent. Understanding UTXOs is essential to understanding how Bitcoin transactions actually work, why wallets behave the way they do, and what gives Bitcoin Script its particular power and limitations.

What Is a UTXO?

A UTXO is a discrete unit of value, locked to a specific spending condition. Think of it as a coin — not a number in an account, but a physical coin of a specific denomination that can only be spent by whoever holds the right key.

Every UTXO has: - An amount — the number of satoshis (the smallest Bitcoin unit, 1 BTC = 100,000,000 satoshis) - A locking script (scriptPubKey) — the conditions required to spend this output, typically requiring a signature from a specific public key

When you "receive" Bitcoin, what actually happens is that a transaction creates a new UTXO with a locking script that only you can satisfy. Your "balance" is not stored anywhere — it is the sum of all UTXOs whose locking scripts you can satisfy.

Anatomy of a Bitcoin Transaction

A Bitcoin transaction is a data structure with three key components: inputs, outputs, and metadata.

Inputs

Each input references a specific UTXO from a previous transaction: - Transaction ID (txid) — the hash of the previous transaction - Output index (vout) — which output of that transaction (0-indexed) - Unlocking script (scriptSig) — data that satisfies the referenced UTXO's locking script, typically a digital signature and a public key

By referencing a specific previous output, an input claims "I am spending UTXO number 2 from transaction abc123..." The referenced UTXO must exist in the UTXO set (the set of all unspent outputs) and must not have been spent in any other transaction.

Outputs

Each output creates a new UTXO: - Amount — satoshis being assigned to this output - Locking script — the conditions the spender must satisfy

A transaction can have multiple outputs, creating multiple UTXOs simultaneously. The sum of all output amounts must be less than or equal to the sum of all input amounts. The difference is implicitly the transaction fee, collected by the miner.

double-spend-problem-solved">The Double Spend Problem: Solved

The UTXO model elegantly prevents double spending. Once a UTXO is used as an input in a confirmed transaction, it is removed from the UTXO set forever. Any subsequent transaction attempting to reference the same UTXO is immediately invalid — nodes reject it without even checking signatures, because the referenced output no longer exists in the UTXO set.

Bitcoin Script: A Stack-Based Language

Bitcoin's locking and unlocking scripts are written in Script, a simple, intentionally limited stack-based language. Script is not Turing-complete — there are no loops. This constraint is a feature: it makes Script execution predictable and analyzable, with no risk of infinite loops or unexpected side effects.

pay-to-public-key-hash-p2pkh-the-standard-transaction">Pay-to-Public-Key-Hash (P2PKH): The Standard Transaction

The most common locking script type, used in traditional Bitcoin addresses (starting with "1"), is P2PKH:

Locking script (scriptPubKey):

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Unlocking script (scriptSig):

<signature> <pubKey>

When the transaction is validated, the node runs the combined script on a stack:

1. Push <signature> onto the stack
2. Push <pubKey> onto the stack
3. OP_DUP — duplicate the top item (pubKey)
4. OP_HASH160 — hash the top item (produces pubKeyHash)
5. Push <pubKeyHash> from the locking script
6. OP_EQUALVERIFY — verify the two hashes match (public key matches the address)
7. OP_CHECKSIG — verify the signature against the public key

If the stack ends with TRUE, the UTXO is validly spent. No trusted party is involved — every full node independently verifies every spending condition.

pay-to-script-hash-p2sh-and-segwit">Pay-to-Script-Hash (P2SH) and SegWit

Bitcoin's Script vocabulary has expanded over the years to support more complex spending conditions without bloating every transaction. P2SH allows a locking script to commit to the hash of a redeem script — the actual spending conditions. The redeemer provides both the redeem script and data satisfying it. This enables multisignature wallets, time-locks, and other complex conditions while keeping typical transactions compact.

SegWit (Segregated Witness), activated in 2017, moved the unlocking script data into a separate "witness" field outside the traditional transaction structure. This fixed a critical bug called transaction malleability (where anyone could modify a transaction's ID without invalidating its signatures), reduced the effective size of transactions, and enabled the Lightning Network's payment channels.

Taproot, activated in 2021, went further by allowing complex Script conditions to be encoded as a single public key when all parties cooperate, revealing the complex script only when spending occurs non-cooperatively. This dramatically improves privacy and efficiency for multisig and time-locked outputs.

The UTXO Set: Bitcoin's Core State

The UTXO set is the set of all UTXOs that exist and have not been spent. As of 2024, the Bitcoin UTXO set contains approximately 120–140 million UTXOs and occupies roughly 5–7 GB when stored in a compact format. This is Bitcoin's entire "state" — every full node maintains a copy of the UTXO set and uses it to validate every new transaction.

The UTXO set is far smaller than the full blockchain (which stores every transaction ever made, now over 600 GB). New nodes can sync the UTXO set from other nodes without downloading the full blockchain, though they cannot independently verify the UTXO set's correctness without replaying the entire transaction history.

Coin Selection: The Wallet's Hidden Complexity

Because Bitcoin balances are composed of discrete UTXOs rather than a single number, sending Bitcoin requires a coin selection algorithm: the wallet must choose which UTXOs to use as inputs for a new transaction.

The Change Address Problem

Suppose you have two UTXOs: one for 0.5 BTC and one for 0.3 BTC. You want to send 0.6 BTC to a merchant. You cannot "split" a UTXO — you must spend it entirely. So your transaction must use both UTXOs as inputs (total: 0.8 BTC) and create two outputs: - 0.6 BTC to the merchant's address - 0.19999 BTC to a change address you control (the 0.00001 BTC difference is the fee)

The change address is critical for privacy: without it, any transaction that doesn't exactly match a UTXO's value would donate the remainder to miners. Change addresses are generated fresh for each transaction in HD wallets (following BIP-32) to prevent address reuse, which could link multiple transactions to the same user.

Trade-offs in Coin Selection

The choice of which UTXOs to use affects: - Transaction fees — more inputs mean a larger transaction (in bytes), which means higher fees - UTXO consolidation — using many small UTXOs in one transaction reduces future fragmentation - Privacy — using multiple UTXOs may link different receiving addresses to the same wallet

Wallets use various strategies: selecting the largest UTXOs first (minimizes input count), selecting UTXOs that minimize change output (reducing UTXO fragmentation), or selecting randomly (for privacy). Sophisticated wallet software like Bitcoin Core uses a Branch and Bound algorithm to find combinations that match the target amount exactly, eliminating the change output entirely when possible.

UTXOs vs. Accounts: Design Implications

The UTXO model's greatest advantage for Bitcoin's use case is its natural support for parallel validation: because UTXOs are independent objects, multiple transactions spending different UTXOs can be validated simultaneously with no shared state. The account model requires serial ordering by nonce to prevent race conditions — a constraint that complicates high-throughput systems.

The UTXO model's greatest limitation is that it makes stateful computation difficult. Complex DeFi protocols need to read and write shared state across many users' positions — something the UTXO model's discrete, unspent-coin abstraction does not naturally support. This is why Ethereum chose the account model, and why Bitcoin's smart contract capabilities remain intentionally limited compared to Ethereum's EVM.