Chapter 10

Transactions

The Fundamental Unit of Value Transfer

A Bitcoin transaction is a signed data structure that transfers value from one or more sources to one or more destinations. Understanding transaction structure is essential—every bitcoin that exists can be traced through an unbroken chain of transactions back to its creation in a coinbase.

In this chapter, we examine the precise byte-level format of transactions, the UTXO model that governs value flow, and the serialization rules that determine transaction identifiers.

10.1 The UTXO Model

Bitcoin does not track account balances. Instead, it tracks individual chunks of value called unspent transaction outputs.

Definition 10.1 (UTXO)

An Unspent Transaction Output (UTXO) is a transaction output that has not yet been consumed as an input to another transaction. Each UTXO represents a discrete amount of bitcoin locked to a specific spending condition.

The UTXO set is the complete collection of all unspent outputs at any given moment. A full node maintains this set and updates it with each new block.

Transaction A Output 0: 0.5 BTC Output 1: 0.3 BTC spent Transaction B Input: A:0 Output 0: 0.2 BTC Output 1: 0.29 BTC UTXOs A:1 remains unspent (UTXO) Fee: 0.01 BTC
Figure 10.1: Transaction B spends output 0 from Transaction A. Output 1 from A and both outputs from B remain as UTXOs.

Remark 10.1 (No Partial Spending)

A UTXO must be spent entirely—you cannot spend "part" of an output. If you wish to send less than a UTXO's full value, you create a transaction with one output to the recipient and another "change" output back to yourself.

Theorem 10.1 (Conservation of Value)

For any valid non-coinbase transaction:

Σ(input values) ≥ Σ(output values)

The difference Σ(inputs) − Σ(outputs) is the transaction fee, claimed by the miner who includes the transaction in a block.

10.2 Transaction Structure

A Bitcoin transaction consists of four main components, serialized in a specific order.

Definition 10.2 (Transaction)

A transaction is a data structure containing:

  1. Version (4 bytes): Protocol version number
  2. Inputs (variable): List of transaction inputs
  3. Outputs (variable): List of transaction outputs
  4. Locktime (4 bytes): Earliest time/block for inclusion
Transaction Structure Version 4 bytes Inputs variable Outputs variable Locktime 4 bytes Serialization order (little-endian integers)
Figure 10.2: High-level transaction structure.

10.2.1 Version Field

The version field indicates which transaction validation rules apply.

Version Meaning
1 Original transaction format
2 BIP-68 relative lock-time semantics enabled

The version is encoded as a 4-byte little-endian integer. Version 1 is 01000000 in hex; version 2 is 02000000.

10.2.2 Locktime

Definition 10.3 (Locktime)

The locktime field specifies the earliest time a transaction can be included in a block:

  • If locktime < 500,000,000: interpreted as a block height
  • If locktime ≥ 500,000,000: interpreted as a Unix timestamp
  • If locktime = 0: no restriction (immediately valid)

Locktime enables time-locked transactions—useful for inheritance planning, escrow, and payment channels.

10.3 Transaction Inputs

Each input references a specific output from a previous transaction and provides proof of authorization to spend it.

Definition 10.4 (Transaction Input)

A transaction input consists of:

  1. Outpoint (36 bytes): Reference to the UTXO being spent
    • Previous txid (32 bytes)
    • Output index (4 bytes)
  2. ScriptSig (variable): Unlocking script (empty for SegWit)
  3. Sequence (4 bytes): Sequence number for replacement/locktime
Transaction Input Outpoint (36 bytes) prev_txid (32) vout (4) ScriptSig variable (unlocking script) Sequence 4 bytes
Figure 10.3: Structure of a transaction input.

10.3.1 The Outpoint

An outpoint uniquely identifies a UTXO by specifying which transaction created it and which output within that transaction.

Example 10.1 (Outpoint Reference)

To spend output index 1 from transaction with txid:

a1b2c3d4e5f6...789012345678abcdef

The outpoint would be (in serialized form):

# txid (32 bytes, reversed for little-endian)
efcdab78563412...f6e5d4c3b2a1
# output index (4 bytes, little-endian)
01000000

10.3.2 Sequence Numbers

Originally intended for transaction replacement, sequence numbers now serve multiple purposes:

Value Meaning
0xFFFFFFFF Final; locktime disabled for this input
0xFFFFFFFE Locktime enabled, RBF disabled
< 0xFFFFFFFE RBF enabled (BIP-125); may encode relative locktime (BIP-68)

10.4 Transaction Outputs

Each output specifies an amount and a locking condition.

Definition 10.5 (Transaction Output)

A transaction output consists of:

  1. Value (8 bytes): Amount in satoshis (little-endian)
  2. ScriptPubKey (variable): Locking script defining spending conditions

Definition 10.6 (Satoshi)

A satoshi is the smallest unit of bitcoin:

1 BTC = 100,000,000 satoshis = 10⁸ satoshis

All values in Bitcoin are represented internally as integer satoshis.

Transaction Output Value 8 bytes (sats) ScriptPubKey variable (locking script)
Figure 10.4: Structure of a transaction output.

Example 10.2 (Output Value Encoding)

To encode 0.01 BTC (1,000,000 satoshis):

1,000,000 = 0x0F4240

# As 8-byte little-endian:
40420f0000000000

10.5 Standard ScriptPubKey Types

While Bitcoin Script allows arbitrary programs, most outputs use one of several standard templates.

10.5.1 P2PKH (Pay-to-Public-Key-Hash)

Definition 10.7 (P2PKH ScriptPubKey)

A P2PKH output has the locking script:

OP_DUP OP_HASH160 <20-byte-pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG

In hex: 76a914{hash}88ac

10.5.2 P2SH (Pay-to-Script-Hash)

Definition 10.8 (P2SH ScriptPubKey)

A P2SH output has the locking script:

OP_HASH160 <20-byte-script-hash> OP_EQUAL

In hex: a914{hash}87

10.5.3 Native SegWit (P2WPKH, P2WSH)

Definition 10.9 (Witness Program)

A native SegWit output has a scriptPubKey of the form:

<witness-version> <witness-program>

For P2WPKH: 0014{20-byte-hash}
For P2WSH: 0020{32-byte-hash}

10.5.4 Taproot (P2TR)

Definition 10.10 (P2TR ScriptPubKey)

A Taproot output has the locking script:

OP_1 <32-byte-x-only-pubkey>

In hex: 5120{pubkey}

Type ScriptPubKey Pattern Size (bytes)
P2PKH 76a914{20}88ac 25
P2SH a914{20}87 23
P2WPKH 0014{20} 22
P2WSH 0020{32} 34
P2TR 5120{32} 34

10.6 Segregated Witness

Segregated Witness (SegWit), activated in August 2017, separates signature data from the main transaction structure.

Definition 10.11 (Witness)

The witness is a separate data structure containing the signatures and other data needed to validate SegWit inputs. It is not included in the transaction hash (txid) but is included in the witness transaction hash (wtxid).

10.6.1 SegWit Transaction Format

A SegWit transaction includes additional marker, flag, and witness fields:

Version 4 Marker 0x00 Flag 0x01 Inputs Outputs Witness (signatures) Locktime SegWit Transaction Structure SegWit markers
Figure 10.5: SegWit transaction structure with marker, flag, and witness fields.

10.6.2 Transaction IDs

Definition 10.12 (Txid and Wtxid)

The txid is the double-SHA256 hash of the "legacy" serialization (version, inputs, outputs, locktime)—excluding marker, flag, and witness.

The wtxid is the double-SHA256 hash of the complete serialization including witness data.

This separation is crucial: the txid remains unchanged regardless of witness data, preventing certain forms of transaction malleability.

10.7 Signature Hash Types

When signing an input, the signer commits to a specific subset of the transaction data. The sighash type determines what is signed.

Definition 10.13 (Sighash Types)

Bitcoin defines the following signature hash types:

Type Value Signs Inputs Signs Outputs
SIGHASH_ALL 0x01 All All
SIGHASH_NONE 0x02 All None
SIGHASH_SINGLE 0x03 All Same index only
SIGHASH_ANYONECANPAY 0x80 (Modifier: signs only this input)

SIGHASH_ANYONECANPAY can be combined with any of the first three types, yielding six valid sighash values in total.

Example 10.3 (Sighash Applications)

  • SIGHASH_ALL: Standard signing. Commits to the entire transaction.
  • SIGHASH_NONE: "Blank check"—anyone can add outputs.
  • SIGHASH_SINGLE: Useful for atomic swaps.
  • SIGHASH_ANYONECANPAY | SIGHASH_ALL: Crowdfunding—others can add inputs.

10.8 Transaction Fees

Transaction fees incentivize miners and prevent spam.

Definition 10.14 (Transaction Fee)

The transaction fee is the difference between total input value and total output value:

fee = Σ(input values) − Σ(output values)

Fees are typically measured in satoshis per virtual byte (sat/vB).

10.8.1 Virtual Size

SegWit introduced weight units to discount witness data.

Definition 10.15 (Transaction Weight)

The weight of a transaction is:

weight = (base size × 3) + total size

where base size excludes witness data and total size includes it.

The virtual size (vsize) is:

vsize = ⌈weight / 4⌉

This formula gives witness data a 75% discount, encouraging SegWit adoption while maintaining backward compatibility with the 1 MB block limit (now measured as 4 million weight units).

10.9 A Complete Transaction Example

Example 10.4 (Parsing a Raw Transaction)

Consider this SegWit transaction (simplified):

02000000                                  # Version 2
0001                                      # SegWit marker + flag
01                                        # 1 input
  a1b2c3...32bytes...txid                 # Previous txid
  01000000                                # Output index 1
  00                                      # Empty scriptSig (SegWit)
  fdffffff                                # Sequence (RBF enabled)
02                                        # 2 outputs
  40420f0000000000                        # Output 0: 1,000,000 sats
  160014{20-byte-witness-program}         # P2WPKH scriptPubKey
  a086010000000000                        # Output 1: 100,000 sats (change)
  160014{20-byte-witness-program}         # P2WPKH scriptPubKey
02                                        # Witness stack for input 0
  47{71-byte-signature}                   # Signature
  21{33-byte-compressed-pubkey}           # Public key
00000000                                  # Locktime: 0

10.10 The Coinbase Transaction

Every block contains exactly one special transaction: the coinbase.

Definition 10.16 (Coinbase Transaction)

A coinbase transaction is the first transaction in every block. It has:

  • Exactly one input with a null outpoint (32 zero bytes + 0xFFFFFFFF)
  • ScriptSig containing arbitrary data (the "coinbase" field)
  • Outputs that may claim the block reward plus fees

Theorem 10.2 (Coinbase Constraint)

The total output value of a coinbase transaction must not exceed:

subsidy + Σ(fees of all transactions in the block)

Any value not claimed is permanently lost (burned).

The coinbase scriptSig must contain the block height (BIP-34) and can include arbitrary data—famously used by Satoshi to embed the headline "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks."

Exercises

Exercise 10.1

A transaction has inputs totaling 0.5 BTC and outputs totaling 0.499 BTC. What is the fee? If the transaction is 250 vbytes, what is the fee rate in sat/vB?

Exercise 10.2

Explain why a P2WPKH output is more efficient than a P2PKH output, considering both the output scriptPubKey size and the spending input size.

Exercise 10.3

A legacy transaction has base size 225 bytes. A SegWit transaction spending the same inputs has base size 150 bytes and witness size 110 bytes. Calculate the weight and vsize of each.

Exercise 10.4

Why does the coinbase transaction need a special 100-block maturity rule before its outputs can be spent? What problem does this prevent?

Exercise 10.5

Describe a scenario where SIGHASH_ANYONECANPAY | SIGHASH_ALL would be useful. What are the security considerations?