Sequence Number

What Is a Sequence Number?

A sequence number is a 32-bit unsigned integer attached to each input of a Bitcoin transaction. Originally designed by Satoshi Nakamoto for a transaction replacement mechanism that was never fully realized, the field was later repurposed to serve critical roles in modern Bitcoin: signaling whether a transaction can be replaced in the mempool, encoding relative timelocks that constrain when an input can be spent, and controlling whether the transaction's locktime is enforced.

Every transaction input has its own independent sequence number, meaning different inputs within the same transaction can have different values with different effects. This per-input granularity is what makes relative timelocks possible: each input can specify its own time-based spending condition relative to when the UTXO it references was confirmed on-chain.

Historical Context

In Bitcoin's original design, the sequence number was intended to allow in-mempool transaction replacement. The idea was simple: if two conflicting transactions spent the same inputs, nodes would keep the version with the higher sequence number. This would have enabled a primitive form of payment channels where parties could exchange updated transactions with incrementing sequence numbers.

The design was fundamentally flawed because there was no economic cost to flooding the network with replacement transactions. An attacker could generate unlimited replacements without paying fees, creating a denial-of-service vector. Satoshi disabled the feature in Bitcoin v0.3.12 (2010), and the sequence field lay dormant for years until the Bitcoin community repurposed it through three BIPs: BIP-68 (relative timelocks), BIP-112 (OP_CHECKSEQUENCEVERIFY), and BIP-125 (Replace-By-Fee).

How It Works

The 32-bit sequence number field packs multiple behaviors into a single integer. Three special values and a bit-level encoding scheme determine how the field is interpreted.

Special Values

When all inputs are set to 0xFFFFFFFF, the transaction is considered "final" and the locktime field is ignored entirely. Bitcoin Core defaults to 0xFFFFFFFE, which enables locktime (used for anti-fee sniping) but does not signal RBF.

BIP-68: Relative Timelock Encoding

BIP-68, activated at block 419,328 in July 2016, repurposes the sequence number to encode relative lock-times. This encoding only applies when two conditions are met: the transaction's version is 2 or higher, and bit 31 of the sequence value is clear (set to 0).

Bit Layout (32-bit nSequence field):

Bit 31:     Disable flag (1 = no relative timelock)
Bits 23-30: Reserved (must be zero)
Bit 22:     Type flag (0 = blocks, 1 = time)
Bits 16-21: Reserved (must be zero)
Bits 0-15:  Lock-time value (16-bit unsigned)

When bit 22 is clear, the lower 16 bits specify a number of blocks that must pass after the spent output is confirmed. The maximum is 65,535 blocks, roughly 455 days at 10 minutes per block. When bit 22 is set, the lower 16 bits are multiplied by 512 to produce a time value in seconds. The maximum is approximately 388 days.

// Block-based: wait 144 blocks (~1 day)
nSequence = 0x00000090  // 144 in hex

// Time-based: wait 86,400 seconds (~1 day)
// 86400 / 512 = 168.75, round to 169
// Set type flag (bit 22) + value 169
nSequence = 0x004000A9

// Disable relative timelock (bit 31 set)
nSequence = 0x80000001  // bit 31 set, no enforcement

The 512-second granularity was chosen deliberately. Bitcoin targets 600-second block intervals, and 512 (2⁹) provides a clean power-of-two division that simplifies implementation while offering reasonable precision for time-based locks.

BIP-125: Replace-By-Fee Signaling

BIP-125 defines the opt-in RBF signaling rule: a transaction signals replaceability if any of its inputs has a sequence number less than 0xFFFFFFFE. This means any value from 0 through 0xFFFFFFFD marks the transaction as replaceable in the mempool.

A single RBF-signaling input makes the entire transaction replaceable. The replacement must pay higher absolute fees than the original and cover its own relay cost. Additionally, any unconfirmed transaction is considered replaceable if it has an unconfirmed ancestor that signals RBF (inherited signaling).

Starting with Bitcoin Core 28.0 (October 2024), the mempoolfullrbf option defaults to on, meaning nodes accept replacements for any unconfirmed transaction regardless of sequence number signaling. This makes the BIP-125 signaling less meaningful at the policy level, though the field's relative timelock function (BIP-68) remains fully enforced at the consensus level.

Interaction with OP_CHECKSEQUENCEVERIFY

BIP-68 enforces relative timelocks at the consensus level: a transaction with a relative timelock simply cannot be mined until the referenced output is old enough. OP_CHECKSEQUENCEVERIFY (CSV), defined in BIP-112, extends this to Bitcoin Script, allowing spending conditions to require a minimum output age.

CSV takes the top value from the script stack and compares it against the spending input's sequence number. The script fails if the type flags (bit 22) do not match between the stack value and the input's nSequence, or if the stack value exceeds the input's sequence value. Together, BIP-68 and BIP-112 enable script-enforced relative timelocks that are critical for constructions like HTLCs and Lightning channels.

For a comprehensive guide to how CSV and CLTV work together, see the Bitcoin timelocks deep dive.

Use Cases

Lightning Network Revocation

Lightning channels use sequence numbers to enforce revocation mechanics. When a channel partner publishes an old commitment transaction, the to-local output includes a CSV-enforced delay (typically 144 blocks or about one day). This delay gives the other party time to broadcast a justice transaction using the revocation key, penalizing the cheater. Without relative timelocks, this dispute mechanism would not be possible.

Fee Bumping with RBF

When a transaction is stuck with an insufficient fee, the sender can create a replacement transaction with higher fees. By setting nSequence below 0xFFFFFFFE on at least one input, the original transaction signals that it may be replaced. This is especially useful during periods of high fee volatility. RBF offers an alternative to Child-Pays-For-Parent (CPFP) for accelerating confirmation.

Time-Locked Vaults

Relative timelocks can enforce withdrawal delays in vault constructions. A user deposits funds into a script that requires waiting a set number of blocks before the withdrawal completes. During this delay, if the keys are compromised, a recovery path can claw the funds back. The OP_VAULT proposal builds on this pattern using covenant-style restrictions.

Hash Time-Locked Contracts

HTLCs combine hash locks with timelocks to create conditional payments. The timeout branch of an HTLC uses CSV to specify how long the receiver has to claim funds by revealing the preimage. If the deadline passes, the sender can reclaim the funds. This pattern underpins cross-chain atomic swaps and Lightning Network routing.

Sequence Number in a Transaction

Every Bitcoin transaction input includes a sequence number alongside the outpoint (txid and output index), the scriptSig (or witness data for SegWit inputs), and other fields. Here is a simplified view of an input structure:

Transaction Input:
├── Previous Output (txid:vout)   // Which UTXO to spend
├── ScriptSig / Witness           // Unlocking script
└── nSequence (4 bytes)           // Sequence number

Example values:
  0xFFFFFFFF  → final, no RBF, no relative lock
  0xFFFFFFFE  → enable locktime, no RBF (default)
  0x00000090  → relative lock: 144 blocks
  0x00400168  → relative lock: 360 × 512 = 184,320 sec

For a complete walkthrough of how inputs, outputs, and metadata fit together, see the Bitcoin transaction lifecycle research article.

Risks and Considerations

Version Dependency

BIP-68 relative timelocks are only enforced in transactions with version 2 or higher. Version 1 transactions ignore the BIP-68 semantics entirely, even if the sequence bits are set in a way that would otherwise encode a relative timelock. Developers must ensure the transaction version is correct when relying on relative timelocks for security.

Full RBF and Signal Reliability

With full RBF now the default in Bitcoin Core 28.0, the BIP-125 sequence number signal no longer guarantees that a transaction will not be replaced. Any unconfirmed transaction may be replaced by one paying higher fees, regardless of sequence values. Applications that previously relied on the absence of RBF signaling to assume transaction finality before confirmation should no longer depend on this assumption.

Reserved Bits

Bits 16 through 21 and bits 23 through 30 are reserved and must be set to zero for current consensus validity. Future soft forks could assign meaning to these bits, potentially changing how certain sequence values are interpreted. Wallet developers should avoid setting reserved bits to prevent compatibility issues.

Complexity of Dual-Purpose Field

The sequence number serves multiple unrelated functions within a single 32-bit field. This overloading creates a risk of misconfiguration: a developer intending to signal RBF might accidentally encode a relative timelock, or vice versa. Careful attention to the bit layout and the interaction between BIP-68, BIP-112, and BIP-125 is essential when constructing transactions programmatically.

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.