Three clocks, none of them yours
A Bitcoin timelock does one narrow thing: it stops a transaction from being included in a block before some condition is met. It does not move money, and it does not guarantee that a payment will ever arrive. The gap between those two ideas is where most confusion about “scheduled” Bitcoin payments begins.
Bitcoin actually runs on three different clocks. Block height counts blocks rather than seconds. Block time comes from the timestamps miners attach to blocks. Median time past — the median timestamp of the previous eleven blocks — became the reference for time-based lock checks under BIP-113 because it rises monotonically and a miner cannot bend it backward by faking a single timestamp.
The distinction matters. A promise to pay on October 30 is a calendar statement. A transaction locked to block height 900,000 is a chain statement. The two coincide only if you assume a steady block cadence, and even then the match is approximate. Anyone quoting an exact hour of settlement is leaning on something other than a timelock.
Absolute and relative delays
Bitcoin also has two kinds of delay. An absolute lock, set by the nLockTime field and enforced in scripts through OP_CHECKLOCKTIMEVERIFY, says a transaction cannot be mined before a given height or time. A relative lock, set by input sequence numbers under BIP-68, says an input cannot be spent until a defined number of blocks or time units pass after the output it spends is confirmed. The relative clock starts from a confirmed output, not from the signing of a contract.
The subtle failure is that a lock restricts a route, not the funds. An output can carry several spending conditions, and a lock on one route says nothing about whether another route could spend earlier. BIP-65’s own example is an escrow where two parties can spend together immediately while a third, time-delayed option opens later. A future locktime on one transaction is not proof that the underlying funds are frozen.
What to check instead
That points to a practical test. To judge a delayed-payment promise, separate four questions: what timing condition applies, whose signatures are required, who is responsible for broadcasting the transaction, and whether the eventual inclusion matches the intended payment. Each question needs its own evidence. A signed transaction does not prove anyone will broadcast it, and a broadcast transaction does not prove the destination was the right one.
For custody, the consequence is direct. A timelock can remove a service from the spending path after maturity, but it does not remove the user’s own signing obligation, and it transfers nothing by itself. Funds becoming eligible to move is not the same as funds moving. The working discipline is to check the chain condition at the claimed moment, then verify actual inclusion afterward — and to repeat the review if the output policy, the destination, or the responsible signer changes. A timelock restricts when a spend can happen; it is not a commitment that a payment will.
Source: BTCUSA.