CHECKSEQUENCEVERIFY

CHECKSEQUENCEVERIFY, commonly abbreviated CSV, is an opcode in Bitcoin Script introduced by BIP-112. It implements a relative timelock by tying the ability to spend an output to the spending transaction’s input sequence number. In practice, a script path pushes a numeric value representing a required delay, then CSV checks that the delay has elapsed relative to when the output was created. After the check, the value is typically removed from the stack with OP_DROP. This enables time-locked or block-delayed conditions without requiring an absolute transaction locktime.

Mechanism and semantics: CSV compares the pushed relative delay against the nSequence field of the spending input. If the required delay has not passed, the script fails. The interpretation of the value depends on its top bits: the most significant bit indicates time-based versus block-based interpretation. If time-based, the delay is expressed in units with a granularity defined by the BIP-112 rules (commonly described as 512-second granularity). If block-based, the delay is the number of blocks. The lower bits carry the magnitude, subject to the type flag. In all cases, the input’s sequence must be non-final for CSV to apply.

Activation and usage: CSV is a soft-fork feature from BIP-112 and requires appropriate transaction versions and script patterns to be valid. It is widely used to implement relative delays in multisig and other scripts, and is a foundational tool in constructs such as payment channels. A typical pattern places CSV at the top of a script path followed by OP_DROP, then the rest of the spending logic (for example, a public-key check).

Limitations: CSV does not by itself assert global time; it enforces a relative delay. It interacts with other lock-time mechanisms and requires careful scripting to ensure correct spending paths.