Timelock
Also: CLTV, CSV, nLockTime, OP_CHECKLOCKTIMEVERIFY, OP_CHECKSEQUENCEVERIFY
cryptography · advanced
A script condition that forbids spending until a specific block height or timestamp. Comes in absolute (CLTV) and relative (CSV) flavors.
A timelock prevents a UTXO from being spent until a future moment. Bitcoin offers four mechanisms, two transaction-level and two script-level:
- nLockTime (transaction-level, BIP-65): the whole transaction is invalid until the specified block height or Unix timestamp.
- nSequence (input-level, BIP-68): an input can require that *N blocks* have passed since the UTXO it spends was confirmed.
- OP_CHECKLOCKTIMEVERIFY (CLTV) (script-level, BIP-65): commits an output to refusing to be spent before a specific *absolute* height/time. Pushed value is compared against the transaction's nLockTime.
- OP_CHECKSEQUENCEVERIFY (CSV) (script-level, BIP-112): commits an output to a *relative* delay measured from when the output was confirmed. Pushed value is compared against the spending input's nSequence.
Why both absolute and relative? Absolute timelocks pin escrow to a calendar date. Relative timelocks pin escrow to "X blocks after this output landed," which is what [Lightning](/glossary/lightning) channels need: a unilateral close starts a countdown, after which the other party can no longer dispute it.
Timelocks compose with [hashlocks](/glossary/hashlock) to make [HTLCs](/glossary/htlc): "claim this if you reveal preimage X, OR claim it back after N blocks." That OR is the safety hatch that keeps Lightning routing from stranding funds when a hop disappears.