How Time-Locking Bitcoin works: How CLTV & CSV Secure Future Transactions

Written By Stephen Whitelaw

Time-locked bitcoin

Advanced Bitcoin Security, Password Recovery & Crypto Forensics

Bitcoin isn’t only a store of value, it’s also programmable money. One of the most powerful and misunderstood features in the Bitcoin protocol is the ability to time-lock coins so they cannot be spent until a specific moment in the future.

Time-locks are essential in:

  • Inheritance & digital estate planning

  • Delayed-recovery security setups

  • Long-term cold-storage strategies

  • Lightning Network channel mechanics

  • Atomic swaps & escrow

  • Vault constructions

  • Anti-theft protections

  • Cryptocurrency recovery workflows (particularly when recovering partially spendable but not-yet-mature UTXOs)

In this blog post, we break down the technology behind time-locking, how it works at the Script level, and how you can safely use it.

1. Types of Bitcoin Time-Locks

Bitcoin supports four levels of time-locking:

1. Absolute Time-Locks (Block Height or Timestamp)

Implemented using CheckLockTimeVerify (CLTV)

 Funds are spendable after a specific block number OR timestamp

 

2. Relative Time-Locks (UTXO Maturity)

Implemented using CheckSequenceVerify (CSV)

Funds are spendable after the output has aged N blocks

 

3. nLockTime (Transaction-Level)

 

A transaction becomes valid only after a certain block/time.

 

4. nSequence (Relative Locktime Within Transaction Inputs)

 

Part of the BIP-68 relative locktime rules.

Here is the breakdown:

Mechanism Type Applies ToPurpose

CLTV (BIP-65) : Enforce “not spendable until block X or time T”

CSV (BIP-112) : Enforce age-based maturity

nLockTime : Prevent TX broadcast until time X

nSequence : Enable/disable CSV and replace-by-fee

2. Time-Locking with CLTV (Absolute Lock)

CheckLockTimeVerify allows you to create a UTXO that literally cannot be spent until the future.

2.1. Example: Lock BTC until block 900000

OP_NOP2 # historical alias for CLTV

Bitcoin Script Example

# Lock funds until block 900000, then require a signature

900000 OP_CHECKLOCKTIMEVERIFY OP_DROP

OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

This means:

  • Nobody can spend the coins before block 900000

  • After block height passes, normal P2PKH spending applies

Raw ScriptPubKey Example

0483a0 OP_CHECKLOCKTIMEVERIFY OP_DROP

76a914{20-byte-hash}88ac

 

3. Time-Locking with CSV (Relative Lock)

Relative time-locks are essential for Lightning channels, vault designs, and security workflows.

CSV forces a UTXO to age for N blocks after it appears on-chain.

Example: Lock for 30 days

30 days ≈ 30 × 144 = 4320 blocks

4320 OP_CHECKSEQUENCEVERIFY OP_DROP

<PubKey> OP_CHECKSIG

This means:

  • The UTXO becomes spendable after 4320 blocks have passed since its confirmation.

4. Using nLockTime (transaction-level locking)

You can also create a transaction that cannot be mined until a specific time:

nLockTime = 900000

Or using a Unix timestamp:

nLockTime = 1735689600  # Jan 1, 2025 UTC

Sample Partially Signed Bitcoin Transaction (PSBT)

{

  "nLockTime": 900000,

  "vin": [...],

  "vout": [...]

}

This is widely used in inheritance protocols, future-broadcast spending, and chain-analysis-resistant workflows.

5. Real-World Use Cases

1. Inheritance & Estate Planning

You allow BTC to be unlocked automatically after a specific date.

2. Multi-Signature with Delayed Spend

Combine CLTV + multisig:

  • If 2-of-3 keys sign, spend anytime

  • If keys are lost, after 3 years a backup key becomes valid

3. Theft Protection

If coins are stolen, but placed behind a CSV lock, the legitimate owner has time to react.

4. Vault Designs

Industry-grade crypto vaults combine:

  • Hot wallet key

  • Cold wallet key

  • CSV/CLTV “recovery time windows”

This prevents hackers from making instant withdrawals.

5. Forensic Recovery

When recovering wallets at BringBackMyCrypto.com, we often encounter:

  • nLockTime transactions waiting to mature

  • Partially time-locked UTXOs

  • Vault-based scripts requiring reconstruction

Understanding the structure is essential to determine when, who, and how funds can be moved.

6. Code Example: Creating a CLTV Time-Locked Address Using Bitcoin Core

Step 1 — Construct redeem script

redeemScript="6304823a0b75a914$(echo -n $PUBKEYHASH)88ac"

Or more formally:

redeemScript=$(bitcoin-cli -named createmultisig \

  nrequired=1 \

  keys='["'"$PUBKEY"'"]' \

  address_type=p2sh-segwit)

Step 2 — Create P2SH Address

address=$(bitcoin-cli createmultisig 1 "[\"$PUBKEY\"]" | jq -r '.address')

Step 3 — Fund the Address

Send BTC to the P2SH address.

Step 4 — Spend After Locktime

bitcoin-cli lockunspent false \

'[{"txid": "...", "vout": 0}]'

Then include:

"locktime": 900000

in your transaction.

7. Code Example: Time-Locked Script Using Bitcoin Script Simulator (Rust)

A Rust example for developers using the rust-bitcoin library:

use bitcoin::blockdata::script::Builder;

use bitcoin::blockdata::opcodes;

 

let lock_block = 900000;

 

let script = Builder::new()

    .push_int(lock_block)

    .push_opcode(opcodes::all::OP_CHECKLOCKTIMEVERIFY)

    .push_opcode(opcodes::all::OP_DROP)

    .push_key(&public_key)

    .push_opcode(opcodes::all::OP_CHECKSIG)

    .into_script();

8. Risks & Warnings

Time-locks are powerful but dangerous if misunderstood.

Risk 1: Permanent loss of funds

If your redeem script or backup keys are lost, no one can bypass Bitcoin’s rules.

Risk 2: Wrong lock value

  • Misconfigured timestamp

  • Block height < 500,000 being interpreted as timestamp instead of block count

  • Using nLockTime incorrectly

Risk 3: Inheritance failure

If heirs cannot access the Script + keys, the funds may remain locked indefinitely.

Risk 4: Transaction malleability (old wallets)

Before SegWit activation, time-locked transactions were vulnerable to malleability. Most modern setups avoid this.

Risk 5: Hardware wallet limitations

Not all hardware wallets fully support CLTV/CSV scripts natively.

9. Best Practices for Time-Locking Your Bitcoin

1. Always test on Bitcoin Testnet first

Before locking real BTC for years.

2. Store redeem scripts in multiple physical locations

3. Never rely on a time-lock for your only backup mechanism

4. Consider adding a “failsafe key”

Use a dual-path vault:

Path A (normal spend): 2-of-3 keys

Path B (timelock): 1 key + CLTV(after 2 years)

5. Use deterministic wallets (BIP-32/39/84)

Mitigates risk of Script loss.

10. Conclusion

Bitcoin time-locks are one of the most underrated tools for:

  • Security

  • Inheritance

  • Vault construction

  • Multi-stage transaction planning

  • Forensic recovery workflows

Used correctly, they offer superior protection vs traditional cold storage.

Used incorrectly, they can lock coins forever.

At BringBackMyCrypto.com, we regularly assist clients in:

  • Recovering time-locked UTXOs

  • Reconstructing incomplete scripts

  • Interpreting CLTV/CSV logic

  • Fixing broken vault implementations

  • Timing optimal spend windows

If you have Bitcoin locked behind a CLTV, CSV, nLockTime, or vault script and you’re unsure how to unlock it we can analyse the wallet and help you recover the funds.

WARNING : The code above is for educational puposes only - please check all your code thoroughly and run everything on the Bitcoin Testnet first.


Stephen Whitelaw
Previous

The Great Bitcoin Treasure Hunt: Who Actually Owns It?
Next

How to Back Up Your Bitcoin Wallet.dat File and Private Keys Safely