OP_CHECKLOCKTIMEVERIFY explained

OP_CHECKLOCKTIMEVERIFY - CLTV, opcode 0xb1 - is the instruction that makes a Bitcoin output unspendable until a chosen moment. It arrived in BIP 65, activated in December 2015, and it is what every timelock product is ultimately built on, ours included.

The script

The standard form is four elements:

<locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkey> OP_CHECKSIG

Read it as two conditions joined: the time has passed and you hold the key.

When a spend is attempted, the interpreter pushes <locktime> onto the stack and CLTV compares it against the spending transaction's nLockTime field. If the transaction's nLockTime is less than the value in the script, the script fails immediately and the transaction is invalid - not rejected by policy, not delayed, but invalid in the same way a bad signature is invalid.

OP_DROP then clears the locktime value off the stack, and the rest is an ordinary pay-to- pubkey check.

Why an early spend is genuinely impossible

Three rules interlock, and the third is the one people miss:

1. CLTV requires the spending transaction's nLockTime to be at least the script's value.
2. nLockTime is only enforced if at least one input has a sequence number below 0xFFFFFFFF - so the spend must also set that. CLTV checks this too and fails otherwise.
3. Consensus rejects any block containing a transaction whose nLockTime is in the future.

So to spend early you would have to set nLockTime to a future value, and no miner can include such a transaction in a valid block. Every node independently rejects it. There is no operator, no key, and no compromise that changes this - the coins are not being withheld from you, the spend simply is not a valid Bitcoin transaction yet.

Block height or timestamp

The locktime value means one of two things depending on its size:

• Below 500,000,000 - a block height. Spendable once the chain reaches that block.
• 500,000,000 or above - a Unix timestamp. Spendable once the median time past exceeds it.

Both have a wrinkle. Block height drifts: blocks average ten minutes but the interval is random, so a height chosen for "roughly five years" can land months either side. Timestamps use median time past - the median of the previous eleven block timestamps - which lags real wall-clock time by about an hour. Miners cannot freely manipulate it, but it is not a precise clock.

For anything measured in years, use a timestamp and accept an hour of slack. For short locks where an exact block matters, use height.

Building one yourself

Entirely doable, and the honest alternative to paying anyone:

1. Generate a keypair you will still control at the unlock date. This is the hard part and it is not a technical problem - see the cold storage guide.
2. Construct the script above with your locktime and pubkey.
3. Wrap it in P2WSH (or P2SH-P2WSH for older wallet compatibility) and derive the address.
4. Save the full redeem script, not just the address. You cannot spend without it, and you cannot reconstruct it from the address. Store it with your seed backup.
5. Send a small test amount. Verify the spend fails before the time and succeeds after - use signet or testnet with a short lock to rehearse the whole cycle end to end.
6. Then fund it.

Bitcoin Core can do all of this. Miniscript support in modern wallets makes it considerably less painful than it was.

The footguns, in the order they bite. Losing the redeem script. Losing the key over the intervening years. Setting a block height that arrives much later than intended. Testing on mainnet with real money. Discovering at the unlock date that the wallet software you used no longer exists. Every one of these is unrecoverable and none of them announce themselves until the end.

What we do differently

VaultUntil generates exactly this script per transfer:

<unlock time> OP_CHECKLOCKTIMEVERIFY OP_DROP <our key> OP_CHECKSIG

The only difference from a self-built lock is whose pubkey is in it. Before the unlock time the guarantee is identical and absolute - the coins cannot be moved by us, by you, or by anyone who steals our keys, because the network will not accept the transaction.

After the unlock time that key is ours alone, and we sign the payout to the recipient you fixed at the start. Consensus has stopped protecting you by then; delivery is us keeping our word. That is the whole trade: you skip the key management, and you take on us as a counterparty for the length of the lock. The risk page says so, and the comparison guide argues the case for doing it yourself.

If you can hold a key for the full term and construct the script correctly, do that instead. It is strictly better and it costs nothing.