Bitcoin transactions have a sequence number field for each input. The original idea was to allow transactions in the mempool to be replaced by using the same input with a higher sequence value. However, this idea was not fully implemented. BIP-68 repurposes the sequence number field to enable new use cases, such as bi-directional payment channels (used in Hashed Timelock Contracts - HTLCs) without breaking existing functionality.

BIP-68 defines the meaning of sequence numbers for transactions with a version greater than or equal to 2. If bit 31 (1 << 31) of the sequence number is set, no consensus meaning is applied to the sequence number, and it can be included in any block under all currently possible circumstances. If bit 31 (1 << 31) of the sequence number is not set, the sequence number is interpreted as an encoded relative lock-time. Bit 22 (1 << 22) determines whether the relative lock-time is time-based or block-based. If bit 22 is set, the relative lock-time specifies a timespan in units of 512 seconds granularity, starting from the median-time-past of the output’s previous block and ending at the MTP of the previous block. If bit 22 is not set, the relative lock-time specifies a number of blocks.

The 512-second granularity for time-based relative lock-time was chosen because bitcoin blocks are generated approximately every 600 seconds. Converting from a sequence number to seconds is performed by multiplying by 512 (2^9) or equivalently shifting up by 9 bits.

When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input that can be included in any block. More generally, a relative time-based lock-time "n" can be included into any block produced 512 * "n" seconds after the mining date of the output it is spending, or any block thereafter. The mining date of the output is equal to the median-time-past of the previous block that mined it.

When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input that can be included in any block. More generally, a relative block lock-time "n" can be included "n" blocks after the mining date of the output it is spending, or any block thereafter.