Bitcoin Timelock Transactions: CLTV and CSV Explained

Bitcoin Timelock Transactions: Time-Locking Your Bitcoin

Bitcoin's scripting language includes powerful timelock mechanisms that prevent transactions from being spent until a specific time or block height. These features enable sophisticated use cases like vesting schedules, inheritance planning, payment channels, and more. This guide explains how Bitcoin timelocks work at a technical level.

Types of Timelocks

Bitcoin supports four distinct timelock mechanisms, each serving different purposes:

nLockTime (Transaction-Level)

The original timelock, present since Bitcoin's creation. It's a field in the transaction data that specifies the earliest time or block height at which the transaction can be included in a block. Before this time, nodes will not relay or mine the transaction.

• Value < 500,000,000: Interpreted as a block height.
• Value >= 500,000,000: Interpreted as a Unix timestamp.

nSequence (Input-Level)

A per-input field that can enforce relative timelocks — delays measured from the time the input UTXO was confirmed, rather than absolute timestamps. This enables constructions like "this UTXO can't be spent until 144 blocks (approximately 1 day) after it was confirmed."

OP_CHECKLOCKTIMEVERIFY (CLTV) — BIP 65

An opcode that makes absolute timelocks enforceable within scripts. CLTV checks that the transaction's nLockTime is greater than or equal to a specified value. If the check fails, the script fails, and the transaction is invalid.

CLTV enables script-level conditions like: "This Bitcoin cannot be spent by anyone until block 900,000" or "This Bitcoin cannot be spent until January 1, 2030."

OP_CHECKSEQUENCEVERIFY (CSV) — BIP 112

An opcode for relative timelocks within scripts. CSV checks that the input's nSequence value enforces a minimum delay since the UTXO was confirmed. This enables conditions like: "This Bitcoin cannot be spent until 1,000 blocks after it was received."

CLTV vs CSV Comparison

Feature	CLTV (Absolute)	CSV (Relative)
Reference Point	Specific block height or timestamp	Time since UTXO confirmation
BIP	BIP 65	BIP 112
Use Case	Fixed deadlines, vesting dates	Cooldown periods, payment channels
Example	"Unlock at block 900,000"	"Unlock 144 blocks after deposit"
Flexibility	Fixed, predetermined	Adapts to when funds are received

Practical Use Cases

1. Vesting Schedules

Companies can create Bitcoin vesting schedules for employees using CLTV. For example, send Bitcoin to an address with a script that requires the employee's signature AND a timelock that expires on their vesting date. The employee can see the Bitcoin in their wallet but cannot spend it until the specified block height.

2. Inheritance Dead Man's Switch

Create a transaction with a CLTV timelock that sends your Bitcoin to your heirs' addresses at a future date. Periodically (before the timelock expires), move the Bitcoin to a new address with a new, extended timelock. If you become unable to move the Bitcoin (due to death or incapacity), the timelock eventually expires, and your heirs can claim the funds without needing your private keys.

3. Savings Vault

Lock Bitcoin with a future CLTV timelock as a forced savings mechanism. The Bitcoin literally cannot be spent until the timelock expires, removing the temptation to sell during market volatility. Some call this "hodl by code."

4. Payment Channels (Lightning Network)

CSV timelocks are fundamental to the Lightning Network. When a Lightning channel is opened, CSV timelocks ensure that if one party tries to cheat by broadcasting an old channel state, the other party has a window of time (the CSV delay) to submit a penalty transaction. This is how Lightning maintains security without constant on-chain monitoring.

5. Escrow with Time Bounds

Create an escrow script: "Either both buyer and seller sign (immediate release) OR after 30 days, the buyer can reclaim funds with just their signature." This ensures escrow funds don't get permanently locked if the seller disappears.

Creating Timelock Transactions

You can create timelock transactions using several tools:

• Bitcoin Core: Using the createrawtransaction RPC with the locktime parameter.
• Electrum: Supports creating transactions with custom locktime values.
• Sparrow Wallet: Advanced transaction builder supports timelocks.
• Programming libraries: bitcoinjs-lib (JavaScript), python-bitcoinlib (Python), and rust-bitcoin (Rust) all support timelock construction.

Important Considerations

• Block time variability: Bitcoin blocks target 10 minutes but can vary significantly. Don't rely on exact timing for critical applications.
• Irreversibility: Once a CLTV-locked UTXO is created, the timelock cannot be shortened. Ensure the timelock period is appropriate before sending funds.
• Testing: Always test timelock scripts on Bitcoin's testnet or regtest before using real funds. See our guides on testnet and regtest.
• Key security: The timelock only prevents spending before the specified time. You still need the private keys to spend after the timelock expires.

For Sri Lankan Bitcoin Users

Timelocks offer Sri Lankan Bitcoin holders practical tools for self-discipline (forced hodling), inheritance planning (dead man's switches), and savings goals (locking funds until a target date). Visit our tools page for timelock-capable wallet recommendations and our learning center for script programming tutorials.

Disclaimer: This article is for educational purposes only. Timelock transactions are irreversible once broadcast — funds cannot be accessed before the timelock expires under any circumstances. Test thoroughly on testnet first. This is not financial advice.