LITECOIN.WATCH — RELATIVE LOCKS
Package version 2026-10-31.1

QUESTION AND SCOPE

Does a five-block transaction sequence start when a candidate is signed, or
when its input output was confirmed? This is a controlled transparent regtest
study with Litecoin Core 0.21.5.8, not mainnet observation or an audited vault.
Every output, key, address, transaction and block is disposable and synthetic.
Do not send real LTC to a published test address. No real wallet, seed, account,
mainnet RPC endpoint or existing node datadir was used or accepted by the runner.

The archived absolute-lock study already covers nLockTime and CLTV. This study
asks a different question: relative input age (BIP68) and a mandatory P2SH
CHECKSEQUENCEVERIFY path (BIP112). Current wallet support and newer Core versions
may differ; the version and full source commit are pinned in the export.

CASE DESIGN

A single funding transaction confirms three 1-LTC outputs at the same height H:
one ordinary output, a separate untouched output, and one P2SH output requiring
5 CHECKSEQUENCEVERIFY DROP <compressed public key> CHECKSIG. A valid signature
is still required. The CSV operand is exactly 5, without the disable flag.
There is no alternate spending branch in this synthetic script.

The ordinary version-2 candidate is first signed early with sequence 5 and
locktime zero. Exactly the same signed bytes are checked again after the input
has four and five confirmations. A different candidate is rebuilt later against
the same input. The second old ordinary output is first used in any spending
candidate only when it is already aged; this separates first signing from
rebuilding an earlier proposal. Construction, signing and testmempoolaccept
are separate from actual inclusion.

Version 1 and the input disable flag provide ordinary-output negative controls:
they disable the transaction-level BIP68 age constraint in the tested setting.
The mandatory CSV path has its own version/disable checks. A later control uses
sequence 4 against the required operand 5, when ordinary input age is sufficient,
so a script failure is not confused with an earlier age failure.

A fresh funding output is then tested while its parent remains unconfirmed.
A nonzero relative age and sequence zero are kept distinct. Confirming a new
output creates a new relative-age origin; old coins elsewhere in the wallet do
not make that particular output old.

The time control uses input sequence (1 << 22) | 1: one 512-second unit. The
origin is median time past of the block BEFORE the input-confirming block.
The comparison uses MTP of the candidate block's predecessor. The runner checks
mock-clock-only movement, then exact chain-MTP offsets 511 and 512. These are
artificial test-chain timestamps, not measured real-world waiting periods.

HEIGHT ARITHMETIC

For enabled version-2 height locks with sequence N, the reviewed Core code
computes minHeight = input-confirming-height + N - 1 and requires the candidate
block height to exceed minHeight. For N=5, the first eligible block is H+5.
Mempool admission evaluates the next block: at tip H+3 the input has four
confirmations and next height H+4 is too early; at tip H+4 it has five
confirmations and next height H+5 can pass this constraint. Other validation
rules, fees, competing spends and miner inclusion remain separate conditions.

RECORDED OUTCOMES

The completed run contains 20 named admission states and 112 passing runtime
assertions. Five explicit block-validation attempts comprise two rejections and
three accepted blocks. These are checks within one completed controlled run,
not repeated independent experiments or an estimate of a user failure rate.

The shared parent confirmed at height 1352. At tip 1355 (four confirmations),
next block 1356 was too early for the unchanged sequence-5 candidate. At tip
1356 (five confirmations), that same candidate passed next-block admission.
A new candidate and the separate old output's first-ever spending candidate,
both signed at tip 1356, also passed immediately. The original, delayed-first-
sign and required-CSV5 spends were actually included in block 1357.

The new output confirmed at height 1358 and had its own younger age origin.
Its sequence-5 child passed at tip 1362 and was included in block 1363.
For the time case, parent height 1364 uses preceding block 1363's MTP
1500000228. MTP 1500000739 (origin+511) was too early; MTP 1500000740
(origin+512) passed. The required signed candidate was included in block 1377.
The time control is ordinary-output BIP68, not a separate time-operand CSV script.

Both node shutdown and removal of the disposable datadir were recorded true.
The 20-case and raw-RPC files remain authoritative over this prose summary.

RAW EVIDENCE

results.json: authoritative cases, candidate bytes, funding outpoints, exact
  chain snapshots, block-validation attempts, assertions and cleanup flags.
cases.csv: compact case table; does not replace raw evidence.
rpc-trace.json: method, parameters and Core stdout/stderr; generated private-key
  responses are redacted, local paths replaced, RPC cookies never recorded.
blocks.csv: headers of the experiment's post-bootstrap generated blocks.
relative-lock-test.py.txt: self-contained standard-library reproduction runner.
verify-results.py.txt: separate offline export verifier, run as shown below.
sources.json: immutable source URLs and byte hashes plus build provenance.
SHA256SUMS.txt: fingerprints of the frozen public files.
LICENSE.txt: original code and observation rights.

Each named case is a controlled state check, not an independent user, a
statistical success rate, an independent security review or proof that a
production wallet supports a recovery workflow. Core's mempool policy verdicts
are reported separately from explicit block-validation and inclusion evidence.

OFFLINE EXPORT VERIFICATION

With Python 3.10+ and the downloaded files in one folder:
python verify-results.py.txt

The verifier defaults to its own containing directory and writes nothing unless
you explicitly request --report PATH. It validates the recorded export and
package checksums without opening a node or contacting any network. The
--skip-checksums option is for package development only; use the default for
the published package. See the report limits: it does not verify signatures,
recreate Core execution or attest a software release's security.

SOFTWARE AND REPRODUCTION

The runner requires the exact verified Windows 64-bit Core 0.21.5.8 binaries:
litecoind.exe SHA256
7430c6d0d4cb59d355361a0b90ffbfc4ac725609483e04c242bf95372cc9b8fe
litecoin-cli.exe SHA256
6f835854576a473599f89b9842bf7855dabda1183f5a707ac5d5e15aa48761d8

These platform-specific hashes differ from the earlier Linux absolute-lock
study even though the release version is the same. Do not silently bypass a
mismatch and call the build identical. The download signature was checked
against the project's download key; this is not an independent certification
of the signer's identity. See sources.json for the archived provenance.

Python 3.10 or newer, standard library only, without -O:
python relative-lock-test.py.txt /path/litecoind.exe /path/litecoin-cli.exe new-output

The output directory must be new. The runner creates a fresh local temporary
lab and copies the same-hash executables there to avoid repeated NAS startup
costs. It always forces -regtest, binds RPC to loopback, disables inbound and
outbound peers, validates an empty chain/version, and checks zero connections.
It mines 1,351 initial blocks to put required script deployments in force.
Its initial mock time is 1500000000; MWEB remains inactive. No external peer or
network is needed after acquiring the specified software and this package.

The lab is stopped and removed after recording the run, including on ordinary
errors. Only the exact newly created temporary lab is eligible for recursive
cleanup; no existing node directory is accepted. Fresh runs create different
keys, addresses, signatures, transaction IDs and block hashes. Compare named
outcomes and height/MTP relationships rather than expecting identical file
hashes. The tiny educational signing helper is not production wallet software;
Core checks the required script in the actual recorded acceptance/inclusion.

LIMITS

A dry-run acceptance does not reserve an input, submit a transaction, guarantee
confirmation, make a wallet backup safe, or schedule a future payment. A
transaction-level sequence can be changed in a newly signed ordinary spend;
the mandatory script path is the distinct enforced condition demonstrated here.
This is one node/version/build and a small predeclared set of transparent cases.
No mainnet propagation, mining incentives, fee competition, reorganization,
hardware-wallet interface, Lightning implementation or custody product is tested.

Research, code and drafting used AI assistance. The separate offline verifier
is an AI peer-check of the export, not an independent human review or a complete
consensus/signature validator. No absence-of-bugs or wallet-safety guarantee is
claimed. Existing software, third-party sources and trademarks retain their rights.