Bitcoin Locktime and Sequence Numbers: Relative Timelocks Explained
You've just signed a transaction. It's structurally valid, properly witnessed, ready to broadcast. And it will sit there, inert, for the next 144 blocks, because you encoded that wait directly into the transaction itself before you ever handed it to the network. That's a timelock. Bitcoin has carried some version of one since Satoshi's original code, and most people who've heard the term assume it's a single, unified mechanism. It isn't. There are two separate timelock systems layered on top of each other, and they interact in a way that took years of careful protocol work to get right.
Let's be precise about what each piece actually does.
The Original Tool: nLocktime
nLocktime is a four-byte field on every Bitcoin transaction. It instructs the network not to mine the transaction before a certain point. That point can be expressed two ways: if the value falls below 500,000,000, it's interpreted as a block height; at or above 500,000,000, it's read as a Unix timestamp.
A transaction with nLocktime set to 800,000 won't be valid until block 800,000 exists. One set to 1,700,000,000 won't be valid until the network's median time past reaches that Unix timestamp.
Simple enough. But there is a catch that trips up almost everyone who first reads about this.
nLocktime is an absolute timelock. It pins the transaction to a specific moment fixed at signing time. If you and a counterparty want to build a payment channel where each new state is valid only after some delay from the previous state, absolute timelocks cannot do that cleanly. You would have to pre-calculate exact future block heights, which collapses the entire point of a flexible channel. That gap is exactly why relative timelocks were invented.
Sequence Numbers: The Field That Almost Did Nothing
nSequence is a four-byte field attached to each input in a transaction, not the transaction itself. Satoshi originally intended it for transaction replacement: a higher sequence number on a new version of the same transaction would signal the preferred version to nodes. The idea was abandoned almost immediately. For years, nSequence sat in every transaction as dead weight, almost always set to 0xFFFFFFFF (the maximum value), which everyone treated as a conventional signal meaning "final, no replacement."
BIP 68, activated in 2016, repurposed those bits. When nLocktime is non-zero and an input's nSequence is not 0xFFFFFFFF, the sequence number now encodes a relative timelock: a delay measured from the moment the output being spent was confirmed on-chain.
The encoding works as follows. Bit 31 of nSequence is a disable flag; if set to 1, the relative timelock is ignored entirely for that input. If bit 31 is 0, the timelock is active. Bit 22 then controls the unit: 0 means the value is in blocks, 1 means it's in 512-second intervals. The remaining low-order bits (0 through 15) hold the actual count.
So an nSequence value encoding a relative timelock of 10 blocks means this input cannot be spent until 10 blocks have been mined on top of the block that confirmed the output being spent. The clock starts at confirmation, not at signing.
A Worked Scenario: The Two-Party Payment Channel
Alice and Bob open a payment channel. They fund it together with a 2-of-2 multisig output confirmed in block 840,000. As part of the channel setup, they pre-sign a refund transaction that Alice can broadcast if Bob disappears. That refund transaction has nSequence on its input set to encode a relative timelock of 144 blocks, roughly one day.
Alice cannot broadcast that refund immediately. The network will reject it until block 840,144 is mined, because the rule is enforced at the consensus layer by BIP 68. She doesn't need to know the future block height at channel open. The 144-block delay is always measured from block 840,000, wherever that falls in real time.
Now add the absolute locktime layer. Suppose that same refund transaction also carries nLocktime set to block 840,050. The transaction must satisfy both constraints: it cannot be broadcast before block 840,050 (absolute), and the input's UTXO must be at least 144 blocks old (relative). In this particular case the relative constraint binds harder. In other channel designs the absolute constraint might bite first. Protocol designers have to think through which constraint dominates under which conditions, and the answer is not always obvious from a quick reading of the fields.
BIP 112 completed the picture by introducing the `CHECKSEQUENCEVERIFY` opcode (CSV), which lets a Script itself enforce relative timelocks rather than relying only on the transaction-level field. Lightning Network's HTLC scripts use CSV extensively, which is why I'd argue CSV is the more consequential of the two BIPs in practice, even though BIP 68 did the foundational work. A payment that hasn't been claimed with the correct preimage can be reclaimed by the sender after a CSV-enforced delay, with no trusted third party adjudicating the timeout.
The Interaction That Confuses Even Protocol Developers
nLocktime is only enforced when at least one input has nSequence less than 0xFFFFFFFE. That rule comes from the original code. If every input has nSequence at the maximum value, the node treats the transaction as final and ignores nLocktime entirely.
The two systems are not independent. nSequence being non-maximal is a prerequisite for nLocktime to do anything at all. BIP 68's relative timelock builds on top of that: it activates when nSequence is non-maximal, bit 31 is clear, and nLocktime is non-zero. Stack those conditions incorrectly and your timelock silently fails to enforce. No error. No warning. The transaction just confirms.
Consider this scenario: a developer building a custody product sets nLocktime correctly on a test transaction but leaves nSequence at 0xFFFFFFFF on every input, assuming the sequence field is cosmetic. The transaction confirms immediately. The timelock does nothing. If that's caught in a testnet environment, fine. If it isn't, the consequences in a live custody product range from embarrassing to catastrophic, and the code will not tell you what went wrong.
This is a design that punishes inattention more than it should. The interaction between these two fields is under-documented in most signing libraries, and the failure mode is silent. If you're constructing transactions by hand or with a low-level library, verify both fields explicitly. Do not assume the library has opinionated defaults that protect you, because several well-regarded ones do not.
Why This Architecture Matters
Relative timelocks are the mechanical foundation of second-layer protocols. Without them, Lightning Network's safety guarantees unravel. The ability to encode "this output can be claimed by the counterparty only after 144 blocks of inactivity" is what allows participants to enforce channel state on-chain without constant monitoring, no oracle, no custodian, no modification to base consensus rules beyond what BIP 68 and BIP 112 already introduced.
Absolute and relative timelocks solve genuinely different problems. Think of absolute locks as a calendar appointment pinned to a wall: fixed, immovable, indifferent to what else is happening. Relative locks are more like a fuse, cut at the moment a prior transaction confirms, burning for exactly as many blocks as specified before the next step becomes possible. Together they let Bitcoin Script model time-conditional contracts in a way that chains causality across transactions rather than simply delaying a single one.
What's worth sitting with is that none of this was designed top-down. nSequence was vestigial. nLocktime predated any real use case for it. BIP 68 and BIP 112 arrived years later, threading new semantics through fields that had been mostly ignored. The seams between those layers are real, and they have consequences. Understanding them is what separates someone who can read a transaction from someone who can actually reason about what it enforces, and in a system where the enforcement is the whole point, that distinction is not academic.