How Bitcoin Records Which Coins You Spend

Bitcoin is often described as a ledger, but unlike a bank account it does not record a single running balance for each user and instead tracks many separate pieces of value.

If a user has two incoming transactions, one with three bitcoin and another with four bitcoin, and then sends out five bitcoin, what exactly happens on the ledger. Do we say that the user spent all three from the first transaction and two from the second, or that the user spent four from the second transaction and one from the first. How is this choice recorded, and how does the system know what happened.

To answer this, we need to look at how Bitcoin really stores information. The system does not store balances for accounts. It stores many separate pieces of value called unspent transaction outputs, usually shortened to UTXO. [In Bitcoin, a UTXO (Unspent Transaction Output) is a discrete chunk of bitcoin created by a previous transaction. Each UTXO has a specific value and a locking script that defines which address can spend it. When a new transaction is made, it consumes existing UTXO as inputs and creates new UTXO as outputs.] Each UTXO says that a certain amount of bitcoin can be spent by whoever controls a certain address. Everything else is derived from this structure.

Account style view and UTXO view

First, it helps to see the difference between an account style ledger and the UTXO style ledger in the same simple situation.

Imagine three users called A, B, and C with these amounts


A: 5  BTC
B: 3  BTC
C: 10 BTC

This is an account style view. It matches how a bank account balance might be written. For simplicity, we can assume that these coins were generated as mining rewards, taking the system from an initial state with no coins to this state.

In the UTXO model, the system does not store one line per user. Instead it stores separate outputs, each with an amount and a locking script that refers to an address. A simplified UTXO view for the same situation might look like this


(tx0, output 0): 5  BTC to addr_A
(tx1, output 0): 3  BTC to addr_B
(tx2, output 0): 10 BTC to addr_C

Here the important facts are

The system knows that there is one output from transaction tx0 that carries five bitcoin and can be spent by addr_A
Another output from tx1 carries three bitcoin for addr_B
Another output from tx2 carries ten bitcoin for addr_C

A wallet program can take all UTXO that belong to a given user and add the values together to display a balance. That is how the familiar account style picture is derived from the underlying UTXO set.

A simple world with three users and one block

Now create a very small world. There is one block, called block zero. It has a block header and a list of transactions. Inside this block, three transactions create value for A, B, and C.

We can describe this block in a simplified structure


Block block0
  hash: "0000000000..."
  height: 0

  header
    version: 1
    prev_block_hash: "0000000000..."
    merkle_root: "<tx_merkle_hash>"
    timestamp: 1234567890
    bits: "0x1d00ffff"
    nonce: 274148111

  transactions: [ tx0, tx1, tx2 ]

Each transaction creates one UTXO for one user. For example


Transaction tx0
  txid: "0xaaa..."

  inputs
    coinbase: true   (new coins, no previous UTXO)

  outputs
    index 0
      value: 5.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_A)> OP_EQUALVERIFY OP_CHECKSIG"


Transaction tx1
  txid: "0xbbb..."

  inputs
    coinbase: true

  outputs
    index 0
      value: 3.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_B)> OP_EQUALVERIFY OP_CHECKSIG"


Transaction tx2
  txid: "0xccc..."

  inputs
    coinbase: true

  outputs
    index 0
      value: 10.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_C)> OP_EQUALVERIFY OP_CHECKSIG"

After this block, the UTXO set is


(tx0, 0): 5  BTC to addr_A
(tx1, 0): 3  BTC to addr_B
(tx2, 0): 10 BTC to addr_C

From the UTXO set, a wallet can compute the familiar balances


A: 5  BTC
B: 3  BTC
C: 10 BTC

The account style view is only a summary. The real ledger content is the UTXO list.

First transfer A sends four bitcoin to B

Next, user A sends four bitcoin to user B. In our small world, A only has one UTXO


(tx0, 0): 5 BTC to addr_A

So the new transaction must use that output as its input. To keep things simple, assume that there is no fee. The transaction spends the full five and creates two outputs. One goes to B as payment. One goes back to A as change.

The new transaction tx3 can be written as


Transaction tx3
  txid: "0xddd..."

  inputs
    previous_txid: "0xaaa..."
    previous_output_index: 0
    scriptSig: "<signature for addr_A>"

  outputs
    index 0
      value: 4.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_B)> OP_EQUALVERIFY OP_CHECKSIG"

    index 1
      value: 1.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_A)> OP_EQUALVERIFY OP_CHECKSIG"

If we only look at the outputs, the simple description of tx3 is


tx3 outputs
  output 0: 4 BTC to addr_B
  output 1: 1 BTC to addr_A

After tx3 is confirmed in a block, the UTXO set changes

The old UTXO from tx0 is removed, because it has been spent
Two new UTXO from tx3 are added

The new UTXO set is


(tx1, 0): 3  BTC to addr_B
(tx2, 0): 10 BTC to addr_C
(tx3, 0): 4  BTC to addr_B
(tx3, 1): 1  BTC to addr_A

The account style view derived from this set is


A: 1  BTC
B: 7  BTC
C: 10 BTC

Again, the account style view is only a summary. The true state is the list of UTXO.

Second transfer B sends five bitcoin to C

Now we reach your central question. At this point, user B has two UTXO


(tx1, 0): 3 BTC to addr_B
(tx3, 0): 4 BTC to addr_B

The computed balance of B is seven bitcoin.

Now B wants to send five bitcoin to C. Before the new transaction is built, there is ambiguity in the human description. You can imagine two ways to choose UTXO that cover five bitcoin

Use all three from the first UTXO and two from the four bitcoin UTXO
Use all four from the second UTXO and one from the first UTXO

However, in the UTXO model the system must pick concrete inputs. There is no partial spending of a single UTXO. Each UTXO is either entirely spent or not used in that transaction. You cannot take only two out of a three bitcoin UTXO or one out of a four bitcoin UTXO. If you need change, the change is created as a new output in the same transaction.

In our example, a natural choice is to use both UTXO that belong to B


(tx1, 0): 3 BTC
(tx3, 0): 4 BTC

The new transaction tx4 then has

Total input value seven
One output of five to C
One output of two back to B as change

The detailed form is


Transaction tx4
  txid: "0xeee..."

  inputs
    input 0
      previous_txid: "0xbbb..."
      previous_output_index: 0
      scriptSig: "<signature for addr_B>"

    input 1
      previous_txid: "0xddd..."
      previous_output_index: 0
      scriptSig: "<signature for addr_B>"

  outputs
    index 0
      value: 5.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_C)> OP_EQUALVERIFY OP_CHECKSIG"

    index 1
      value: 2.0
      scriptPubKey: "OP_DUP OP_HASH160 <hash(addr_B)> OP_EQUALVERIFY OP_CHECKSIG"

If we only look at tx4 outputs


tx4 outputs
  output 0: 5 BTC to addr_C
  output 1: 2 BTC to addr_B

Once tx4 is confirmed, the UTXO set is updated again.

The two old UTXO that belonged to B and were used as inputs are removed


(tx1, 0): 3 BTC to addr_B   spent
(tx3, 0): 4 BTC to addr_B   spent

Two new UTXO appear from the outputs of tx4


(tx4, 0): 5 BTC to addr_C
(tx4, 1): 2 BTC to addr_B

The complete UTXO set is now


(tx2, 0): 10 BTC to addr_C
(tx3, 1): 1  BTC to addr_A
(tx4, 0): 5  BTC to addr_C
(tx4, 1): 2  BTC to addr_B

The account style summary is


A: 1  BTC
B: 2  BTC
C: 15 BTC

In this final state C indeed has fifteen bitcoin in total, but that value is spread across two separate UTXO that came from different transactions.

How the system knows which coins were spent

This question is focused on what the ledger records in the moment when B sends five bitcoin to C. Does the system record that B spent three from the first UTXO and two from the second, or some other split. The important point is that the system does not think in such partial amounts.

Each input of a transaction points to one specific previous output by its transaction hash and output index. When a new transaction is created, the wallet chooses which previous outputs to use as inputs. Each chosen output is completely consumed. If the sum of those outputs is larger than the amount you want to send, the transaction creates a change output that returns the difference to an address you control.

So in our example, once tx4 has been built and broadcast, there is no ambiguity left. The chain contains an objective record

This transaction spends output zero of transaction tx1, which carried three bitcoin for B
It also spends output zero of transaction tx3, which carried four bitcoin for B
In return it creates output zero of tx4 with five bitcoin for C
It also creates output one of tx4 with two bitcoin back to B

All nodes can see exactly which UTXO were spent. There is no hidden question such as whether the system took three plus two or four plus one. That kind of description belongs to the account style way of thinking. In the UTXO style ledger, the only question is which prior outputs were used entirely.

Different wallet software might choose different combinations of UTXO when there are many available. For example, a wallet could have chosen just one larger UTXO in a different situation, or many small ones, depending on its own coin selection strategy. Both choices would be valid as long as the inputs cover the outputs plus fee. The network simply verifies that the chosen inputs are unspent, that the signatures are valid, and that the total input value is not less than the total output value.

Simple ledger and detailed ledger

We can now clearly separate two ways of writing the same state.

The simple ledger or account style view shows only balances


After all transactions
  A: 1  BTC
  B: 2  BTC
  C: 15 BTC

This view is compact and intuitive for humans. It is not what the Bitcoin chain stores directly.

The detailed ledger or UTXO style view shows all unspent outputs along with the transaction that created them and the addresses that can spend them


After all transactions
  (tx2, 0): 10 BTC to addr_C
  (tx3, 1): 1  BTC to addr_A
  (tx4, 0): 5  BTC to addr_C
  (tx4, 1): 2  BTC to addr_B

This UTXO set is the real state of the system. From it, balances and histories can be computed, but all checking of new transactions and new blocks uses this structure.

Conclusion

Bitcoin is indeed a system for keeping a ledger, but the style of that ledger is subtle. It does not keep a simple table that says user A has this many coins and user B has that many. Instead it keeps a collection of individual outputs, each one assigned to an address and each one either entirely unspent or entirely spent.

In the example with users A, B, and C, we started with simple incoming outputs for each user, then let A pay B, and later let B pay C. At each step, the UTXO set changed in a precise way. Old outputs were consumed as inputs. New outputs were created as payment and as change. When B sent five bitcoin to C, the new transaction explicitly named which previous outputs B was spending. Those outputs were used completely, and any remainder came back as a new change output.

What we are really examining is whether the system thinks in terms of three plus two or four plus one, and this way of framing the problem arises naturally from an account style view of balances. The UTXO model answers it by avoiding partial spending of a single output. For each transaction, the chain records exactly which previous outputs were consumed and exactly which new outputs were created. The apparent balance of a user is then just the sum of all UTXO that the user can spend.

1. Blockchain and Bitcoin - Overview and Big Picture
https://shiluqi.blogspot.com/2025/11/blockchain-and-bitcoin-main-article.html
2. Blockchain and Bitcoin - How Bitcoin Records Which Coins You Spend
this article

3. Blockchain and Bitcoin - Transactions Prove Ownership and Deliver Funds
https://shiluqi.blogspot.com/2025/11/blockchain-and-bitcoin-transactions.html

4. Blockchain and Bitcoin - Wallets, Keys, and Seed Phrases
https://shiluqi.blogspot.com/2025/11/4-blockchain-and-bitcoin-wallets-keys.html

5. Blockchain and Bitcoin - Fees, Mempools, and the Bitcoin Fee Market
TODO

6. Blockchain and Bitcoin - Bitcoin Scripts and Advanced Spending Conditions
TODO

7. Blockchain and Bitcoin - Privacy and a First Look at On-chain Analysis
TODO

SLQ notes

November 16, 2025

2. Blockchain and Bitcoin - How Bitcoin Records Which Coins You Spend