Litecoin.watch: keys and time, version 1 Released 6 October 2026 Public package: /uploads/research/keys-and-time-20261006-v1/ Protocol: litecoin-watch-core-controls-v1 WHAT THIS PACKAGE CONTAINS Two separate controlled studies in Litecoin Core 0.21.5.8: 1. Timelocks: 13 cases comparing transaction-level nLockTime with a funded, key-signed CHECKLOCKTIMEVERIFY (CLTV) script. Cases also distinguish candidate-block height, chain median time past and the node's mock clock. 2. Passwords: 12 cases comparing an encrypted wallet A, an earlier consistent encrypted snapshot B and an independently created wallet C. The original password was known. No password cracking was performed. Each study was run and then repeated in a new empty regtest directory: four separate executions in total. All assertions passed. The first recorded pair passed 82 offline verification checks; the repeated pair passed the same 82. The repeat comparison matched all 25 named case outcomes. These are controlled case checks, not 25 independent human participants or a security success rate. FILES core-controls.py.txt: original study runner, downloaded as text for inspection. verify-controls.py.txt: stdlib offline verifier of the recorded observations. timelock-results.json / password-results.json: first frozen runs, including case records, version/hash metadata and deliberately redacted RPC traces. timelock-repeat-results.json / password-repeat-results.json: fresh repeat runs. timelock-cases.csv / password-cases.csv: compact case summaries; JSON and raw RPC records remain the authoritative observation files. verification.json: first-pair offline verification report. repeat-verification.json: repeated-pair checks and semantic outcome comparison. environment.json: executable version strings and SHA256 fingerprints. experiment-files.json: hashes of the frozen experiment working files. Its .py names refer to the original working names, distributed publicly as .py.txt. source-records.json: pinned third-party source URLs and content hashes, plus documentation context. Full third-party source files are not redistributed. scheduled-payment-checklist.txt / wallet-migration-checklist.txt: blank public worksheets. Never put signing secrets or wallet files in these worksheets. SVG files: two mechanism illustrations and one recorded height-boundary diagram. SHA256SUMS.txt / archive-sha256.txt: package-file and ZIP integrity fingerprints. LICENSE.txt: rights for original code, diagrams, worksheets and observations. The site may also provide a combined results.json summary for navigation. It does not replace the separate recorded runs or their raw RPC backing. SOFTWARE PIN The runner requires the reported version /LitecoinCore:0.21.5.8/ and records the actual executable hashes. The frozen runs used: litecoind SHA256: 63fb440cdc5e2e7d46144b8e3a47dab4725fa9c056a77b8b12b11854504f4838 litecoin-cli SHA256: d185011cc0dbb5d2dd20611e9dc060dbb0a5d9be31a03f57da5dbd3dad4c3769 core-controls.py SHA256: cf1caf4d26050cb4d39ea01e96ff1930ebd6d1cde8f127fbd2f64c32ae49f009 Source tag v0.21.5.8 was resolved to immutable commit: ec1b6489a900d09cf5991e220dce089c77a232a2 https://github.com/litecoin-project/litecoin/tree/ec1b6489a900d09cf5991e220dce089c77a232a2 Executable fingerprints identify the exact builds used here. A build for another operating system can have a different hash despite the same version. The verifier intentionally compares the published build fingerprints; do not silently bypass a mismatch and call it the identical published environment. OFFLINE VERIFICATION OF THE PUBLISHED DATA Requires Python 3.10 or later, using only the standard library. No wallet, node, network access, account or secret is needed for this step. Save the two .py.txt files as core-controls.py and verify-controls.py without changing their contents. From the extracted package directory run: python verify-controls.py timelock-results.json password-results.json core-controls.py Expected report: allPassed true, checks 82. To check the repeat files: python verify-controls.py timelock-repeat-results.json password-repeat-results.json core-controls.py The verifier checks case counts, version/build/source hashes, observed unlock and signing controls, timelock boundaries, corresponding raw mempool verdicts, selected block records and trace redactions. It checks the published evidence; it does not independently recreate Core's consensus engine or prove an absence of bugs. Some values are inspected structurally, so rerunning the experiment offers stronger evidence than accepting an offline PASS report alone. REPRODUCING THE STUDIES Requires Python 3.10+, the specified litecoind and litecoin-cli executables, and permission to create a disposable local process and temporary directory. Run each study separately with the same downloaded runner: python core-controls.py timelock /path/to/litecoind /path/to/litecoin-cli timelock-new.json python core-controls.py password /path/to/litecoind /path/to/litecoin-cli password-new.json An optional final positional argument is a parent folder in which to create the temporary test directory. It is not an existing node datadir. Quote paths containing spaces according to your shell. Do not run Python with -O: these research assertions are part of the checking protocol. The runner creates its own empty datadir, forces -regtest, selects a localhost RPC port automatically, disables inbound/outbound peers and verifies both an empty regtest chain and zero connections before creating wallets. It stops the node and removes that disposable datadir after recording the result. It never accepts an existing wallet or node datadir as a study input. The timelock setup mines 1,351 initial regtest blocks to activate CLTV; the regtest CSV activation height is 432. The password setup mines 101 initial blocks. The initial mock time is 1500000000, before the pinned regtest MWEB deployment start. Recorded chain data confirm MWEB was not active. These are transparent legacy-wallet/output tests, not MWEB tests. Core's regtest mining RPCs produce synthetic blocks; their timing is not an observation of mainnet hashrate, miner behavior or confirmation waiting time. The runner's small ECDSA helper signs one synthetic legacy CLTV construction. Core checks the resulting signature and script in the acceptance/block cases. This helper is research code, not a production wallet or a recommended way to construct a real recovery vault. Do not send real LTC to any test address. A rerun creates fresh keys, wallets, addresses, transactions and block hashes. Compare named case outcomes, height/time relationships and controls rather than expecting identical identifiers or JSON file hashes. The source/build hashes remain comparable when the same files and executables are used. ISO8601 metadata record actual execution times in UTC; the intentionally manipulated test-chain timestamps answer a different question. WHAT THE ACCEPTANCE RESULTS MEAN testmempoolaccept returns this node's admission decision for a candidate at the recorded tip. It does not broadcast a transaction or establish confirmation. The timelock study separately records generateblock rejection/acceptance and selected raw block inclusion, including an ordinary spend confirmed before its competing future transaction's lock and a valid key-signed CLTV spend. Consensus/block outcomes and mempool outcomes should not be conflated. In the password study, B actually signed and broadcast the shared 1 LTC input to C; one mined test block confirmed that transfer. C received 0.9999 LTC and the fee was 0.0001 LTC. A different later candidate signed by B for the spent old input was complete but rejected with missing-inputs. That is a spent-coin failure, not revocation of B's private key. For C's new output, B failed to complete a signature; C's candidate was complete and passed the mempool admission check. It was not broadcast or mined. The fresh-address case tests one address from the copied prefilled HD keypool, not all future addresses or all wallet/backup formats. The initial-encryption setup separately records an unchanged reported hdseedid despite the seed-change status text; the main password-change test uses an already-encrypted snapshot. BOUNDARIES, REDACTION AND RIGHTS No mainnet funds, customer wallets, recovery phrases, hardware devices, mobile wallets, device PINs, BIP39 passphrase workflows or exchange accounts were used. No live attacker race, compromised-device scenario, password-strength study or security audit of every Litecoin wallet was performed. A valid test case does not certify a user's device, backup or migration procedure. The RPC trace preserves recorded stdout/stderr and public synthetic transaction data, with generated private-key exports and disposable password parameters masked. Machine-specific filesystem paths are replaced by synthetic labels. This is deliberately redacted evidence, not an unaltered full-secret session dump. The runner contains its own disposable password labels; they are not real credentials. Do not substitute actual user secrets into the research script. Source references are pinned where possible; official PIN/account documentation provides background only and was not tested here. Original code, diagrams and worksheets use the package's MIT license; original observations are dedicated under CC0-1.0. Third-party software, sources, standards and trademarks retain their own rights. Editorial hero images are generated illustrations, not photographs of these tests. Research, code and drafting were AI-assisted. No independent external human review is claimed. SEPARATE SIGNATURE CROSS-CHECK Node.js 18+ standard library only. Keep the original downloaded filename so the byte-hashed runner stays unchanged. Run from the package directory: node signature-cross-check.cjs.txt This second implementation parses the saved legacy transactions and verifies SIGHASH_ALL signatures with Node crypto, funded script hashes, activation context and reporting/privacy distinctions. The frozen result contains 36 checks. It is an internal computational cross-check, not an independent external audit or fresh network replay. It reads files and prints JSON without writing results.