§ 2.4Module 2

Transactions, UTXO, and Double Spending

2.4 — Transactions in Blockchain: UTXO and Double Spending

Recall first. Alice wants to pay Bob 3 BTC, but Alice’s wallet shows two previous receipts: 2 BTC and 2 BTC. Can she use “3 BTC from her balance” as one magical balance entry, or must the transaction refer to earlier ledger outputs? Predict before reading.

What a blockchain transaction does

A transaction is a signed instruction that changes the ledger state according to the network’s rules. In a Bitcoin-style ledger, a transaction does not simply edit a balance field from 10 to 7. It consumes previous unspent outputs and creates new outputs. The book’s Bitcoin transaction section identifies version information, inputs, outputs, and lock time, and explains that outputs of earlier transactions become inputs of later transactions. [Book: Ch. 4 “Transaction in the Bitcoin Network,” lines 3019–3040]

A simplified lifecycle is:

wallet constructs transaction
        ↓
sender signs with private key
        ↓
broadcast to peers / mempool
        ↓
nodes check signature, inputs, and rules
        ↓
miner includes it in a candidate block
        ↓
PoW and block validation accept it into the chain
        ↓
additional blocks increase confirmation confidence

The book’s earlier high-level flow describes the same movement from wallet request, to network broadcast, to validation, to block inclusion, to an updated replicated ledger. [Book: Ch. 1 §§1.5.2–1.5.3, lines 780–830]

UTXO: the spendable pieces

UTXO means Unspent Transaction Output. Each output is a conditional amount that has not yet been consumed. Its locking condition normally specifies what evidence is needed to spend it, such as a valid signature corresponding to a public key hash/address.

Think of UTXOs as physical notes rather than a bank account:

A wallet’s displayed “balance” is a derived sum of the UTXOs controlled by its keys. The wallet may hold many UTXOs even when it displays one total.

Inputs, outputs, change, and fee

An input points to a previous transaction output and supplies an authorising signature. An output specifies an amount and a locking condition for the next owner. A normal payment may have:

  1. one or more inputs from the sender;
  2. one output to the recipient;
  3. a change output back to the sender; and
  4. an implicit miner fee equal to input value minus output value.

The accounting identity is:

sum(inputs) = sum(outputs) + transaction fee

The fee is not a mysterious extra coin. It is the value of consumed inputs that is not assigned to an output; under Bitcoin’s rules it is collected by the miner who includes the transaction. [Book: Ch. 4 transaction section, lines 3041–3070]

Worked UTXO example

Alice controls:

She wants to pay Bob 3 BTC and chooses a fee of 0.01 BTC. Her wallet can construct:

Inputs:  UTXO A (2.00) + UTXO B (2.00) = 4.00 BTC
Outputs: Bob (3.00) + Alice change (0.99) = 3.99 BTC
Fee:     4.00 - 3.99 = 0.01 BTC

After confirmation, UTXO A and UTXO B no longer exist as spendable outputs. Bob controls a new 3 BTC UTXO and Alice controls a new 0.99 BTC change UTXO. Alice cannot spend the old 2 BTC outputs again.

Signatures: authorisation, not the whole validity check

The sender signs the transaction with a private key. Nodes verify the signature using the associated public information. This demonstrates control of the key required by the output’s locking condition. It does not by itself prove that:

A valid signature from a key that does not control a currently spendable output is not enough. The ledger state and protocol rules complete the validation.

Double spending

Digital data can be copied, so a digital-cash system must prevent one spendable unit from being accepted twice. Double spending occurs when the same UTXO is referenced by two conflicting transactions, for example:

T1: spend Alice's 4 BTC UTXO → Bob
T2: spend the same Alice UTXO → Alice's second address

Only one can become the accepted spend in a valid UTXO ledger. Once one transaction is confirmed, the referenced UTXO is marked spent; the conflicting transaction fails because its input is no longer unspent.

How the network resists it

  1. Nodes check that each input refers to an existing unspent output.
  2. Nodes reject a transaction that tries to spend an already-used output.
  3. Conflicting transactions may briefly appear in different mempools, but consensus chooses one valid history.
  4. In Bitcoin’s Proof-of-Work chain, a transaction included in a block gains probabilistic confidence as later blocks build on that block.

The book explains that chronological blocks, broadcast, cryptographic links, and consensus make rewriting an old spend increasingly costly, while noting that double spending is theoretically possible through attacks such as race, Finney, or majority-hash-rate attacks. [Book: Ch. 1 §1.5.3, lines 817–830]

Important distinction: a digital signature prevents an attacker from authorising a spend as the key owner; UTXO validation prevents the same output from being accepted twice; consensus decides which competing valid history is followed.

Mempool and confirmation

Before inclusion, a valid transaction is usually held in a node’s mempool, a staging area for unconfirmed transactions. Different nodes may have different mempool contents. A miner selects transactions for a candidate block, commonly considering fee rate and block-space limits. Once a valid block is accepted, the transaction is confirmed in that block. More blocks afterward are additional confirmations, not copies of the same transaction.

The book’s source describes transaction propagation, inputs/outputs/change, fees, public/private-key checks, mempool staging, and the fact that a block’s transaction data is not edited in place. [Book: Ch. 4 transaction section, lines 3041–3094]

Worked example — identify the invalid spend

A wallet has one UTXO worth 5 BTC. It broadcasts:

Both transactions have valid-looking signatures. What can happen?

Revealed answer

They conflict because both consume the same UTXO. At most one can be accepted in the same valid history. If T1 is confirmed first, T2’s input is spent and T2 is rejected; if T2 wins first, T1 is rejected. A valid signature does not make both transactions valid simultaneously. A merchant accepting an unconfirmed transaction therefore takes more double-spend risk than one waiting for confirmation.

Exercise

Alice has UTXOs of 1.2 BTC and 0.8 BTC. She wants to send 1.5 BTC and pay a 0.02 BTC fee.

  1. Which inputs must she select if she uses both UTXOs?
  2. How much change should return to Alice?
  3. What happens to the original UTXOs after confirmation?
Revealed answer
  1. Inputs total 2.0 BTC: both UTXOs are selected.
  2. Change = 2.0 − 1.5 − 0.02 = 0.48 BTC.
  3. The original 1.2 BTC and 0.8 BTC outputs are consumed. The transaction creates a 1.5 BTC output for the recipient and a 0.48 BTC change output for Alice; the 0.02 BTC difference is the fee.

Exam lens

A complete UTXO and double-spending answer should follow this chain:

  1. Define a transaction as a signed state-change instruction.
  2. Define UTXOs as unspent outputs and explain that outputs become future inputs.
  3. Show inputs = outputs + fee.
  4. Explain change output.
  5. Explain signature verification and why it is not sufficient alone.
  6. Define double spending as reusing the same UTXO in conflicting transactions.
  7. Explain node validation, mempool, block inclusion, and consensus/confirmations.

Common traps:

Rapid revision

Key takeaways

Sources