Timelock

Anna and Pavel can arrange shared funds so that they can spend together at any time, while Anna can spend alone only after a delay. If Pavel stops responding, the delayed branch provides a recovery route agreed in advance. A branch here means one permitted way to spend; each can have different conditions. The lock therefore need not block every option at once. These rules must be part of the output when it is created. Adding an “unlock in a week” note to an ordinary wallet later is not enough. Even after waiting, Anna will need the relevant key and the information required to construct a valid transaction. A Timelock helps control access; it cannot restore lost keys. [3]

An absolute lock refers to a fixed boundary recorded in the transaction’s nLockTime field. If a transaction has an effective nLockTime set to block height 1,000,000, the earliest block satisfying this condition is 1,000,001: equality is not enough. A relative lock instead measures a delay from confirmation of the output being spent. If Anna’s output is created in block 1,000,000 and the relevant branch requires a delay of 6 blocks, spending it can satisfy that condition no earlier than block 1,000,006. These are example numbers, not the network’s current height. Signatures, other inputs and any additional locks still have to meet their conditions. Six blocks is not exactly an hour, either: blocks arrive at irregular intervals. The relative wait does not begin when the wallet is created or when Anna decides to use the money. [1] [2] [5]

Suppose Anna’s required delay has just elapsed. The network will not act on her behalf. Someone must still construct or use a prepared transaction, provide signatures, pay a fee and submit it to the network. Only then can a miner include it in a block. A satisfied Timelock is one fulfilled condition, not a reservation or an automatic transfer. It normally establishes when spending becomes possible, not when that option expires by itself. A reorganization replaces part of the chain with another valid branch. This can change an output’s confirmation and the calculation of its relative delay. For a custom arrangement, check every branch, wallet support and backups of both keys and spending rules in advance; time will not repair a wrongly specified condition. [2] [5]

Time-based conditions use Median Time Past, or MTP. For the block being evaluated, this is the median timestamp of the last 11 blocks ending with the previous block. Sort their times and take the middle one, the sixth: that is the median, not the arithmetic mean. BIP113 describes the rule and Bitcoin Core uses GetMedianTimePast for the calculation. The relevant time is therefore neither Anna’s current phone time nor the timestamp of the proposed block. Midnight on a calendar need not be the moment the lock is satisfied. Height-based locks instead wait for blocks; they do not count down seconds. [4]

We can now separate four names found in the documentation. nLockTime is a field in the whole transaction for an absolute boundary. nSequence on an input carries a relative delay under BIP68. But nLockTime alone does not lock a UTXO, an output not yet spent, against another transaction with different settings. Someone authorized to spend can create that other transaction unless the output’s rules prevent it. Bitcoin Script is the language used to express those spending rules. OP_CHECKLOCKTIMEVERIFY, or CLTV under BIP65, requires the corresponding absolute setting in the selected branch. OP_CHECKSEQUENCEVERIFY, or CSV under BIP112, checks the relative setting, while BIP68 enforces the actual delay. Neither CLTV nor CSV sends money or supplies a missing signature. Another permitted branch may be usable under different conditions. [1] [2] [3]

The following sections are a technical reference. A field is an item stored in a transaction; an input refers to an output being spent. nSequence is a field on each input. A special value can disable the effect of nLockTime, so merely entering a date is not enough. nLockTime is an unsigned 32-bit field; zero disables the absolute time condition. If every input uses SEQUENCE_FINAL, whose value is 0xffffffff, an unsatisfied nLockTime is ignored. An effective absolute lock needs at least one input with a different nSequence. This evaluates the particular transaction, rather than permanently freezing its inputs. [5] [7]

One field can express two different things, so a numerical threshold separates them. A Unix timestamp represents time as seconds since the start of 1970 in UTC. The candidate block is the block in which the transaction being checked would be included. LOCKTIME_THRESHOLD is 500000000. A lower nLockTime means block height; an equal or higher value means a Unix timestamp. With absolute checking enabled, nLockTime must be strictly less than the candidate block height or the relevant MTP. Equality is insufficient; this is neither an amount, an average height nor a protocol activation date. [5] [8]

An operand is a value supplied to an instruction; an opcode is the Script instruction itself. CLTV compares the branch’s stored requirement with the transaction’s setting. A separate check determines whether the chain has progressed far enough. This is more than comparing today’s date with one number. OP_CHECKLOCKTIMEVERIFY requires a nonnegative operand, the same height/time type as nLockTime and an operand no greater than nLockTime. The corresponding spending input must not have nSequence 0xffffffff. The opcode does not directly read a clock or chain height; transaction settings are checked separately when evaluating time-related validity. All other Script conditions remain necessary. [1] [6]

The nSequence number contains both a waiting period and switches that give it meaning. A bit is a zero or one in this representation; setting it can enable an option. The bit positions below belong to the technical format, not confirmation counts. For transactions of version 2 or higher, BIP68 enables a relative condition on inputs without bit 31 set. The low 16 bits specify the delay; bit 22 selects units of 512 seconds, otherwise blocks. Block delay starts at the confirmation height of the spent output. Time delay runs from the MTP of the block before that confirmation to the MTP before the candidate block. It is not time since the wallet created the transaction. [2] [5]

CSV performs a similar check for a relative wait. A mask selects the relevant nSequence bits; a disable flag is an off switch. Lightning Network is a network of payment channels: participants update how jointly locked funds are divided between them. The delay gives the other party time to respond if someone publishes an old, revoked state. A commitment transaction records the division of funds; a revocation key lets the other party spend the relevant output of a revoked version through a penalty branch. OP_CHECKSEQUENCEVERIFY with an active nonnegative operand requires version at least 2, the input disable flag unset, the same delay type and a sufficiently large nSequence value after masking. BIP68 separately enforces actual age. CSV permits a delayed recovery branch. For a Lightning to_local output, to_self_delay constrains the owner of the commitment transaction; the other party with the correct revocation key can use the penalty branch without that delay. [3] [9]

Two almost identical numbers can have different effects. The values beginning with 0x below are hexadecimal. NOP means an instruction that adds no time restriction here. It also matters whether the switch is in the transaction input or in the value passed to CSV. Bit 31 is SEQUENCE_LOCKTIME_DISABLE_FLAG and disables BIP68 relative interpretation only for that input. The value 0xfffffffe contains it but is not SEQUENCE_FINAL: it permits effective nLockTime and CLTV. The value 0xffffffff is final. A nonnegative CSV operand with the disable flag set behaves as a NOP; the flag set in an input, however, fails an active CSV requirement. These two cases must not be confused. [3] [7]

An RPC is a command for interacting with your node, the software that verifies Bitcoin blocks and transactions. Decoding only turns stored data into a readable listing; the testing command then checks whether a particular signed transaction would pass. A Mempool is the node’s local list of pending transactions. In Core 31, decoderawtransaction RPC shows version, locktime and each input’s sequence. For CLTV/CSV, inspect the Script actually used and the spent output; decoding alone is not proof of validity. testmempoolaccept RPC tests a signed candidate against the current chain, Bitcoin’s validity rules and the node’s local transaction acceptance rules, without accepting it into the mempool or broadcasting it. Check allowed and the rejection reason; success is not a promise of future confirmation. [10] [11] [12]