1. A timelock restricts validity, not a calendar appointment

Bitcoin can require a transaction or spending path to wait until a threshold is satisfied. The threshold may relate to block height or a defined measure of time. These conditions are evaluated by network rules; they are not a reminder service or an instruction to a wallet to send money automatically. Someone still needs to construct and broadcast an appropriate transaction.

The important distinction is between when a transaction becomes eligible and when it actually confirms. Eligibility does not reserve space in a block. Fees, connectivity, available signatures and competing spends can still affect the outcome. Never describe a timed output as guaranteed to pay at an exact minute.

2. Absolute locks refer to a shared threshold

An absolute lock refers to a chain-wide threshold rather than the age of one particular output. Transaction locktime and the CHECKLOCKTIMEVERIFY script operation have related but different roles: a transaction carries a locktime field, while a script can require a compatible condition before a spending path succeeds. Inputs also have sequence fields whose values matter to these rules.

Height-based and time-based values are not interchangeable. A number entered with the wrong interpretation can produce a very different waiting condition. Read the construction used by your wallet or contract tool instead of copying a value from an unrelated example. Check both the script requirement and the final transaction fields.

3. Relative locks measure age from an earlier confirmation

A relative lock starts from an input's position in the chain. BIP 68 defines sequence-based relative locktime semantics for applicable transactions, and BIP 112 adds CHECKSEQUENCEVERIFY for script enforcement. A recovery path might become available after an output has aged by a specified number of blocks. The wait does not begin when someone drafts an unsigned transaction on a laptop.

If the funding transaction has not confirmed, the expected recovery schedule is still uncertain. A reorganization can also affect confirmation position. Distinguish a block-count delay from a time-based relative delay, whose units and interpretation follow the protocol specification rather than an application's display preference.

4. Time measurements are deliberately approximate

Bitcoin does not give each node authority to use its own wall clock for every spending condition. BIP 113 uses median time past for time-based locktime evaluation. This derives a reference from earlier blocks and reduces dependence on a single miner's timestamp. It also means the reference can lag the time displayed on your phone.

Block-height delays are uncertain in calendar terms because blocks arrive irregularly. Ten minutes is a long-run target, not a timer for the next block. Build operational margin into recovery plans and avoid legal or commercial promises that assume an exact chain-to-calendar conversion.

5. Test every spending path before committing funds

A timed setup may have an immediate cooperative path and a delayed recovery path. Inspect who holds the keys for each, which signatures are required, and whether the recovery transaction can still pay fees when it is eventually used. A correct delay with a missing signing key does not provide recovery.

Use a supported test environment and the official tool documentation. Save the script or descriptor, key-origin information and recovery procedure in the appropriate backup plan. Do not put private keys into an online decoder merely to inspect a timelock. The ability to display a script is different from proving that you can satisfy it.

Worked example: a delayed recovery route

Consider a hypothetical output that allows two people to spend together immediately, while one designated recovery key can spend after a relative delay of 144 blocks. The recovery wait starts from the output's confirmation, not from the day the parties sign their agreement. A network slowdown can make the calendar wait longer than an estimate.

Before funding, the parties should test both branches with disposable keys. They should also establish how the recovery holder obtains current transaction data and chooses a fee. This example explains timing semantics only; it is not a complete, reviewed custody design.

FAQ

Can I undo a payment by adding a timelock afterward?

No. A timelock must be part of the relevant transaction or spending conditions. It cannot retroactively modify an already confirmed output. If a tool promises to freeze arbitrary Bitcoin after payment, ask for the actual script and protocol mechanism rather than trusting the interface label.