Timelocks in the box model

Timelocked coins still need a key

Updated 6 October 2026

That is a calendar on the box. It is not a stronger lock.

What a timelock actually does

Bitcoin has two timelocks in common use. CheckLockTimeVerify, BIP-65, makes an output unspendable until a particular block height or Unix timestamp. CheckSequenceVerify, BIP-112, makes an output unspendable until a relative number of blocks or seconds have passed since the output was confirmed. Both are consensus rules. Both are checked by every full node. Both are, in the model this site uses, a sticker on the outside of the box that says do not open before this date.

What they do not do is rotate the key. They do not move the box to a new address. They do not wrap the public key in anything that the discrete logarithm problem would not already break. They are pure delays. If the box can be opened in 2040, the key inside it is the same key it was in 2026, and a sufficiently large quantum computer running Shor's algorithm in 2041 can derive the private key from the public key that was broadcast when the spend finally happened.

This matters because timelocks are popular. Inheritance plans use them. Custody vaults use them. The original BIP-65 proposal was written to let a tx be created, signed, and broadcast, but rejected by the network until a future block, which is the standard pattern for a last-resort recovery transaction that a relative inherits. None of these patterns close the box. They only schedule it.

Absolute versus relative, and why both leak

CLTV is absolute. A transaction spending the output must be valid at block height H or later, or the network rejects it. CSV is relative. A transaction is only valid once M blocks have been added to the chain on top of the output's own confirmation. Mechanically the two are different. From the point of view of the box they are the same sticker, with two ways of writing the date.

What changes between CLTV and CSV, in quantum terms, is only the schedule. A CLTV coin in a 20-year vault, broadcast on the planned date, will reveal the public key in 2046. A CSV coin, locked for 10,000 blocks after confirmation, reveals the public key roughly 70 days after whatever moment it was confirmed. The hash stays until spend in both cases. The moment of opening is the moment the key is exposed. A box with a 100-year timelock that is never opened leaks nothing. A box with a 100-year timelock that is opened, by its owner, in 2126, leaks everything it has in that one spend.

That is the whole quantum budget of a timelock. It is not the same as a normal box, because the owner has a calendar in the way, but it is the same as a normal box the moment the spend goes out. The relevant metric is not the timelock length, it is whether the box is still closed when the spend happens.

The inheritance case, honestly drawn

Consider the common pattern. Alice puts 1 BTC in a P2WSH output that is spendable either by a 2-of-2 multisig with her hardware wallet and a recovery co-signer, or by a CSV-locked backup path that only her heir Bob can use after, say, 12 months of inactivity. The CSV path requires Bob's hardware wallet to sign. The multisig path is normal.

If Alice disappears, the multisig is never used. The CSV path is what pays Bob. Bob's spend broadcasts Bob's public key. The coins leave the box. If a quantum computer exists at the moment of the spend, Bob's key is derivable from that broadcast, and the same run that breaks Bob's key can rewrite a competing transaction that double-spends the same UTXO before Bob's gets confirmed. That is the standard long-exposure case, applied to a multisig with a 12-month timelock.

The point is not that timelocks are bad. They are useful, sometimes essential. The point is that they sit on the outside of the box, and the box is what we have been thinking about on this site for months. Anything on the outside of the box can be peeled off without touching the lock.

What timelocks do not solve

Timelocks do not stop a quantum attacker from racing the legitimate spender. Once the timelock expires, the box can be opened. Any spend broadcasts a public key. Any public key broadcast can be targeted. The race is not against the timelock, it is against the spend's propagation through the mempool, and that race is exactly the long-versus-short exposure window discussed in earlier pieces on this site.

Timelocks do not rotate the key. There is no consensus rule in Bitcoin that swaps a public key for a new one. P2TRv2 and the post-quantum output types discussed elsewhere on the site are the only serious proposals that change the lock itself. CLTV and CSV are orthogonal. They can be combined with a P2TRv2 output, or a P2MR output, but combining them does not retroactively close a box that was opened by an earlier script.

Timelocks do not hide the box. The UTXO set is public. A box with a 1,000-block CSV sits in the UTXO set, in the clear, until it is spent. The timelock does not obscure the script, the amount, the address type, or the expected opening time. Long-running inheritance scripts in particular are easy to enumerate. A quantum attacker that wants a long-exposure target can grep the chain for CLTV outputs with expiry dates after the projected quantum horizon and precompute the public keys for any P2PKH-style spend path that has already been revealed.

The honest best practice for a quantum-plausible future

If you are writing a timelocked script today, and you care about a post-quantum adversary, the analysis is the same as for any other spend path. The lock is the lock. The timelock is the calendar. Move the coins to a still-closed address type before the spend, not at the moment of the spend. If the only way to spend a CSV-locked output is to broadcast a key, then plan the recovery so that the broadcast is the last possible step, with the coins already in a post-quantum output by the time the broadcast happens.

For users who cannot move the coins to a post-quantum output yet, because no consensus rule supports it, the practical advice is to assume that any timelocked spend is a long-exposure spend from the day the timelock expires. Set the calendar with that in mind. If the calendar has to outlive the quantum horizon, the plan needs a different lock, not a longer one.