UTXO Model

Bitcoin does not keep a global balance per address. Instead, it tracks unspent transaction outputs (UTXOs), discrete chunks of value that can be spent exactly once.

Why this matters

If you think in “account balance” terms (like a bank), you will mis-build wallets, explorers, and Lightning funding logic. UTXOs are the native accounting unit.

Analogy

Imagine cash bills in a wallet. You do not “subtract $7 from a $20 balance” in place. You hand over bills and get change back. Each bill is a UTXO. Spending consumes whole bills; change is a new bill returned to you.

Inputs and outputs

A transaction:

1. Consumes one or more UTXOs as inputs
2. Creates one or more new outputs
3. Pays the difference as a miner fee (no explicit fee output)

type Utxo = {
  txid: string;
  vout: number;
  valueSats: number;
  scriptPubKey: string;
};
 
const balance = utxos.reduce((sum, u) => sum + u.valueSats, 0);

Wallet balances

Your wallet balance is the sum of UTXOs it can unlock with its keys, not a single number stored on-chain.

Coin selection

When sending, wallets choose which UTXOs to spend. Goals often include:

• Minimizing fees (prefer fewer / appropriately sized inputs)
• Avoiding unnecessary change
• Preserving privacy when possible

Common mistakes

• Forgetting change and accidentally overpaying the fee
• Creating dust outputs that cost more to spend later than they are worth
• Assuming address balance APIs equal UTXO-aware wallet state

Try it: count UTXOs

On regtest, fund an address, then inspect UTXOs:

ADDR=$(bitcoin-cli -regtest getnewaddress)
bitcoin-cli -regtest generatetoaddress 101 "$ADDR"
bitcoin-cli -regtest listunspent

Each listunspent row is a UTXO your wallet can spend. Notice txid, vout, and amount. When you send, some rows disappear and new ones appear (payment + change).

Dust and consolidation

Very small UTXOs can cost more in fees to spend than they are worth, that is dust. Wallets sometimes consolidate many small UTXOs into one when fees are low. Consolidation improves future fee efficiency but links history (privacy tradeoff).

Builders checklist

• Always compute change explicitly in tests
• Log fee = inputs − outputs on every send path
• Never assume an "address balance" API matches your local UTXO set during reorgs

Worked mental model

Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

Hands-on habit

Every protocol idea should be paired with one local experiment:

1. Reproduce the happy path on regtest (or Polar for Lightning)
2. Break it on purpose (wrong fee, expired invoice, offline peer)
3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)

That habit turns reading into builder instinct.

Glossary check

Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

Resource order

Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Next steps

Learn how keys become addresses, then how UTXOs get confirmed inside blocks.