A Bitcoin spending condition can include a waiting period. Understanding that condition means asking when the wait begins, how Bitcoin measures it, and which spending route must obey it. Those questions matter whenever a wallet or protocol describes funds as timelocked.
Bitcoin records spendable value in transaction outputs. Each output has conditions that a later transaction must satisfy. A timelock can add a timing requirement alongside other requirements, such as signatures. Passing the timing test does not supply a missing signature or make an otherwise invalid transaction acceptable. Bitcoin transaction guide
Absolute locks use a fixed threshold
An absolute timelock refers to a particular block height or timestamp. Bitcoin's transaction field called nLockTime carries that threshold. With the lock enabled, a transaction must wait until the candidate block's height, or the applicable time measure, is strictly greater than the recorded value. For example, an illustrative height threshold of 1,000,000 first permits inclusion at height 1,000,001, assuming all other requirements are satisfied. Bitcoin Core transaction validation
Delaying one transaction does not establish that its inputs cannot be spent another way. Someone with the necessary authorization might construct a different transaction without that delay. BIP65 explicitly identifies this limitation of nLockTime and introduces CHECKLOCKTIMEVERIFY, usually called CLTV, to let an output's spending conditions require an absolute lock. BIP65 motivation
CLTV checks the spending transaction's lock value and requires a matching unit: a height condition must be matched by a height lock, and a timestamp condition by a timestamp lock. It also prevents the relevant input from using the setting that would bypass the transaction's absolute lock. BIP65 summary
Relative locks measure the age of an output
A relative timelock waits for an interval after the output being spent is confirmed. BIP68 gives selected input sequence values this meaning for transactions with version 2 or higher. Its rules distinguish block counts from time intervals; the time-based form uses increments of 512 seconds. A disable flag allows an input's sequence field to opt out of these relative-lock rules. BIP68 specification
Consider a hypothetical 144-block delay. If the relevant output confirms at height 1,000,000, that delay first permits its spend at height 1,000,144. If confirmation occurs later, the eligibility height moves with it. The example follows BIP68's height calculation; it does not promise a particular calendar duration. BIP68 block-based calculation
BIP112 adds CHECKSEQUENCEVERIFY, or CSV, so a spending path can require that relative delay. CSV checks that the transaction version, sequence settings and lock type are compatible with the required minimum age. Together, BIP68 and BIP112 connect a delay expressed in the transaction to a requirement enforced by the output's script. BIP112 summary
Bitcoin uses its own time measure
A timestamp-based lock is evaluated using blockchain information. BIP113 specifies median time past, or MTP: the median of the timestamps in the previous 11 blocks when evaluating a candidate block. The candidate block's own timestamp does not determine whether an absolute time lock has matured. This reduces the incentive for its miner to manipulate that timestamp to collect fees from prematurely included transactions. BIP113 motivation and specification
Relative time locks also use MTP. Their starting reference is the MTP of the block immediately before the block containing the output. Their ending reference is the MTP of the block immediately before the proposed spending block. Consequently, timing starts from a chain-defined reference around confirmation, rather than the moment someone creates or broadcasts a transaction. BIP68 time-based calculation
A phone showing the target date has therefore not established that Bitcoin's timing condition is satisfied. MTP follows recent block timestamps, and BIP113 notes that its introduction delayed time-based eligibility relative to the old rule. A wallet's calendar estimate needs that qualification. BIP113 compatibility
Identify the route that is delayed
An output can offer alternative spending paths with different conditions. BIP112 describes arrangements with an immediate path for someone who knows a particular secret and a delayed path for another participant. A timelock on one path therefore does not necessarily freeze every way of spending that output. BIP112 retroactive invalidation examples
This also explains why waiting is only part of a protocol. A delay can provide another participant with a response window, but the participant still needs to act through the appropriate path. BIP112 uses this property to explain protection against revoked payment-channel transactions. BIP112 payment channels
For a useful reading checklist, identify the specific output and spending path, the absolute threshold or relative interval, its units, and the other required authorizations. Then ask what must happen after eligibility. A timelock establishes a timing constraint; completing a payment still requires a valid spending transaction. That is the level of detail needed to interpret a wallet's promise without mistaking a countdown for a complete spending policy.