Transaction Version Field

What Is the Transaction Version Field?

The transaction version field (often called nVersion) is a 4-byte signed integer that appears at the very beginning of every serialized Bitcoin transaction. It tells nodes and miners which set of validation rules should apply when processing the transaction. Think of it as a label that says "interpret my inputs and outputs according to ruleset X."

When Satoshi Nakamoto designed the Bitcoin transaction format, the version field was included as a forward-compatibility mechanism. By incrementing the version number, new consensus rules can be deployed through soft forks without breaking older transactions. Nodes that do not understand a new version still consider the transaction valid at the consensus level, though they may refuse to relay it as a matter of policy.

The field is serialized in little-endian byte order. Version 1 is written as 01000000 in raw hex, and version 2 as 02000000. In a SegWit transaction, the marker and flag bytes follow immediately after the version field.

How It Works

Every Bitcoin transaction begins with the version field, followed by the inputs, outputs, and locktime. When a node receives a transaction, it reads the version number first and uses it to determine which additional rules to enforce:

1. The node deserializes the 4-byte version field as a signed 32-bit little-endian integer
2. If the version is 2 or higher, the node applies BIP 68 rules to the sequence numbers of each input
3. If the version is 3, the node additionally applies TRUC mempool policy rules (topology limits, size constraints)
4. The version number becomes part of the transaction's serialized data and is included in the txid hash

Version 1: The Original

Version 1 transactions have been valid since Bitcoin's genesis block in January 2009. Under version 1 rules, the nSequence field on each input has no consensus meaning beyond its role in absolute locktime enforcement. A version 1 transaction can use OP_CHECKLOCKTIMEVERIFY for absolute time locks, but it cannot use relative time locks.

Version 1 transactions are still valid and relayed today. However, nearly all modern wallet software defaults to version 2 because relative timelocks are required by many protocols.

Version 2: Relative Timelocks (BIP 68)

BIP 68 introduced consensus-enforced relative lock-times by redefining how the nSequence field is interpreted for transactions with version 2 or higher. The soft fork activated at block 419,328 in July 2016.

In a version 2 transaction, the low 16 bits of each input's nSequence value encode a relative lock-time: the minimum number of blocks (or 512-second time intervals) that must pass after the referenced output confirms before the spending transaction is valid. Bit 22 determines whether the lock is measured in blocks or time, and bit 31 disables the relative lock entirely when set.

nSequence bit layout (version 2+ transactions):

Bit 31:    Disable flag (1 = no relative lock)
Bits 23-30: Reserved
Bit 22:    Type flag (0 = blocks, 1 = 512-second intervals)
Bits 16-21: Reserved
Bits 0-15:  Lock value (block count or time units)

This mechanism is the foundation for OP_CHECKSEQUENCEVERIFY (BIP 112), which allows Bitcoin Script to enforce relative timelocks on-chain. Together, BIP 68 and BIP 112 enable time-delayed spending conditions essential for protocols like Lightning Network payment channels and HTLCs.

Version 3: TRUC Transactions (BIP 431)

Version 3 transactions, formally called Topologically Restricted Until Confirmation (TRUC) transactions, were standardized in Bitcoin Core 28.0 (October 2024). Unlike versions 1 and 2, version 3 does not introduce new consensus rules. Instead, it opts the transaction into a stricter set of mempool relay policies designed to make fee-bumping more reliable.

TRUC transactions enforce the following mempool policy constraints:

• A TRUC transaction can have at most one unconfirmed parent, and at most one unconfirmed child (ancestor and descendant set sizes capped at 2)
• A child spending an unconfirmed TRUC parent is limited to approximately 1,000 virtual bytes
• TRUC transactions can be replaced more easily via replace-by-fee, since the constrained topology makes fee comparison straightforward

These restrictions eliminate transaction pinning attacks, where a counterparty inflates the descendant tree to make fee-bumping prohibitively expensive. Version 3 transactions work in concert with ephemeral anchors (BIP 433) and package relay to provide a complete solution for multi-party contract fee management.

Unknown Versions

Bitcoin's consensus rules treat transactions with unrecognized version numbers as valid. A block containing a transaction with version 4, 5, or any other value will be accepted by all nodes. However, Bitcoin Core's relay policy only considers versions 1, 2, and 3 as standard. Transactions with other version numbers will not be relayed by default, though miners can still include them in blocks.

This design allows future soft forks to assign meaning to higher version numbers without requiring a hard fork. The version bits mechanism used for miner signaling operates on block headers, not transaction versions, so the two versioning systems are independent.

Transaction Version in Raw Serialization

The version field occupies bytes 0 through 3 of every serialized transaction. Here is how the three standard versions appear in raw transaction data:

# Version 1 (original)
01000000    # 0x00000001 in little-endian

# Version 2 (BIP 68 relative timelocks)
02000000    # 0x00000002 in little-endian

# Version 3 (TRUC / BIP 431)
03000000    # 0x00000003 in little-endian

# Full transaction layout:
[version: 4 bytes]
[marker: 1 byte]    # 0x00 (SegWit only)
[flag: 1 byte]      # 0x01 (SegWit only)
[input count: varint]
[inputs: variable]
[output count: varint]
[outputs: variable]
[witness: variable] # (SegWit only)
[locktime: 4 bytes]

Use Cases

Payment Channels and Lightning

Lightning Network commitment transactions rely on version 2 to enforce relative timelocks. When a channel is force-closed, the to-local output includes an OP_CHECKSEQUENCEVERIFY condition that prevents the broadcaster from spending their funds for a set number of blocks. This delay gives the counterparty time to broadcast a justice transaction if the commitment was revoked.

Newer Lightning implementations are adopting version 3 transactions for commitment outputs, pairing them with ephemeral anchors to allow either party to fee-bump a force-close without the risk of pinning. This is a significant improvement over the previous anchor outputs design, which required each party to maintain a reserve specifically for fee-bumping. For deeper analysis of how fee dynamics affect these protocols, see the Bitcoin fee market dynamics research article.

Time-Locked Contracts

Any contract requiring a relative delay between two on-chain events needs version 2. Hash Time-Locked Contracts, Discreet Log Contracts, and vault constructions all depend on the combination of version 2 transactions and CSV to enforce their spending conditions.

Anti-Pinning for Multi-Party Protocols

Version 3 transactions address a long-standing problem in two-party and multi-party Bitcoin protocols. When two parties share a transaction (such as a Lightning commitment), either party can broadcast it. Without TRUC rules, a malicious counterparty could attach a large, low-feerate child transaction, making it expensive for the honest party to CPFP fee-bump the parent. Version 3 limits prevent this by capping the descendant size and count.

Risks and Considerations

Version Downgrade Risks

If wallet software accidentally creates a version 1 transaction when version 2 is expected, any relative timelock conditions in the spending scripts will not be enforced at the consensus level. The transaction would still be valid, but the intended delay would be absent. Wallet developers must ensure the version field matches the script conditions being used.

Policy vs. Consensus Distinction

Version 3 rules are enforced at the mempool policy level, not by consensus. A miner could include a version 3 transaction that violates TRUC topology rules in a block, and all nodes would accept that block. The security of TRUC depends on the assumption that most miners run default Bitcoin Core policy. For protocols that rely on version 3 guarantees, this is an important trust assumption to understand.

Forward Compatibility

While unknown versions are consensus-valid, using a non-standard version number means the transaction will not propagate through the network under default relay policy. Applications should only use version numbers that have defined semantics (currently 1, 2, or 3) unless they have a direct relationship with a miner who will include the transaction.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.