Relative timelock

BIP-68 gave the four byte sequence field on each input a consensus meaning, but only for transactions declaring version 2 or higher. The rule reached the network through a BIP-9 versionbits deployment on bit 0 that opened on 1 May 2016 and shipped alongside BIP-112 and BIP-113. If you hold coins behind a recovery or channel script, the countdown restarts every time those coins move.

How it works

Relative timelocks are encoded in the sequence field, and the top bit decides whether anything happens at all.

With bit 31 set, the field carries no consensus meaning and the input may go into any block. With bit 31 clear, nodes mask the field with 0x0000ffff and read the surviving 16 bits as a waiting period. Bit 22 picks the unit. Cleared, the number counts blocks, and BIP-68 gives the range as 0 to 65,535 blocks, which it calls 1.25 years. Set, the number counts periods of 512 seconds, a range the BIP states as under 33,554,431 seconds, about 1.06 years. The odd 512 was chosen because blocks arrive roughly every 600 seconds, so both units cover a similar span in the same 16 bits.

An input carrying a block based value of n may be included n blocks after the block that mined the output it spends, so a value of 1 clears in the very next block rather than the one after. Time based values are never compared against a clock. BIP-68 measures from the median time past of the block before the one that mined the output, and against the median time past of the block before the one being built, and BIP-113 defines that figure as the median of the last 11 block timestamps. Medians are used rather than raw timestamps because consensus rules guarantee the median advances monotonically, which stops a miner collecting extra fees by lying about a block's time.

Two carve outs matter. The rules never apply to the sequence field of a coinbase transaction's input. And six positions, 16 through 21, were left undefined so a later soft fork can raise the granularity or the ceiling without a new field.

Where you see it

BIP-112 works a relative timelock through an escrow contract that times out 30 days after it is funded.

Alice, Bob and an escrow agent share a 2-of-3 script. Any two can spend at any moment; after the delay Alice signs alone. The BIP is blunt about the trigger: the clock does not start ticking until the payment to the escrow address confirms. That is the whole difference from a calendar deadline, and it is why one script serves every new escrow without a rewrite.

The rule also shapes how mempools behave. Bitcoin Core's sequence lock check runs against the height of the next block rather than the current tip, and treats an unconfirmed parent as though it will confirm in that block, so a spend whose wait expires with the coming block is relayed slightly before it is spendable. Outside that slack there is no queue: an immature spend is invalid, not pending.

Relative timelock vs OP_CHECKSEQUENCEVERIFY

A relative timelock lives on the transaction input, while OP_CHECKSEQUENCEVERIFY lives in the coin's script and checks that a spending input honors one.

BIP-68 on its own binds nobody. Whoever builds the spend picks the sequence value, so a delay written there is a preference, not a rule a counterparty can rely on. BIP-112 closes the gap by making the field readable from script: the opcode fails if the transaction version is below 2, if the input sequence has the disable flag set, if the two values disagree on their unit, or if the number on the stack exceeds the masked sequence. A stack value carrying the disable flag itself makes the opcode behave as a NOP, deliberate room for a future soft fork. Only with those checks in place does the wait become something an escrow agent or a Lightning peer can count on.