Founders & Origins3 min readBitcoin (BTC)

Bitcoin Timelocks: Why the Right Key May Still Have to Wait

Bitcoin can require both a signature and a wait. BIP65 and BIP112 explain how a spending rule can reserve an exit for later, and why reaching a deadline does not send the money by itself.

Bitcoin Timelocks: Why the Right Key May Still Have to Wait

3-Minute Fast Briefing

  • The ParadoxBIP65 put an absolute time or block-height condition inside Bitcoin spending scripts.
  • The Turning PointBIP112 added a different kind of wait, measured from confirmation of the output being spent.
  • The LegacyA timeout can open another spending path; it neither sends funds automatically nor necessarily closes the original path.

Chronological Timeline

2014-10-01BIP65 is proposed

Peter Todd specifies a script-level absolute timelock.

2015-08-10A relative clock is proposed

BIP112 describes spending paths that depend on an output’s age.

2015-11Software support arrives

Bitcoin Core 0.11.2 includes BIP65 enforcement support, subject to activation.

A scheduled transaction was not enough

Having the key is usually the decisive fact in a story about a Bitcoin wallet. BIP65 asks a second question: is it time yet? Peter Todd’s proposal, dated October 1, 2014, introduced CHECKLOCKTIMEVERIFY, a rule that can require a particular time or block height before a spending path becomes usable. Bitcoin Core 0.11.2 later included support for enforcing the rule. Installing that release and activating the consensus change were separate steps.[1][2]

Bitcoin already had nLockTime, a field that could postpone the inclusion of a particular transaction in a block. But a postponed transaction was not a promise that its coins could not move earlier. Someone able to sign another transaction spending the same output might omit that wait. BIP65 moved the requirement into the script guarding the output: a transaction using that path must satisfy the prescribed locktime, rather than merely choosing to wait.[1]

An exit that becomes available later

The proposal’s examples make the distinction tangible. Imagine a wallet whose ordinary path needs signatures from both its user and a service. A second path can require only the user’s signature, but becomes available after a specified deadline. This is a design example in the BIP, not a claim that every wallet has such a recovery route. Before the deadline, the user cannot use that route alone; afterward, the service’s absence need not keep the funds stuck.[1]

A timelock is not an alarm clock that broadcasts a payment. The script still requires the relevant signature and a transaction spending the output. Nor does opening the delayed route automatically disable the cooperative one. In the example, user and service can still spend together after the deadline if the output remains unspent. The rule changes which actions are allowed, not which action is guaranteed to happen.[1]

When does the clock start?

An absolute threshold is not always the right clock. BIP112, proposed in August 2015 by BtcDrak, Mark Friedenbach and Eric Lombrozo, describes CHECKSEQUENCEVERIFY. Together with BIP68, it can require an output to reach a minimum age. Its escrow example begins counting when the funding transaction confirms. That differs from naming a fixed date that keeps approaching even before the deposit arrives.[3]

These are clocks defined by Bitcoin’s rules. Conditions can use block counts; time-based locktime checks use blockchain time conventions, including the median of recent block timestamps under BIP113, rather than a phone’s clock. BIP112 also explains how a delay can leave another channel participant time to respond to an old commitment. The point of waiting is therefore not simply to freeze money. It can give a counterparty time to act, or preserve a later exit, while signatures still determine who can take it.[3][4]

Connected Lore & Universe

Connected Stories in this Universe

Explore the chain reaction of historical breakthroughs, blunders, and legends.

Sources & References

  1. [1]Source 1: BIP65: absolute timelocks, motivation and wallet examplesBitcoin BIPs · 2014-10-01Accessed 2026-09-25
  2. [2]Source 2: Bitcoin Core 0.11.2 release notes: BIP65 support and activationBitcoin Core · 2015-11-13Accessed 2026-09-25
  3. [3]Source 3: BIP112: relative timelocks, escrow and payment channelsBitcoin BIPs · 2015-08-10Accessed 2026-09-25
  4. [4]Source 4: BIP113: median time-past for locktime calculationsBitcoin BIPs · 2015-08-10Accessed 2026-09-25
← Back to all storiesExplore all coins →