We gave Litecoin Core one standardized public extended key and a declared address layout. It derived ten receiving addresses and five change addresses without a wallet or private key. Giving it only the receiving branch’s public extended key reproduced the same ten receiving addresses. No seed, signature or funds were involved.
That is why an extended public key deserves more care than an individual payment address. It can disclose a repeatable set of addresses, including candidates for future use if the wallet continues using the same subtree, script and network. It does not show which candidates have actually been used or establish a balance by itself.
This guide explains the difference, shows our bounded experiment and gives a practical way to decide what a service actually needs. Do not paste your real extended key into a website to follow along. The downloads contain only public standardized test fixtures and regtest addresses that must never be funded. The standard publishes these fixtures’ private counterparts elsewhere; omitting them from our package does not make the fixture safe for funds.
An extended public key describes a branch, not one payment destination
A regular address is a destination you can give somebody for a payment. A BIP32 extended public key combines a public key with a chain code and derivation metadata. With the right non-hardened path and script rules, software can use it to derive more public keys and addresses.
The familiar prefix xpub is not a complete wallet description. It does not universally specify the coin, the address script, an account’s original path or which branches a wallet used. In the tested Core release, Litecoin mainnet uses the same extended-public version bytes as Bitcoin. A prefix alone is therefore an insufficient network check.
Our experiment explicitly chose wpkh, an ordinary native-SegWit script, and regtest address encoding. We called the selected public parent P, designated P/0/i as receiving and P/1/i as change, and supplied the index ranges. Those choices were inputs to the experiment. They were not discovered from the key’s label.
Some wallet conventions place receiving and change branches beneath an account. BIP44 describes one hierarchy with hardened account levels and non-hardened branches below them. Wallet formats differ. Our declared tree is not a claim about every Litecoin wallet, a real account export or Core’s legacy wallet layout.
Decide what the recipient needs before exporting anything
Ask what task the requester will perform. A shop asking where to send one refund does not need a repeatable view of a wallet branch. A person investigating one payment can usually start with the relevant transaction record. A watch-only service that generates new receiving addresses needs more context and a broader disclosure decision.
| Data | Possible use | What to consider before sharing |
|---|---|---|
| One address | Receive one payment. | Its public transaction history and other on-chain links may still be visible. |
| Transaction ID and relevant output | Investigate a specific transfer. | It exposes that transaction and linked outputs; avoid publishing unrelated account details. |
| Receiving-branch extended public key | Derive destinations within a specified receiving subtree. | It can associate multiple candidates in that subtree; script, network and path still matter. |
| Parent or account-level extended public key | Watch multiple covered branches. | It may expose receiving and change branches if the actual layout permits public derivation. |
| Seed, private key or extended private key | Not needed for these public-only tasks. | Do not provide spending secrets as a substitute for a public export. |
An individual address is not a promise that every other payment is untraceable. The point of a narrower export is to avoid directly handing over a derivation tree that the task does not require. Public transaction analysis can create additional links beyond the exported branch.
If the request is only to demonstrate signing control, an extended key is a different disclosure. The guide on what a signed Litecoin message proves explains the limits of that proof. Neither a signature nor an xpub is a general identity or reserve certificate.
Our public-only experiment made every choice explicit
On 17 October 2026 at 08:37 UTC, we started one fresh Litecoin Core 0.21.5.8 regtest node with wallet support disabled. Peer networking was disabled, RPC was loopback-only and no blocks or transactions were created. We used the public key for m/0' from BIP32 test vector 1 as our synthetic parent.
To make the public fixture usable on regtest, we re-encoded its version from 0488b21e to 043587cf and recalculated the Base58Check checksum. The remaining 74 bytes of the extended-key payload were unchanged. This produces a tpub representation; it does not move keys, funds or an account between networks.
We supplied ranged descriptors for ten receiving candidates, wpkh(P/0/*) at indices 0–9, and five change candidates, wpkh(P/1/*) at indices 0–4. Each actual descriptor-info result reported hasprivatekeys: false.
Separately, our Python standard-library implementation performed public BIP32 derivation and encoded the regtest witness addresses. We first checked one derived extended key against the next public key published in the official BIP32 vector, then compared the address calculations with Core. No wallet export, private counterpart, seed or balance scan was an input.
The parent revealed both declared branches
| Operation | Declared range | Observed result | What it establishes |
|---|---|---|---|
| Receiving addresses from parent | P/0/0–9 | 10 of 10 matched independent math. | The parent derives these receiving candidates publicly. |
| Change addresses from parent | P/1/0–4 | 5 of 5 matched independent math. | This same parent also covers the declared change branch. |
| Receiving-branch key alone | Branch 0, then indices 0–9 | The same 10 receiving addresses. | A narrower export still reproduces its descendant candidates. |
| A nested path from branch 0 | P/0/1/0–4 | All five differed from P/1/0–4. | Appending “1” below branch 0 is not moving to its sibling. |
| Public hardened derivation | P/0'/*, first index | deriveaddresses returned error −5. | This operation could not derive the script without private keys. |
| Same public key, different script | P/0/0 with pkh instead of wpkh | A different regtest address. | The script wrapper is part of address interpretation. |
The first receiving result was rltc1qwlvfdv8ctae2ureaqjrugv4j8s5tw9yng9qlnq. The first change result was rltc1qhdjn79g0f5yq7tl2snz937tc6jst753vkwas8z. They are public regtest fixtures, not payment instructions. The complete fifteen-row CSV records paths, public keys, addresses and the independent comparison.
For the hardened attempt, Core accepted descriptor inspection but actual address derivation failed with “Cannot derive script without private keys.” That distinction matters: a descriptor can be recognized without being usable for every requested derivation.
A receiving branch is narrower, not a privacy reset
We derived the branch-0 extended public key offline, then gave that key to Core without the parent. It reproduced the ten receiving candidates. An observer with that export and the same address rules would not need you to announce each new candidate individually.
Our five nested controls illustrate a path mistake. From branch 0, adding /1/i means P/0/1/i. It does not mean P/1/i. The different addresses are a concrete illustration, not a mathematical proof that every possible attempt to recover a parent or sibling will fail. The general public-derivation boundary comes from BIP32’s construction.
Nor does a receiving-only export conceal every outgoing relationship. If addresses appear together in public transactions, change identification or other on-chain analysis may connect them. Narrowing what a service can derive directly does not erase information it already collected.
A previously disclosed extended key also does not stop describing its old subtree because you uninstall an app or remove a browser extension. Before changing future wallet use, understand your wallet’s account and backup rules. Do not abandon access to existing funds or assume that changing an address label changes its derivation.
Address derivation is not a balance or ownership proof
The xpub supplies no transaction history by itself. Software must obtain separate chain information and apply the right address and discovery rules to investigate usage. Our node stayed at regtest height zero. We did not scan mainnet, discover a real wallet, measure a balance or verify ownership.
This is also why two applications can show different results after an import. They may use different scripts, paths, ranges or discovery limits. A blank screen can mean the settings did not reach the relevant addresses; it is not automatically proof that coins disappeared. Our receive-address guide explains why one wallet can present many destinations.
Keep the original wallet name and version, network, exported node or account, path information and script format with a private recovery record. Metadata helps identify the intended tree; it does not make an incorrect suffix path correct. The tested wallet-recovery guide covers a separate recovery task.
An extended public key alone does not contain the signing private key. That is not a universal no-theft guarantee. BIP32 warns that combining a parent extended public key with a descendant private key reachable from that parent through only non-hardened steps can expose the parent private key and its subtree. This guide does not demonstrate that attack. Do not export private keys to complete a watch-only setup or treat public-key disclosure as a reason to relax private-key protection.
Questions to ask a watch-only or tracking service
| Ask | Why it matters | Useful decision |
|---|---|---|
| Do you need one transfer or ongoing address derivation? | The disclosure scope is different. | Start with one address or transaction when that answers the task. |
| Which branch, script and network do you support? | A key prefix is insufficient configuration. | Confirm the exact supported export and avoid guessing from an empty result. |
| Will this include my change branch? | A sufficiently broad parent may cover both branches. | Understand the exported node before treating it as receiving-only. |
| Where is the data processed, stored and retained? | An ongoing address map can be linked to an account or identity. | Read the service’s actual handling terms before uploading. |
| Are you requesting any signing secret? | Public derivation did not require one in our test. | Do not provide a seed, private key or extended private key. |
Use your wallet’s official export instructions and check the receiving software’s documented format. Do not submit a real key to random “xpub checkers,” conversion pages or public support posts to see what happens. The printable sharing checklist records the questions without collecting any key.
Verify the experiment without exposing your own wallet
Download the version 1 research package and run python verify.py.txt with Python 3.10 or later. The offline verifier needs no wallet, node, network connection or additional package. It recomputes the public descendants and regtest addresses and compares them with the actual Core results.
The original experiment passed 57 assertions. Its recorded node exit code was zero and its cleanup flags state that the fresh directory was removed. An offline reader can check those records, not inspect the former process. Fresh reproduction is a separate program that accepts only the pinned Core binaries and creates its own temporary data directory with wallet support disabled.
Individual downloads: fifteen-address CSV, five nested-path controls, measured results, method and limitations and checksums. The public math is educational, not an audited wallet implementation.
Primary references are BIP32’s public derivation and security sections, the stated BIP44 convention, and the tested Core descriptor rules and network encodings. The package’s public-only source extract and hashes preserve provenance without reproducing the standard’s private test-vector material.
