Lesson 0002: Transaction Structure & the UTXO Model

The UTXO Model: There Are No Accounts

Bitcoin does not have accounts or balances. This is the single most important thing to internalize. Instead, Bitcoin uses the UTXO model (Unspent Transaction Output).

Analogy: Physical Cash

Imagine you have a $20 bill and a $5 bill in your pocket. You don't have a "$25 account" — you have two specific, indivisible notes. To pay $23, you hand over the $20 bill and the $5 bill, receive $2 in change (a new note), and destroy the original two notes. This is exactly how Bitcoin works: UTXOs are indivisible (you must spend them entirely), and change comes back as a new UTXO.

Transaction Structure: The Raw Anatomy

A Bitcoin transaction is a binary message with a well-defined structure. Here's the complete field layout:

TxIn: The Input Structure

TxOut: The Output Structure

Locking Scripts (ScriptPubKey) & Unlocking Scripts (ScriptSig)

This is where Bitcoin's programmability lives. Every output has a locking script (ScriptPubKey) — a small program written in Bitcoin Script that defines the conditions for spending. When someone wants to spend that output, they provide an unlocking script (ScriptSig) that satisfies those conditions.

The validation process concatenates the two scripts — ScriptSig first, then ScriptPubKey — and executes them on a stack machine. If execution completes without error and leaves a true (non-zero) value on the stack, the spend is authorized.

The Most Common Pattern: P2PKH (Pay to Public Key Hash)

OP_DUP
OP_HASH160
<pubkey-hash>
OP_EQUALVERIFY
OP_CHECKSIG

<signature>
<public-key>

Stack: []
  1. Push <sig>        → [sig]
  2. Push <pubkey>      → [sig, pubkey]
  3. OP_DUP              → [sig, pubkey, pubkey]
  4. OP_HASH160          → [sig, pubkey, hash(pubkey)]
  5. Push <pubkey-hash> → [sig, pubkey, hash(pubkey), pubkey-hash]
  6. OP_EQUALVERIFY      → [sig, pubkey]  (fails if hashes don't match)
  7. OP_CHECKSIG         → [true]  (fails if sig doesn't match pubkey)
  → VALID ✓

The genius of this system: the sender doesn't need to know the recipient's public key — just its hash. The recipient reveals their public key only at spending time, providing a layer of privacy. Once spent, the public key is visible on-chain, which is why address reuse is discouraged.

The Fee Mechanism: Inputs − Outputs = Fee

There is no "fee" field in a transaction. The fee is implicit:

The miner who includes the transaction collects this difference. Because UTXOs must be spent in full, you almost always need a change output — an output sending the excess back to yourself (to a fresh address).

Example Transaction

Alice wants to pay Bob 0.01 BTC. She has one UTXO worth 0.05 BTC.

Inputs:  1 UTXO (0.05 BTC)         = 5,000,000 sat
Outputs:
  → Bob:       0.01 BTC            = 1,000,000 sat
  → Change:    0.0399 BTC          = 3,990,000 sat
Fee:           0.0001 BTC          =    10,000 sat

5,000,000 − (1,000,000 + 3,990,000) = 10,000 sat fee

The Chain of Ownership

Every transaction (except coinbase) consumes UTXOs and creates new ones. This creates a directed graph of ownership, traceable all the way back to the coinbase transactions that originally created the bitcoin. A valid transaction is one where every input's ScriptSig correctly unlocks the ScriptPubKey of the UTXO it references.

Coinbase Tx         Tx A                Tx B (Alice→Bob)
┌──────────┐       ┌──────────┐         ┌──────────┐
│ Input:   │       │ Input:   │         │ Input:   │
│  (none)  │       │  ┌──────┐│         │  ┌──────┐│
│          │       │  │CB out││─────────│──│TxA #1││
│ Output:  │───┐   │  └──────┘│         │  └──────┘│
│  50 BTC  │   │   │          │         │          │
│  (UTXO)  │   │   │ Output:  │         │ Output:  │
└──────────┘   │   │  25 BTC──│─────────│→ 0.01 BTC│ (Bob's UTXO)
               └───│→(UTXO)   │         │          │
                   └──────────┘         │  24.99──│→ (Change UTXO)
                                        └──────────┘

Coinbase Transactions: The Exception

The coinbase transaction (first transaction in every block) breaks the rules:

• It has exactly one input with a null outpoint (txid = 32 zero bytes, vout = 0xffffffff).
• The ScriptSig can contain arbitrary data (up to 100 bytes) — miners use this for the extra nonce and to embed messages (like the famous "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the genesis block).
• It creates new bitcoin: the block subsidy (currently 3.125 BTC after the 2024 halving) plus all fees from transactions in the block.
• Coinbase outputs cannot be spent for 100 blocks (the maturity requirement).

Standard Transaction Types (Quick Reference)

Key Takeaways

1. Bitcoin has no accounts — only UTXOs. Your "balance" is the sum of UTXOs you can unlock.
2. A transaction consumes UTXOs (inputs) and creates new UTXOs (outputs). UTXOs are indivisible — you always spend the full amount.
3. Every output has a locking script (ScriptPubKey). Every input provides an unlocking script (ScriptSig) that must satisfy it.
4. Fee = inputs − outputs. There is no explicit fee field. Change outputs send excess back to the spender.
5. The coinbase transaction is the sole exception — it creates bitcoin from nothing and has no real input.
6. Addresses encode script conditions — "1..." = P2PKH, "3..." = P2SH, "bc1q..." = SegWit v0, "bc1p..." = Taproot.

Navigate