Can Bitcoin Timelocks Really Lock Coins? Setup and Unlock Verification

Crypto Basics

18 October 2026

Bitcoin timelocks do indeed "lock" coins, but what they lock is the spending condition, not a physical freeze. A UTXO constrained by a timelock still exists on-chain and still belongs to your address, but before the time condition is met, any transaction trying to spend it will be rejected by the network. Once the time arrives, the unlock happens automatically—there is no need to "apply" or "contact customer service." What you really need to design in advance is who can spend the money under what conditions, and whether there is a backup path if something goes wrong.

OKX Exchange
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！

Two Types of Timelocks, Completely Different Purposes

Bitcoin timelocks are divided into absolute timelocks and relative timelocks, corresponding to CLTV and CSV at the script level.

Absolute timelock (CLTV) means "this money cannot be spent before a specific point in time or block height." It locks an absolute position measured from the genesis block. For example, if you set 500000000, it represents a time around November 15, 2025; if you set 850000, it means the money cannot be spent until block height 850000 has been mined.

Relative timelock (CSV) means "after this money enters the blockchain, it must wait for a period of time before it can be spent." It locks a relative duration measured from when the transaction is confirmed. The CSV parameter is 16 bits, up to about 65535 blocks or 65535 seconds, making it more suitable for payment channels and on-chain contract refund scenarios.

For the goal of "locking coins," what you most likely need is CLTV. It allows you to lock coins until a future date, and before that date arrives, even you yourself cannot spend them.

What a Timelock Script Looks Like

The simplest CLTV locking script structure looks like this:

OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG

Its logic is: first check whether the current time has already passed . If not, the script fails immediately and the transaction is invalid. If it has, continue checking whether the signature corresponding to is valid. If the signature is valid, the coins can be spent.

More complex scenarios use conditional branches. For example, the classic escrow case in BIP 65: Alice and Bob run a joint business, and the funds are held in a 2-of-2 multisig. They worry that "if one party has an accident," the coins will become unspendable, so they set it up like this: within 3 months, both parties must sign together to spend; after 3 months, a signature from lawyer Lenny plus either Alice or Bob can spend. This preserves control during normal times while also providing an exit for unexpected situations.

Use Ready-Made Tools to Create a Timelock Wallet

You don't need to write scripts yourself. Several open-source tools can be used directly.

BTCapsule is an open-source program specifically designed for "Bitcoin time capsules." Its design idea is: you generate a P2SH address, set a future date, and send coins into it. The program generates two files: sender_wallet.txt is the sender's redemption script, which you (the original holder) can use at any time to take the coins back; receiver_wallet.txt is the receiver's script, which can only be spent after the date you set. You copy the receiver file to a USB drive and give it to your family. Even if they have the file, they cannot spend it before the date arrives. After the date arrives, they broadcast the redemption script in a blockchain explorer and then use the Sweep Wallet function to sweep the coins to their own address.

Liana is another option. It natively supports a timelock recovery path. In the GUI, under Settings → Recovery, you can find the "Recover funds" button. Enter the destination address and fee rate, sign, and broadcast. Liana's design leans more toward a combination of "primary path + timelock recovery path," suitable for people who want to use the primary path daily and fall back on the timelock path if the primary path fails.

Unlock Verification: Time Has Arrived, but the Transaction May Still Fail

Meeting the time condition does not guarantee that the transaction will be successfully broadcast. A few common sticking points:

nLockTime and nSequence must be set correctly. Although CLTV is written in the script, it relies on the spending transaction's nLockTime field for the final comparison. A transaction trying to spend a CLTV-locked UTXO must have an nLockTime greater than or equal to the time/height written in the script, and nSequence must not be 0xffffffff. If your wallet software automatically sets these fields to default values (for example, nLockTime=0), the transaction will be rejected by the network.

The 500,000,000 dividing line for time interpretation. Numbers smaller than 500,000,000 are interpreted as block heights, while numbers greater than or equal to that are interpreted as UNIX timestamps. If you write 1000000 thinking it represents a date, it actually means "spendable after block height reaches 1 million"—and Bitcoin has long passed that height, so the coins may be spendable immediately. Conversely, if you use 500000000 intending to express a height, it will be treated as a timestamp corresponding to 1985, and the coins will likewise be spendable immediately. Before writing a script, confirm that the number you use falls in the correct range.

Time arriving does not mean the block arrives immediately. The timestamp in CLTV is "block time," and miners are allowed up to two hours of variance when packing blocks. If you set a timestamp precise to the second, the actual unlock may happen several hours earlier or later than expected. Block heights have less ambiguity, but block production speed itself fluctuates. The average is 10 minutes per block, but in practice it can be faster or slower.

An Easily Overlooked Risk

A timelock protects the "spending path," not the private key. If your receiver file is leaked and the timelock happens to have expired, anyone who obtains the private key can sweep the coins away directly. BTCapsule's receiver file contains the receiver's private key, so this file needs to be treated like a private key—do not give it to people who should not have it ahead of time, and do not store it long-term on internet-connected devices.

Once a timelock script is on-chain, it is irreversible. You sent coins into a P2SH timelock address, and this UTXO's spending conditions are fixed by the script. If you later discover that the time was set incorrectly or the conditions have a flaw, there is no way to modify the script. The only remedy is to use the sender path (if one exists) to withdraw the coins before the timelock expires and lock them again. If the script is designed so that "nobody can spend before expiry," then you can only wait.

Completion Criteria

The point at which a timelock transaction is considered "setup complete" is when the locking transaction is confirmed and you can see the output corresponding to that P2SH address in a blockchain explorer. The point at which it is considered "unlock complete" is when, after the time condition is satisfied, a valid spending transaction is confirmed and the coins arrive at the target address.

If any step in between—script construction, broadcast, confirmation, unlock—goes wrong, the coins may become temporarily or permanently unspendable. Before locking large amounts of funds, first run through the entire process with a small amount (for example, a few thousand satoshis) on testnet or mainnet: setup, wait, unlock, sweep. This is the only way to verify that your script and toolchain are reliable.

OKX Exchange
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！