What sharing a Litecoin extended public key reveals — experiment v1.0.0

ACTUAL RUN
17 October 2026, 08:37:45–08:37:48 UTC. Pinned Litecoin Core 0.21.5.8.
One fresh regtest node, wallet support disabled, peer networking disabled,
loopback RPC only, 32 MiB configured cache, one validation worker. No wallet,
funds, blocks, transaction, mainnet scan or private counterpart was an input.
The own node exited 0 and its fresh data directory was removed, as recorded.
57 experiment assertions passed.

DECLARED PUBLIC FIXTURE
P is the PUBLIC extended key for m/0H from BIP32 standard test vector 1.
The standard publicly documents private counterparts elsewhere. This package
omits them; that does NOT make the fixture safe for funds. Never fund any
fixture address or use this key as a real wallet. Only regtest destinations
were derived here. No real user's xpub, seed, private key or wallet was used.

The public payload's 4 version bytes were changed from 0488b21e to 043587cf,
then the Base58Check checksum was recalculated. The remaining 74 payload bytes
are unchanged. This creates a regtest-compatible tpub representation; it does
not convert a wallet/account/coin or make a prefix a unique coin identifier.

The synthetic descriptor tree declares:
  wpkh(P/0/*), indices 0–9: 10 receiving candidates.
  wpkh(P/1/*), indices 0–4: 5 change candidates.
These roles are declared inputs, not a discovered real wallet or universal
BIP44/BIP84/Electrum structure. Core's legacy wallet layout also differs.

OBSERVED RESULTS
15 of 15 public candidate addresses matched independent Python standard-library
BIP32 public derivation and witness-v0 Bech32 encoding. The math was first
checked against the next published public key for m/0H/1 in the official vector.
A branch-0 public export alone reproduced the same 10 receiving candidates.
Five P/0/1/i nested descendants differed from the corresponding P/1/i sibling
change candidates. This finite illustration is NOT a mathematical proof of
general parent/sibling noninvertibility; the general boundary comes from BIP32.
Core accepted inspection of wpkh(P/0H/*) but actual deriveaddresses returned
error −5: Cannot derive script without private keys. All five actual inspected
descriptor records contained hasprivatekeys:false. The same public key under
pkh and wpkh yielded different regtest addresses, as explicitly recorded.

OFFLINE CHECK
Python 3.10+; no network, Core binary, wallet or third-party dependency:
  python verify.py.txt
The verifier checks the curated SHA256 manifest before loading public math,
recomputes all 15 primary addresses, ten branch-only matches, five nested
controls, the script comparison, CSV identities, recorded errors, trace and
cleanup flags. It also rejects checksum damage, public hardened requests and
private extended-key versions, and demonstrates wrong-network/chain-code
mismatches. It checks former cleanup RECORDS, not a live remote filesystem.
The small public-only math is educational and unaudited, not a wallet library.

FRESH REPRODUCTION
  python reproduce.py.txt /path/litecoind /path/litecoin-cli new-output-directory
The program requires public-derivation.py.txt alongside it and the pinned
Linux binaries. It accepts no existing datadir or wallet and creates its own
temporary directory. A 75-second work alarm allows bounded shutdown; the private
runner additionally limits its process group to at most 90 seconds. The declared
public derivation is deterministic; new run times may differ. The offline
verifier checks this frozen evidence, rather than proving a new node's behavior.

BINARY SHA256
litecoind 63fb440cdc5e2e7d46144b8e3a47dab4725fa9c056a77b8b12b11854504f4838
litecoin-cli d185011cc0dbb5d2dd20611e9dc060dbb0a5d9be31a03f57da5dbd3dad4c3769
Pinned bytes identify the runtime, not a reproducible-build or security audit.

LIMITS
Candidates are not proof of actual address usage. Usage/history/balance requires
separate chain data and correct discovery settings; no such scan was done.
The exported node, suffix path, script and network determine the intended scope.
Key-origin annotations are not a substitute for the correct derivation suffix.
Receiving-only disclosure can narrow direct derivation but cannot erase on-chain
links or a service's existing records. The xpub alone contains no signing private
key; it is not a universal no-theft guarantee. BIP32 warns that a parent public
extended key plus a descendant private key reachable through only non-hardened
steps can expose the parent private key and its subtree. This is a source-based
caution only; we neither generated nor demonstrated that private-key combination.
No identity, ownership, reserve, exclusive control, actual-wallet recovery,
all-address discovery, privacy score, signing, MWEB or hardware-wallet test.

PUBLIC PACKAGE
results.json / addresses.csv / nested-controls.csv: original finite results.
rpc-trace.json / rpc-help.json / cleanup.json: actual RPC and recorded cleanup.
public-derivation.py.txt / reproduce.py.txt / verify.py.txt: public math and code.
sharing-checklist.txt: practical blank privacy checklist; collects no key.
sources.json: upstream links, pinned version/commit references and boundaries.
SHA256SUMS.txt: integrity hashes, not an authenticity/security certification.
Publisher may additionally include exactly reviewed-source-index.json,
reviewed-source-snapshots.zip and artwork-provenance.json; their hashes must
also be listed in SHA256SUMS. Public source extracts omit private test-vector
values. Private remote runners, configurations, startup paths and scratch
source downloads are excluded from the curated public payload.