Relative Timelocks (BIP 68)

While nLockTime sets a specific date or block height for a transaction, Relative Timelocks (defined in BIP 68) allow an input to be locked based on the age of the coins being spent.

1. How it Works

A relative timelock says: "This input cannot be spent until 1,000 blocks have passed since the previous transaction was confirmed."

• This is enforced by repurposing the bits within the Sequence field.

2. Bitwise Logic of nSequence

BIP 68 uses specific bits to define the lock:

• Bit 31 (Disable bit): If this bit is 1, relative timelocks are disabled (default). If it is 0, they are enabled.

• Bit 22 (Type bit):

  • 0: The lock is based on Block Count.
  • 1: The lock is based on Time (512-second increments).

• Bits 0-15 (Value): The actual number of blocks or time units to wait.

3. Comparison with nLockTime

Feature	nLockTime	nSequence (BIP 68)
Lock Type	Absolute (Date/Height)	Relative (Age of UTXO)
Scope	Entire Transaction	Per-Input
Enabled By	Sequence \u003c 0xffffffff	Sequence bit 31 = 0

4. Use Case: Lightning Network

Relative timelocks are the foundation of the Lightning Network's security.

• They allow a user to say: "I am publishing this channel state, but my partner has 24 hours (a relative lock) to dispute it if I am trying to cheat."

• Without relative timelocks, off-chain protocols would be significantly more complex and less secure.

5. Hex Example

• Sequence 0x0000000a:
  • Bit 31 is 0 (Enabled).
  • Bit 22 is 0 (Block based).
  • Value is 10.
  • Result: Input is locked for 10 blocks after the source UTXO is mined.

In the next section, we will discuss the 0xffffffff Sentinel and how it affects consensus.