Version

Just like software updates labeled as v1.0, v2.0, v3.0, Bitcoin transactions use version numbers to indicate which features they support.

TransactionVersion
Structure
Version
4 bytes
Segwit (Optional)
Marker
1 byte
Flag
1 byte
Structure
Input Count
variable
Input Structure
Previous TXID
32 bytes
Output Index
4 bytes
ScriptSig Size
variable
ScriptSig
variable
Sequence
4 bytes
Structure
Output Count
variable
Output Structure
Amount
8 bytes
ScriptPubKey Size
variable
ScriptPubKey
variable
Structure
Witness
variable
Structure
Locktime
4 bytes

Size

4 bytes

Format

Little-Endian

Description

The version number for the transaction. Used to enable new features.

Example

02000000

Byte Visualization

02
Byte 1
00
Byte 2
00
Byte 3
00
Byte 4
  1. Version 1: The original transaction format that follows basic Bitcoin transaction rules.

  2. Version 2: Introduced in BIP68, BIP112, and BIP113, enabling:

    • OP_CHECKSEQUENCEVERIFY (CSV): Allows relative timelock constraints
    • Relative lock-time: Prevents spending until a certain number of blocks have passed
    • Median-time-past: Uses median timestamp of previous 11 blocks for time-based locks
  3. Version 3: Introduced to prevent transaction pinning attacks

Note

Don't worry if these new terms seem complex - we'll cover timelocks, CSV operations, and more in detail in later sections!

Encoding

The version is stored as a 4-byte integer in little-endian format. For example:

  • Hex: 01000000 → Version: 1
  • Hex: 02000000 → Version: 2

Most transactions today use version 1 or 2, with version 2 being necessary when using relative timelocks or CSV operations.

Suggest Edits