A five- relative lock counts from the history of the output being spent. Signing a transaction today does not give an already old output a fresh five-block waiting period. That matters if you are reviewing a delayed payment or an emergency spending path.
In our isolated Core test, a candidate first created and signed when its input already had five confirmations was immediately eligible for the next block. An earlier signed candidate spending another output from the same funding transaction had initially been rejected. The difference was the chain's progress, rather than the age of a signature.
This is a follow-up to our absolute timelock experiment. That study examined a fixed height or time. Here the question is how old a particular output must be, and what prevents a signer from choosing a different transaction.
Find the event that starts the clock
For a block-based relative lock, start with the transaction that created the output your payment spends. If that funding transaction confirms at height H, a relative delay of five makes H+5 the earliest block allowed by that relative height condition. Creating a backup, opening the wallet and signing a new transaction do not enter that calculation.
The input's nSequence field carries the relative delay, subject to the transaction version and flag rules described below. The pinned Litecoin Core implementation calculates the required height from the spent output's recorded height. It does not take a signing timestamp as an input.
A useful consequence follows. Two transactions signed at the same moment, each carrying a five-block delay, can become eligible at different heights because they spend outputs confirmed in different blocks. Conversely, signing later does not postpone the boundary for the same output. A signed file can also remain unbroadcast; holding the file and advancing the chain are separate events.
Why five confirmations can already be enough for the mempool
Core's checks whether a candidate could enter the next block. The current chain tip and the proposed inclusion block are different heights. At tip H+4, the funding transaction has five confirmations and the next block is H+5.
| Candidate | Chain tip / funding confirmations | Local result |
|---|---|---|
| Original signed candidate | 1352 / 1 confirmation | Rejected: non-BIP68-final |
| Same signed bytes | 1355 / 4 confirmations | Rejected: non-BIP68-final |
| Same signed bytes | 1356 / 5 confirmations | Allowed for next block 1357 |
| Separate output, first signed now | 1356 / 5 confirmations | Allowed for next block 1357 |
Our funding block was 1352. At tip 1355, four confirmations, the original candidate failed with non-BIP68-final. At tip 1356, five confirmations, its unchanged signed bytes passed. A rebuilt candidate and a separate candidate first signed only at that later height also passed. The original, the delayed-first-sign candidate and the valid CSV candidate were actually included in block 1357, which is H+5.
A successful testmempoolaccept response is a local admission check. It does not submit the transaction or guarantee that a miner will include it. The height condition is one requirement alongside valid signatures, available inputs, fees and the rest of the applicable rules.
A transaction delay does not force every signer to wait
There are two things to inspect: the candidate transaction and the output's spending conditions. On an ordinary key-controlled output, a signer can construct a different candidate with different sequence semantics. A delay carried by one signed file does not add a new condition to that existing output.
The BIP68 specification assigns relative-lock meaning to qualifying inputs in transactions with version at least two. Setting the sequence disable bit, 0x80000000, disables that input's BIP68 interpretation. A version-one transaction also falls outside those relative-lock rules. Other validity requirements still apply.
While the ordinary output still had only one confirmation, our separately signed version-one candidate passed the local admission check. A version-two candidate with the disable bit set also passed. Neither was submitted. They were different valid candidates spending the same ordinary output, not edits that preserved the original transaction's signature.
This is the question to ask about a proposed delayed-payment arrangement: does only this transaction wait, or does the funded output require the relevant spending path to wait? The distinction determines what another person with signing authority could do.
What a mandatory CSV condition changes
OP_CHECKSEQUENCEVERIFY, usually shortened to CSV, lets a script enforce an appropriate sequence value for a spending path. Our test uses a key-signed P2SH spending script with a mandatory block-based CSV value of five. The public method records the exact script and signed transaction bytes.
For a required block-based CSV value of five, the interpreter checks the transaction version, the input's disable flag, the block-versus-time type and whether the encoded delay reaches the required value. It works together with BIP68's age check. See the CSV specification and the pinned Litecoin interpreter.
The same shortcuts failed against that script: version one and the disable bit were rejected. At five funding confirmations, lowering the input sequence to four still failed the script check, while the correctly signed sequence-five candidate passed and was mined in block 1357. A sufficiently old input does not erase a script's requirement to express the permitted delay correctly.
Those results apply to the tested mandatory path. A more complicated contract can contain another branch with different rules. Review the complete spending conditions; a CSV instruction appearing somewhere in a script does not establish that every possible spend must wait.
A time-based unit is 512 seconds
The sequence type flag switches the relative measurement from blocks to units of 512 seconds (8 minutes 32 seconds). Litecoin's block target does not change that encoding into 150-second units. A value of one with the time flag set therefore means one 512-second unit in the relevant chain-time calculation.
The reference point is the median-time-past of the block immediately before the funding block. The endpoint uses the predecessor's median time for the proposed spending block. Median-time-past is derived from up to eleven block timestamps. It is distinct from the time displayed by a desktop clock or the timestamp written on the funding block itself. Median-time-past specification.
We tested a time-based BIP 68 candidate with sequence 4194305: the time flag plus one unit. Its funding block was 1364, and the preceding block's MTP was 1500000228. At an endpoint MTP of 1500000739, a 511-second difference, it was rejected. At 1500000740, a 512-second difference, it was allowed and subsequently mined in block 1377. Advancing only the 's mock clock, without advancing the chain's MTP, had left it rejected. These were artificial timestamps, not an observation of real-world waiting time. This case tests transaction-level BIP 68; our mandatory CSV script cases use the separate block-based value five.
The recovery question that a countdown can hide
Suppose a recovery path is described as available after a certain relative delay. Its age can accumulate while the ordinary owner continues using their wallet. Reaching an emergency, retrieving a backup or signing the recovery transaction does not itself restart that path's clock.
That can be intentional. Some designs need a recovery route to become available after funding has aged. An arrangement that promises a fresh response period after a later action needs its complete transaction structure examined. Ask which confirmed output anchors the period and what action, if any, creates a new output with a new confirmation history.
Our second funding exercise created a fresh output. Its sequence-five candidate failed while the parent was unconfirmed and again after the parent confirmed at 1358. It passed at tip 1362, five confirmations, and was mined at 1363. The new output supplied a new reference height. Changing signing time alone had not done that in the earlier cases.
A displayed countdown is useful only when its starting event, chain reference and spending branch are clear. For multiple inputs, inspect each relevant output's age and sequence settings; the transaction must satisfy all applicable input constraints.
Five checks before relying on a relative lock
- Identify the exact . Record the and output number being spent. Find its funding block in the chain you are checking. A wallet label or the date of a backup is not that evidence.
- Decode the candidate. Inspect the version and each input's sequence with your local node's
decoderawtransaction. Check the disable bit, measurement type and encoded value rather than treating the integer as a plain count of seconds. - Identify the spending condition. Obtain the relevant redeem script, witness script or wallet/contract descriptor. An alone does not expose a hashed script's full conditions. Check every applicable branch and signing authority.
- Use the right chain counter. For block delays, compare the funding height with the proposed inclusion height. For time delays, use the specified median-time references. Signing time and elapsed desktop time answer different questions.
- Separate eligibility from execution. Check whether a signed candidate is merely stored, locally acceptable, submitted or confirmed. Review the destination and fee as well as the delay; our PSBT review guide covers that wider inspection.
Inspect the experiment
One completed run used Litecoin Core 0.21.5.8 on Windows, a fresh regtest chain and disposable wallets, with peer connections disabled. It recorded 20 admission cases, 112 runtime assertions and five explicit block-validation attempts: two rejected and three accepted. The package records the binary hashes, CSV activation, signatures, case heights, MTP references and cleanup. It covers ordinary transparent outputs, one mandatory key-signed P2SH CSV5 path and one transaction-level time unit. It does not test mainnet timing, MWEB, reorganizations, a hardware device or a production recovery product.
Download the case table, structured results and RPC record. The reproduction script accepts binary paths and creates fresh disposable regtest data rather than opening an existing wallet.
The separate offline verifier reconstructs transaction identifiers and checks the exported byte fields, height/MTP boundaries, RPC observations and recorded block membership. It does not independently verify cryptographic signatures or attest that a published experiment was executed. Its report is a consistency check on the exported evidence, separate from the node's own checks. See the method and limits, versioned source record and package checksums. Research, scripting and drafting used AI assistance. The cover is a conceptual illustration.
