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.
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:
- Version (4 bytes): Protocol version number
- Inputs (variable): List of transaction inputs
- Outputs (variable): List of transaction outputs
- Locktime (4 bytes): Earliest time/block for inclusion
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:
- Outpoint (36 bytes): Reference to the UTXO being spent
- Previous txid (32 bytes)
- Output index (4 bytes)
- ScriptSig (variable): Unlocking script (empty for SegWit)
- Sequence (4 bytes): Sequence number for replacement/locktime
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:
- Value (8 bytes): Amount in satoshis (little-endian)
- 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.
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:
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?