Relative Timelock

A relative timelock prevents a coin from being spent until a defined amount of time has elapsed since the output it spends was confirmed. The deadline is measured relative to confirmation rather than to a fixed calendar point or block height. Relative locks are defined by BIP 68, which gave consensus meaning to a transaction input's previously idle nSequence field, and they can be enforced inside a script with OP_CHECKSEQUENCEVERIFY (CSV). Together, the two mechanisms let a contract say "this path opens N blocks after the coin lands" — a primitive that layer-2 protocols are built on.

How it is encoded

Each transaction input carries a 4-byte nSequence value. Under BIP 68, the low 16 bits hold the lock duration. Bit 22 selects the units — clear for blocks (1-block steps), set for time (512-second steps) — while bit 31 disables the relative-lock interpretation entirely when set, preserving compatibility with older uses of the field. The rules apply only to transactions of version 2 or higher. A transaction is valid only once every input has aged past its specified relative lock, with time-based locks measured against Median Time Past rather than raw block timestamps, so miners cannot cheat the clock. Note the division of labor: BIP 68 makes the transaction itself invalid until the age is reached, while CSV lets a locking script demand that a spender commit to such an age — belt and suspenders for contract designers.

Why it exists

Relative timelocks are the ingredient that makes off-chain protocols safe. In the Lightning Network, when a channel closes, the party who broadcast the closing state must wait out a CSV delay before sweeping their funds — a guaranteed reaction window in which the counterparty can publish a penalty transaction if the broadcast state was an old, revoked one. Because the timer starts at confirmation rather than at a calendar date, the same contract template works no matter when the channel was funded or how long it lived — a property no absolute deadline can provide. The same pattern secures HTLC timeout paths, vault-style covenants, and any construction where one party needs a head start measured from the moment coins hit the chain.

What it means in practice

Encoding in practice

The arithmetic is friendlier than the bitfield sounds. A block-based lock is just the number of blocks: an nSequence of 144 with the type and disable bits clear means the input cannot be spent until its parent output has 144 confirmations — about a day at ten-minute blocks. For time-based locks the 512-second granularity means one unit is roughly 8.5 minutes; a one-day lock is about 169 units, set alongside the type flag on bit 22. Wallets and libraries handle the encoding, but knowing the layout pays off when you are staring at a raw transaction wondering why it will not broadcast — a surprisingly common repair-bench moment for anyone experimenting with channel software or vault scripts. Note also the interaction with fee-bumping conventions: because nSequence carries multiple meanings (relative locks, replace-by-fee signaling, locktime enablement), tooling must set it deliberately rather than defaulting, and reading an input's nSequence is often the fastest way to learn what a transaction's author intended.

For a node runner or Lightning operator, relative timelocks are why "just stay online occasionally" is a real security model: your watchtower or your own node needs to observe the chain within the CSV window to punish cheating, and longer windows buy safety at the cost of slower unilateral exits. For anyone scripting raw transactions, the classic footgun is forgetting that nSequence defaults matter — set the disable bit unintentionally and your lock silently vanishes; leave version 1 and BIP 68 never applies. This contrasts with an absolute timelock, which fixes a specific height or time regardless of when the output confirmed; most sophisticated contracts use both, absolute deadlines for expiry and relative delays for reaction windows.