Bitcoin transaction design — UTXO model, Script, and signature schemes

Introduction

This page is L1 #2 — Transaction design in the design-document series. It covers the transaction layer end-to-end: how value is represented, transferred, locked, and unlocked. Everything in Bitcoin — mining incentives, block weight, fee markets, wallet UX — rests on the structures described here.

New to these concepts? What owning a bitcoin actually means introduces UTXOs, keys, and transactions with no prior knowledge assumed; this page is the design-document treatment of the same transaction layer, including the Bitcoin Script mechanics that page does not cover. Forensicxs’s 2024 code walkthrough traces the same Forth-based Script system back to the v0.1 source it first shipped in.

The transaction layer answers three questions:

1. What is a coin? An unspent transaction output (UTXO) — not an account balance.
2. What does a valid spend look like? A transaction that consumes existing UTXOs, proves authorization via cryptographic signatures, and creates new UTXOs.
3. How is authorization expressed? Through Bitcoin Script — a stack-based language that evaluates locking and unlocking conditions.

Where behavior differs between the Satoshi-era implementation (v0.1, January 2009) and modern Bitcoin Core (v27+ baseline), both are noted.

The v0.1 transaction path in source

The v0.1 source makes the UTXO model concrete. CTransaction in the pinned commit 4184ab2, src/main.h lines 193–363, stores inputs, outputs, and locktime; ConnectInputs in src/main.cpp lines 772–854 follows each referenced output, rejects an immature coinbase, verifies the signature, checks whether the output is already spent, marks it spent, and computes the fee as input value minus output value. The script side is a separate but connected path: OP_CHECKSIG in src/script.cpp lines 692–901 removes the signature from the script being signed, constructs the legacy signature hash, and verifies the resulting digest against the public key.

These references document the January 2009 implementation rather than claiming that modern Bitcoin Core follows the same internal code path. The later sections therefore keep the v0.1 and modern baselines separate.

The separate v0.1 serialization-boundary analysis maps which bytes enter transaction, block, and signature hashes and how those objects are reused across network and disk paths.

1. The UTXO model

Bitcoin does not track balances. Instead, every transaction creates one or more discrete outputs, each carrying a specific amount and a locking condition. An output that has not yet been consumed by a later transaction is an unspent transaction output (UTXO). The set of all UTXOs at any moment is the complete picture of who can spend what.

UTXO lifecycle

A “coin” is simply an entry in the UTXO set; a wallet’s “balance” is the sum of every UTXO it can unlock.

UTXO model vs account model

2. Transaction structure

A transaction is a signed message that consumes one or more existing UTXOs (inputs) and creates one or more new UTXOs (outputs). The difference between total input value and total output value is the transaction fee, collected by the miner who includes the transaction in a block.

Transaction anatomy

Field-by-field breakdown

Satoshi era vs v27+ baseline: transaction format

3. Bitcoin Script

Bitcoin transactions are not locked to public keys directly. Instead, each output carries a small program called a locking script (scriptPubKey), and each input provides an unlocking script (scriptSig or witness data) that satisfies the locking condition. Bitcoin Script is the stack-based language in which these programs are written.

Script evaluation flow

The interpreter processes opcodes sequentially. It pushes data items onto the stack, then executes operations that consume and produce stack elements. If the stack’s top element is nonzero (true) after all opcodes have been processed, the spend is valid.

Common script patterns

Script evolution: v0.1 to v27+

4. Signature schemes

Cryptographic signatures are the mechanism by which a spender proves they control the private key associated with a UTXO’s locking condition. Bitcoin has used two signature schemes across its history.

ECDSA vs Schnorr

Signing and verification flow

The spender constructs the transaction — its inputs, outputs, and locktime — before signing it; on the receiving side, a verifying node identifies the public key the spend must match before recomputing the digest: from the previous output’s locking script for Taproot’s key-path spend, or from the input’s own unlocking data for P2PKH and P2WPKH.

5. SegWit and Taproot

SegWit (Segregated Witness, 2017) and Taproot (2021) are the two major structural changes to Bitcoin’s transaction format since its creation. Both are backward-compatible soft forks. When Mt. Gox halted withdrawals in February 2014 it blamed transaction malleability, the flaw the fix below closes, but a study of the network over the preceding year found no widespread use of malleability attacks before the exchange closed.

Structural comparison

Key innovations

6. Coin selection

When a wallet builds a transaction, it must choose which UTXOs to spend as inputs. This is the coin selection problem. The choice affects transaction size (and therefore fees), privacy (which UTXOs become linked on chain), and the future shape of the wallet’s UTXO pool.

Modern Bitcoin Core (v27+ baseline) runs several algorithms (BnB, knapsack, single random draw, and at high fee rates CoinGrinder) and keeps the result with the lowest waste. Satoshi’s v0.1 SelectCoins was the knapsack’s ancestor: an exact match if one existed, otherwise the best of 1,000 randomized subset-sum passes over the smaller coins, compared with the single smallest coin larger than the target.

7. Two-era comparison

8. Limits of this page

This page covers the transaction layer in isolation. The following topics are out of scope and addressed in their respective domain pages within the design-document series:

• Block structure and Merkle trees — how transactions are batched into blocks and committed via Merkle roots.
• Mining and proof-of-work — the incentive mechanism that selects which transactions enter the blockchain.
• Mempool policy — relay rules, fee-rate floors, and package relay that govern transaction propagation before confirmation.
• Network-layer transaction relay — how inv, getdata, and tx messages propagate transactions across the P2P network.
• Lightning Network and payment channels — layer-2 constructions that build on the transaction primitives described here.
• Wallet key derivation — BIP 32/44/84/86 HD key trees and descriptor wallets that generate the addresses used in locking scripts.

The transaction is the object every other design page touches. It is block contents in the block-chain design, the consumer of signatures and hashes in the cryptography design, the coinbase and fee mechanism in the monetary design, the propagation payload in the P2P network design, the UTXO-set update unit in the storage design, the constructed and signed object in the wallet design, and the unit the fee market and the Lightning Network operate on in the ecosystem design.