Bitcoin's scripting system can require that time pass before an output becomes spendable. The mechanism is simple, and a substantial amount of protocol design rests on it.
Two ways to express time
A timelock can specify a block height or a timestamp. Height is precise about position in the chain, while timestamps are approximate because block times vary.
Height-based locks are generally preferred where exactness matters, since the number of blocks is unambiguous and cannot drift.
Timestamp-based locks are used where a real-world date matters more than a chain position, accepting that arrival will not be exact.
Absolute and relative locks differ in reference point
An absolute lock names a specific height or time, and the output cannot be spent until the chain reaches it.
A relative lock names a duration measured from when the output being spent was confirmed, so the deadline depends on the output's own history.
Relative locks are what allow a structure to specify that a party has a set period to respond after something happens, without knowing in advance when that will be.
Enforcement happens at two levels
Transaction-level fields cause a node to reject a transaction that arrives before its lock expires, which prevents inclusion in a block.
Script-level opcodes place the requirement inside the output's spending conditions, so any transaction spending it must satisfy the timelock.
The script-level form is the stronger one, because the condition travels with the output rather than depending on how a particular spending transaction is constructed.
Payment channels depend on the delay
Channels work by exchanging signed transactions off chain, with only the opening and closing recorded on the network.
A relative timelock gives the counterparty a window to respond if an outdated state is published, using a pre-arranged transaction that claims the funds.
The delay is what makes the enforcement possible, since without it a stale state could be settled before anyone could react.
Recovery arrangements use the same primitive
An output can be constructed so one key can spend immediately while another becomes able to spend after a long delay.
This supports inheritance and backup designs where a fallback key gains authority only if the primary has not moved the funds within a defined period.
Because the delay resets each time funds are moved, such arrangements require periodic activity, and the design's reliability depends on that maintenance actually happening.
The transactions enabling the fallback path must also be stored somewhere the intended recipient can find them, which turns a cryptographic arrangement into a records problem as much as a technical one.