A timelock refuses to spend early, it cannot force spending

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A refusal, not a compulsion

A script enforced by the network can make an output unspendable before a condition is met; it cannot make anyone spend it after. The BIP65 specification, assigned 1 October 2014, redefines a previously unused opcode into OP_CHECKLOCKTIMEVERIFY, which fails a script if the stack is empty, if the locked value does not match the transaction's own locktime in type or exceeds it, or if the input's sequence number signals the locktime is disabled. The BIP lists escrow, two-factor wallets with a delayed unilateral spend path, payment-channel refunds, and time-limited data-carrying payments among the uses this absolute, calendar- or height-based lock enables.

A second, relative version

An absolute lock has one weakness for anything meant to stay open indefinitely: it must be reset before it expires. The BIP112 specification, assigned 10 August 2015, introduces CHECKSEQUENCEVERIFY, which restricts spending based on how long ago the output being spent was itself confirmed, not a fixed date. As the BIP puts it, absolute locktime necessitates closing a channel and reopening it near the timeout, whereas with relative locktime the clock starts ticking the moment the transaction confirms in a block, a distinction the BIP ties directly to giving a payment-channel counterparty a predictable window to respond to a revoked transaction.

How each one actually reached the network

Neither opcode activated the moment it was written. Bitcoin Core 0.11.2, published 13 November 2015, shipped BIP65 enforcement as a soft fork gated on miner signalling: once 951 out of a sequence of 1,001 blocks contained version 4 or higher, older version-3 blocks would be rejected. BIP112, alongside BIP68 and BIP113, followed the same signalling pattern in Bitcoin Core 0.12.1, published 15 April 2016, which set a block-version signalling window running from 1 May 2016 to 1 May 2017 to gauge readiness before enforcement began. Neither opcode enforces anything about what happens if a private key is lost; a timelock protects against early spending, not against no spending ever occurring.

Questions to carry forward

• Does a custody or inheritance design specify whether it relies on an absolute date or a relative, confirmation-counted delay?
• Is there a fallback if the key meant to spend after the timelock expires is itself lost, since the lock enforces nothing about that?
• For a payment channel, does the stated response window match what BIP112's relative lock actually guarantees against a stale broadcast?

A timelock is a narrow, well-specified refusal built into consensus rules; the custody plan built around it still has to answer for everything the opcode itself declines to promise.