Bitcoin Timelocks (CLTV, CSV, and nLockTime)

A standard Bitcoin transaction settles in approximately 10 minutes. However, Bitcoin contains an extremely rich scripting system that allows users to write smart contracts. One of the most powerful features of these smart contracts is the ability to lock coins in Time.

A Timelock is a protocol-level rule that restricts bitcoins from being spent until a specific block height is reached or a specific date has passed.

️ The Two Axes of Timelocks

To understand Bitcoin’s timelock system, you must look at how they are categorized across two distinct axes:

 ┌───────────────────────┬────────────────────────┐
 │ TRANSACTION-LEVEL │ SCRIPT-LEVEL │
 │ (Locks entire Tx) │ (Locks specific UTXO) │
┌──────────────┼───────────────────────┼────────────────────────┤
│ ABSOLUTE │ nLockTime │ CLTV │
│ (Specific) │ (Header Parameter) │ (BIP 65 Opcode) │
├──────────────┼───────────────────────┼────────────────────────┤
│ RELATIVE │ nSequence │ CSV │
│ (Elapsed) │ (Input Parameter) │ (BIP 112 Opcode) │
└──────────────┴───────────────────────┴────────────────────────┘

Absolute Timelocks: Specific Points in Time

Absolute timelocks dictate that coins cannot be spent until a specific point in history is reached.

1. nLockTime (Transaction-Level)

This is the oldest timelock parameter, embedded directly into the transaction header.

• The Rule: A miner cannot include this transaction in a block until the blockchain has progressed past the specified block height or date.

• How it is written:

• If nLockTime < 500000000, it is interpreted as a Block Height.
• If nLockTime >= 500000000, it is interpreted as a UNIX Timestamp (seconds since 1970).

2. CheckLockTimeVerify (CLTV) (Script-Level — BIP 65)

Activated in 2015, CLTV allows developers to embed absolute timelocks directly into the scriptPubKey (locking script) of a UTXO.

• The script: <Target Block Height> OP_CHECKLOCKTIMEVERIFY OP_DROP

• How it works: Unlike nLockTime (which makes the transaction invalid for miners), CLTV locks the output itself. If a user wants to spend this UTXO, they must write a transaction with an nLockTime parameter equal to or greater than the target block height. This is the cornerstone of trustless inheritance contracts and time-locked escrows.

⏳ Relative Timelocks: Elapsed Time Since Confirmation

Relative timelocks state that coins cannot be spent until a certain amount of time has elapsed after the previous parent output was mined.

1. nSequence (Transaction-Level — BIP 68)

In 2016, the 4-byte nSequence field inside transaction inputs was repurposed to act as a relative transaction-level lock.

• The Rule: The input cannot be spent until the parent transaction (the UTXO it is consuming) has been buried under a specific number of blocks or time intervals.

2. CheckSequenceVerify (CSV) (Script-Level — BIP 112)

Activated alongside nSequence, CSV allows relative timelocks to be written inside custom scripts.

• The script: <Relative Blocks Delay> OP_CHECKSEQUENCEVERIFY OP_DROP

• How it works: CSV requires that the spending transaction's input sequence number is set to a relative delay equal to or greater than the specified delay block count.

⚡ Why Timelocks Are Crucial for Layer-2 Networks

Timelocks are not just simple gimmicks; they are the architectural scaffolding that makes the Lightning Network possible.

In the Lightning Network, users update payment channels off-chain. If your channel partner goes offline, or attempts to cheat by broadcasting an outdated channel balance, you need time to respond and challenge the transaction.

By using CheckSequenceVerify (CSV), the channel script ensures that if a partner broadcasts a state unilaterally, their coins are locked for, say, 144 blocks (24 hours). This relative delay gives your node a 24-hour window to detect the breach, broadcast a penalty transaction, and safely claim all channel funds before their lock expires!