CLTV vs CSV (BIP 65 vs BIP 112)
OP_CHECKLOCKTIMEVERIFY (CLTV, BIP 65) locks coins until an absolute point, a specific block height or date, by checking the transaction's nLockTime; OP_CHECKSEQUENCEVERIFY (CSV, BIP 112) locks coins until a set number of blocks or amount of time has passed since the coin was confirmed, by checking the input's nSequence as defined in BIP 68. Many contracts, including Lightning channels, use both.
Updated · 3 min read
At a glance
| BIP 65 | BIP 112 | |
|---|---|---|
| Title | OP_CHECKLOCKTIMEVERIFY | CHECKSEQUENCEVERIFY |
| Status | Deployed | Deployed |
| Type | Specification | Specification |
| Assigned | 2014-10-01 | 2015-08-10 |
| Authors | Peter Todd | BtcDrak, Mark Friedenbach, Eric Lombrozo |
| In plain English | Adds OP_CHECKLOCKTIMEVERIFY, a script command that keeps coins unspendable until a chosen date or block height. It enables time-locked savings, escrow with deadlines, and payment channels such as those used by the Lightning Network. | Introduces CHECKSEQUENCEVERIFY, a script instruction that lets coins be locked until a certain amount of time has passed since they were received. This 'relative timelock' is a key building block for the Lightning Network and other payment channels. |
What CLTV (BIP 65) does
BIP 65, by Peter Todd, redefined OP_NOP2 (0xb1) as OP_CHECKLOCKTIMEVERIFY. The script fails if the top stack item is greater than the transaction's nLockTime, if the two use different lock types (block height or timestamp), or if the input's sequence is 0xffffffff, which would switch nLockTime off. Since a transaction with a future nLockTime can't be mined, an output guarded by CLTV can't be spent before that height or time. Values below 500,000,000 are block heights; values of 500,000,000 or more are Unix timestamps, which since BIP 113 are compared against the median time of the previous 11 blocks.
Before CLTV, nLockTime could prove a coin could be spent in the future but not that it couldn't be spent sooner, because a different signed transaction might exist. CLTV puts the rule in the script itself. It activated at block 388,381 in December 2015.
What CSV (BIP 112) does
BIP 112, by BtcDrak, Mark Friedenbach and Eric Lombrozo, redefined OP_NOP3 (0xb2) as OP_CHECKSEQUENCEVERIFY. It works together with BIP 68, which gives an input's nSequence field a consensus meaning in transactions of version 2 or higher: the input can't be mined until the coin it spends is a given number of blocks old, or a given multiple of 512 seconds old. CSV fails the script unless the input's sequence encodes a relative lock of the same type that is at least as long as the script requires. The lock uses 16 bits, so it reaches at most 65,535 blocks or 65,535 × 512 seconds (about 388 days).
The CSV soft fork (BIPs 68, 112 and 113) activated at block 419,328 in July 2016.
CLTV vs CSV compared
| CLTV (BIP 65) | CSV (BIP 112) | |
|---|---|---|
| Kind of timelock | Absolute: a block height or date | Relative: the age of the coin being spent |
| Opcode | OP_CHECKLOCKTIMEVERIFY, formerly OP_NOP2 (0xb1) |
OP_CHECKSEQUENCEVERIFY, formerly OP_NOP3 (0xb2) |
| Field it checks | Transaction nLockTime (one per transaction) |
Input nSequence (one per input), per BIP 68 |
| Units | Block height (below 500,000,000) or Unix time | Blocks, or units of 512 seconds |
| Maximum | Whatever the 32-bit nLockTime can express | 65,535 units (16 bits) |
| Clock starts | Fixed when the script is written | When the coin being spent confirms |
| Other requirement | Input sequence must not be 0xffffffff |
Transaction version 2 or higher |
| Activated | Block 388,381 (December 2015) | Block 419,328 (July 2016) |
Both opcodes work in legacy scripts, SegWit v0 scripts and tapscript, which BIP 342 bases on the P2WSH rules including CLTV and CSV.
How CLTV and CSV relate
They are complementary. CLTV says "not before this date"; CSV says "not until this long after the coin confirmed". BIP 112 explains why payment channels needed the second kind: with only CLTV, a channel has a fixed deadline and must be closed and reopened as it approaches, while with CSV "the clock starts ticking the moment the transactions confirms", so the other side always gets the same window to respond.
The two are often combined. BIP 112's HTLC examples use CSV for the revocation delay and CLTV for the payment timeout, and in one branch require both before Bob can spend.
Which should you use?
- Inheritance plans, vesting, or savings locked until a date: CLTV, because the unlock time is known in advance.
- Escrow or dispute windows that start when funds arrive: CSV. BIP 112's escrow example lets Alice reclaim funds alone 30 days after the payment to the escrow address confirms, while any two of Alice, Bob and the escrow agent can spend earlier.
- Lightning and similar protocols: both, as described above.
The opcode reference covers both opcodes, and the Lightning BIPs guide shows where timelocks fit into payment channels.
Frequently asked questions
What is the difference between an absolute and a relative timelock?
An absolute timelock (CLTV, BIP 65) unlocks at a fixed block height or date, no matter when the coins were received. A relative timelock (CSV, BIP 112 with BIP 68) unlocks after a set number of blocks or 512-second units have passed since the coin being spent was confirmed. Absolute locks suit deadlines; relative locks suit response windows.
Does the Lightning Network use CLTV or CSV?
Both. BIP 112 describes the pattern: outputs paying the party who broadcast a commitment transaction are delayed with CSV, so the other side has time to claim them if an old, revoked state was published, while HTLCs use CLTV for their absolute payment timeout. BIP 112's example scripts combine both opcodes.
What is the maximum CSV timelock?
BIP 68 uses 16 bits of the sequence number for the lock, so the maximum is 65,535 blocks or 65,535 units of 512 seconds, about 388 days. A flag bit chooses between blocks and time. CLTV has no such limit: it can lock until any height or timestamp the 32-bit nLockTime field can express.
What is the difference between nLockTime and OP_CHECKLOCKTIMEVERIFY?
nLockTime is a transaction field: that transaction can't be mined before the given height or time, but the same coins could still be spent sooner by a different transaction. OP_CHECKLOCKTIMEVERIFY puts the rule in the output's script, so every spending transaction must set an nLockTime at least that late. That makes the lock enforceable in advance, which is what BIP 65 was written to provide.
Can CLTV and CSV be used in the same script?
Yes. They check different fields (nLockTime and nSequence), so one script branch can require both an absolute and a relative delay. BIP 112's HTLC example for Bob's commitment transaction does exactly that, requiring a CLTV timeout and a CSV delay before Bob can spend.