Transactions

Data structure composition of a transaction

A transaction is the data structure that consumes existing outputs and creates new ones. It comprises a list of inputs and a list of outputs.

Each input consists of:

1. a reference to the previous output being spent (its transaction id and output index), and
2. an unlocking script that satisfies that output's spending condition (typically a digital signature).

Each output consists of:

1. an amount, and
2. a locking script that sets the condition under which the output may later be spent.

A transaction is identified by its Transaction Identifier (TxID), the double-SHA-256 of its serialization (see Serialization format).

Input in the transaction is to have a set of fields that unlock funds from the previous unspent output. The nature of the unlocking process depends on the lock used when the output was created in the previous transaction (UTXO), which is being spent. There is no separate consensus cap on the count of inputs or outputs: both are CompactSize-prefixed lists. In practice the serialized transaction size limit (1 MB pre-Genesis, 1 GB from Genesis) binds long before encoding limits on the count field. Separately, each input's prevout index is a 32-bit field, so an individual previous transaction cannot have a spendable output at index greater than 2³²−1.

The overall data structure of a transaction is shown in the following diagram.

Internal data structure of a transaction

One of the biggest nuisances in transaction formats used in bitcoin is the usage of little endian and big endian format for different things. Always keep in mind this property as part of debugging process when developing code to build transactions.

Serialization format

This section specifies the exact byte layout of a transaction as it appears on the wire and in a block. It is the consensus serialization: two encodings of the same transaction that differ in any byte are different transactions with different TxIDs.

Ground truth. The field layout and constants below derive from CTransaction, CTxIn, CTxOut, and COutPoint in src/primitives/transaction.h, and the count/length prefixing from WriteCompactSize in src/serialize.h. All citations are pinned to release v1.2.2 (commit 879fc8b).

Conventions

• Little-endian unless stated otherwise: all integer fields (nVersion, nSequence, nLockTime, the output amount, and the CompactSize multi-byte forms) are serialized least-significant byte first.
• txid / hashes are 32-byte values written in internal byte order (the reverse of the big-endian hex string normally displayed to users).
• CompactSize is the variable-length count/length prefix — see CompactSize (VarInt).

Top-level transaction

A transaction serializes as exactly four fields, in this order (SerializeTransaction, transaction.h L227–L252):

#	Field	Type	Size (bytes)	Encoding	Notes
1	nVersion	int32	4	little-endian, signed	Default CURRENT_VERSION = 2. Pre-Chronicle standard versions are 1–2; version influences Chronicle malleability opt-outs (see Script).
2	input count	CompactSize	1–9	—	Number of inputs that follow.
3	vin	CTxIn[]	variable	—	The inputs, back to back, in order (see Input).
4	output count	CompactSize	1–9	—	Number of outputs that follow.
5	vout	CTxOut[]	variable	—	The outputs, back to back, in order (see Output).
6	nLockTime	uint32	4	little-endian, unsigned	Earliest time/height at which the transaction may be included; see nLockTime.

There is no field for the number of bytes in the transaction: total size is implied by the fields. The TxID is the double-SHA-256 of this exact byte serialization, displayed as big-endian hex (byte-reversed).

Input (CTxIn)

Each input serializes three fields (transaction.h L150–L157):

#	Field	Type	Size (bytes)	Encoding	Notes
1	prevout	COutPoint	36	see below	The output being spent.
2	scriptSig length	CompactSize	1–9	—	Byte length of the unlocking script.
3	scriptSig	bytes	variable	raw	The unlocking script (see Script).
4	nSequence	uint32	4	little-endian	Default SEQUENCE_FINAL = 0xffffffff. See nSequence.

The prevout (COutPoint, transaction.h L60–L66) is a fixed 36 bytes:

#	Field	Type	Size (bytes)	Encoding	Notes
1	txid	hash	32	internal byte order	TxID of the transaction containing the output being spent.
2	n	uint32	4	little-endian	Index of the output within that transaction (0-based). Because this field is 4 bytes, an output at index > 0xffffffff (4,294,967,295) could never be referenced by any input.

Output (CTxOut)

Each output serializes two fields (transaction.h L188–L193):

#	Field	Type	Size (bytes)	Encoding	Notes
1	nValue	int64	8	little-endian, signed	Amount in satoshis. Must be in [0, MAX_MONEY]; MAX_MONEY = 21,000,000 × 100,000,000 satoshis.
2	scriptPubKey length	CompactSize	1–9	—	Byte length of the locking script.
3	scriptPubKey	bytes	variable	raw	The locking script (see Script).

COIN = 100,000,000 satoshis; MAX_MONEY is a consensus value (amount.h L115–L133).

CompactSize (VarInt)

Every count and script-length prefix above is a CompactSize: a 1-, 3-, 5-, or 9-byte little-endian unsigned integer whose width is chosen by the value (WriteCompactSize, serialize.h L296–L313):

Value range	Total bytes	Encoding
0 … 252	1	the value as a single byte
253 … 65,535	3	0xfd then the value as uint16 little-endian
65,536 … 4,294,967,295	5	0xfe then the value as uint32 little-endian
4,294,967,296 … 2⁶⁴−1	9	0xff then the value as uint64 little-endian

The encoding must be canonical: a value must use the shortest form that fits, and the decoder rejects a non-minimal encoding (serialize.h ReadCompactSize L315).

nLockTime

nLockTime (4-byte LE uint32) sets the earliest point at which a transaction may be mined. It is interpreted against the threshold LOCKTIME_THRESHOLD = 500,000,000 (script.h L36):

nLockTime value	Interpretation
0	No lock — the transaction is final immediately.
1 … 499,999,999	A block height; the transaction is not final until that height.
≥ 500,000,000	A Unix timestamp; the transaction is not final until that time (median-time-past).

nLockTime has no effect if every input has nSequence = 0xffffffff (SEQUENCE_FINAL), in which case the transaction is final regardless. The precise finality test is a consensus rule — see the Consensus Rules page.

nSequence

nSequence is a 4-byte little-endian uint32 on every input. Its only role that bears on validity in the current protocol is the finality flag: an input with nSequence == 0xffffffff (SEQUENCE_FINAL) is final, and if every input is final the transaction is final regardless of nLockTime (see nLockTime and the finality rule on the Consensus Rules page).

BIP68 relative locktime — pre-Genesis only

The nSequence field also carries the BIP68 relative-locktime bit-fields (transaction.h L99–L129):

Constant	Value	Meaning
SEQUENCE_FINAL	0xffffffff	Input is final; disables nLockTime when set on all inputs.
SEQUENCE_LOCKTIME_DISABLE_FLAG	1 << 31 (0x80000000)	When set, nSequence is not interpreted as a relative locktime.
SEQUENCE_LOCKTIME_TYPE_FLAG	1 << 22 (0x00400000)	When set, the relative locktime is measured in units of 512 seconds; otherwise in blocks.
SEQUENCE_LOCKTIME_MASK	0x0000ffff	Masks the low 16 bits, which hold the relative-locktime value.
SEQUENCE_LOCKTIME_GRANULARITY	9	Time-based value is multiplied by 2⁹ = 512 seconds.

On BSV, BIP68 relative-locktime is not enforced after Genesis. The relative lock is applied only when the LOCKTIME_VERIFY_SEQUENCE verify flag is active, and that flag is set only for pre-Genesis blocks — StandardNonFinalVerifyFlags adds it only when Genesis is not active (src/policy/policy.h L248–L256). This mirrors OP_CHECKSEQUENCEVERIFY (OP_CSV), which reverts to a no-op at Genesis (see Opcodes). After Genesis the bit-fields above are inert: the only consensus effect of nSequence is the SEQUENCE_FINAL finality check described above.

Where it does apply (pre-Genesis, transaction version ≥ 2, disable flag clear): the low 16 bits give the relative locktime — a count of blocks, or (if the type flag is set) a count of 512-second intervals — that must elapse after the spent output was confirmed, computed by CalculateSequenceLocks (src/validation.cpp L257–L326).

Coinbase transaction

The first transaction in every block is the coinbase. It is structurally a normal transaction with exactly one input whose prevout is null — a txid of all zeroes and n = 0xffffffff (COutPoint::IsNull, transaction.h L68). Its scriptSig is not evaluated as script and carries the block-height prefix (BIP34) plus arbitrary miner data. The additional coinbase-specific rules (scriptSig length bounds, output value = subsidy + fees, maturity) are consensus rules covered on the Consensus Rules and Blocks pages.

Size limits by era

The maximum serialized transaction size is a consensus limit that changed at Genesis (consensus.h L27–L29):

Limit	Pre-Genesis	Genesis onward
MAX_TX_SIZE_CONSENSUS	1,000,000 bytes (1 MB)	1,000,000,000 bytes (1 GB)

This is the consensus bound on validity. Miners may additionally apply smaller policy limits to transactions they accept or relay; those are configurable and do not bear on whether a transaction is valid.