Transactions

A Bitcoin transaction consumes previously created outputs and creates new outputs. Consensus validation distinguishes the serialized transaction bytes, the identifiers derived from those bytes, and the contextual checks that depend on the UTXO set and block height.

Identifier and amount primitives

Transaction records

Witness is vector<varbytes>. It is present only in witness serialization and has exactly one stack per input.

Legacy serialization

$E_0(tx)$, the legacy transaction serialization, is:

$$ version || inputs || outputs || lockTime. $$

Witness serialization

$E_w(tx)$, the witness transaction serialization, is:

$$ version || marker || flag || inputs || outputs || witnesses || lockTime. $$

The witness form is valid only when at least one witness stack is nonempty. A transaction with no witness data uses legacy serialization for both Txid and Wtxid (sources: bip-0141,bip-0144).

Transaction identifiers

Context-free validity

A transaction is context-free valid only if:

1. it has at least one input and at least one output;

2. its stripped size satisfies $strippedSize(tx) * WITNESS_SCALE_FACTOR <= MAX_BLOCK_WEIGHT$;

3. every output value is in range;

4. the sum of output values is in range;

5. no two inputs reference the same previous output;

6. if it is coinbase, it has exactly one input whose previous output is the null outpoint and whose scriptSig length is between COINBASE_SCRIPTSIG_MIN and COINBASE_SCRIPTSIG_MAX bytes; and

7. if it is not coinbase, no input uses the null outpoint.

Context-free validity does not prove the inputs exist or signatures are valid; those checks require the UTXO set and rule context (sources: bitcoin-core-v31).

Coinbase transaction

A coinbase transaction has exactly one input whose previous output is the null outpoint defined by NULL_TXID and NULL_INDEX. Its input does not spend a UTXO. Its outputs create the block subsidy and collect fees, subject to the coinbase amount rule during block connection.

Coinbase-created outputs require COINBASE_MATURITY confirmations before they may be spent.

Value conservation

For a non-coinbase transaction:

$$ fee(tx) = \sum value(spentInputs(tx)) - \sum value(outputs(tx)). $$

The transaction is invalid if any referenced input is absent, any spent coin is immature coinbase, any output is outside the money range, the output sum is outside the money range, or fee(tx) is negative (sources: bitcoin-core-v31).

Locktime and sequence

lockTime values below LOCKTIME_THRESHOLD are block heights; values at or above that threshold are Unix times. For a candidate block at height $h$ with rule context $R$ and locktime cutoff $t$, define the selected lock boundary:

$$ \ell(tx,h,t)= \begin{cases} h, & tx.\text{\code{lockTime}} < \text{\code{LOCKTIME_THRESHOLD}},\ t, & tx.\text{\code{lockTime}} \ge \text{\code{LOCKTIME_THRESHOLD}}, \end{cases} $$

$$ \begin{aligned} \operatorname{AbsFinal}(tx,h,t) \Longleftrightarrow;& tx.\text{\code{lockTime}}=0 \vee tx.\text{\code{lockTime}} < \ell(tx,h,t) \vee {}\ &\forall i:\ tx.\text{\code{inputs}}[i].\text{\code{sequence}} = \text{\code{SEQUENCE_FINAL}}. \end{aligned} $$

If $R$ includes BIP113, $t=MTP(C,h-1)$; otherwise $t$ is the candidate block timestamp.

If $R$ includes BIP68, relative locks apply only to version-2-or-higher transactions and only to inputs whose sequence does not set SEQUENCE_LOCKTIME_DISABLE_FLAG. For validation view $V$, define $SeqFinal(tx,C,V,h)$ as follows. If $tx.version < 2$, it is true. Otherwise, for each applicable input $i$, let $s_i$ be its sequence value, $v_i=s_i \mathbin& SEQUENCE_LOCKTIME_MASK$, and $c_i$ be the height of the coin spent by input $i$ in $V$. Height locks require:

$$ h > c_i + v_i - 1. $$

When $s_i$ sets SEQUENCE_LOCKTIME_TYPE_FLAG, the input is time locked instead. Let $\tau_i=MTP(C,c_i-1)$. Time locks require:

$$ \operatorname{MTP}(C,h-1) > \tau_i + v_i \cdot \text{\code{SEQUENCE_LOCKTIME_GRANULARITY}} - 1. $$

The transaction satisfies relative locks iff every applicable input satisfies its selected height or time constraint; disabled inputs impose no constraint. If $R$ does not include BIP68, $SeqFinal$ is true (sources: bip-0068,bip-0112,bip-0113,bitcoin-core-v31).

Signature hashes

Signature validation signs a digest derived from the transaction, input index, spent output, hash type, and active script version. Legacy, SegWit v0, and Taproot/Tapscript spend paths use different digest algorithms, specified in Section Script. These digests are consensus-critical because the signature checks validate exactly those bytes.