BIP 65 (OP_CHECKLOCKTIMEVERIFY) — Plain-English Explainer

BIP-65 added the OP_CHECKLOCKTIMEVERIFY (CLTV) opcode to Bitcoin Script. Activated as a soft fork in December 2015, it gave script-level enforcement to absolute locktimes.

Before BIP-65, the only locktime mechanism was the transaction-level nLockTime field, which prevents a whole transaction from being mined before a given height or time. CLTV brought the same concept into the script itself: an output's locking script could now require that "the spending transaction's nLockTime is at least X."

This sounds like a small distinction. It's actually load-bearing for entire categories of Bitcoin applications:

• Payment channels and the Lightning Network use CLTV to enforce withdrawal delays after force-closing a channel.
• Atomic swaps use CLTV to enforce refund deadlines if a counterparty bails.
• HTLCs use CLTV as the time-based fallback in their "preimage or timeout" structure.
• Inheritance vaults use CLTV to ensure heirs can claim funds after a long delay if the original owner is inactive.

CLTV was paired with BIP-68/112 (CSV) for relative locktimes a year later. Together, the two opcodes turned Bitcoin Script into something powerful enough to support Lightning and most modern multi-party protocols.

For users, you'll rarely interact with CLTV directly. Your wallet or Lightning implementation handles it behind the scenes. But every Lightning channel you ever use relies on CLTV being there.