Litecoin wallet recovery tests
What did a backup actually restore: the addresses, the balance, or the ability to sign? Inspect the tested versions, exact cases and downloadable evidence.
Seed Phrase
In brief Secret recovery words that need the right wallet format, settings and any extra passphrase; keep them offline.
A sequence of secret recovery words that some wallets use to rebuild keys. Recovery must match the original wallet's word format, settings and any extra passphrase; other wallets use different backup methods. Keep the words offline and follow the original wallet's official recovery instructions.
For example In a BIP39 wallet, the same words with a different extra passphrase produce a different seed and can show different addresses.
Common mistake Entering recovery words into a website, sharing them with support or assuming every Litecoin wallet uses the same word format.
Compare: Seed phrase vs private key
- Seed Phrase
- Recovery words used by many wallets to rebuild key material; the correct format, optional recovery passphrase and wallet settings still matter.
- Private Key
- A secret used to authorize spending under its key conditions; one exported private key is not necessarily a backup of every key a wallet uses.
One example A fictional simple HD wallet can derive several receiving keys from one recovery setup; exporting just one of those private keys does not preserve the others.
Remember: Identify the complete backup method for the original wallet, keep secret recovery material offline and never paste it into this website.
Optional: what would make this clearer?
Choose one reason, or leave without answering.
BIP39
In brief A recovery-word standard used by some wallets to derive a seed from the words and an optional passphrase.
A specification that turns generated randomness into recovery words and derives a seed from those words plus an optional passphrase. It does not define every wallet's backup format or the complete address-discovery process. Not every recovery phrase is BIP39.
For example The same BIP39 words with two different passphrases produce different seeds and can open different wallets.
Common mistake Assuming twelve words identify the format, or that every Litecoin app will restore the intended accounts from those words alone.
Full glossary entryOptional: what would make this clearer?
Choose one reason, or leave without answering.
Passphrase
In brief A wallet-specific secret that can unlock stored keys or change the seed derived from recovery words.
A secret whose role depends on the wallet. A local encryption passphrase unlocks stored signing material. A BIP39 recovery passphrase is combined with recovery words to derive a seed. Changing the local unlock password does not by itself change that BIP39 recovery setup or move coins.
For example A typo in a BIP39 passphrase can derive a different valid wallet, whereas a wrong local encryption passphrase normally fails to unlock the file.
Common mistake Treating an app password, device PIN and recovery passphrase as interchangeable, or assuming a password change invalidates every old backup.
Compare: Wallet password vs recovery passphrase
- Wallet Encryption
- An encryption password unlocks a particular wallet's stored secrets; it does not replace a missing backup file or encrypt blockchain records.
- Passphrase
- A BIP39 recovery passphrase is used with recovery words to derive a seed; a different passphrase derives a different valid seed.
One example An incorrect unlock password is rejected by an encrypted Litecoin Core wallet; an incorrect BIP39 recovery passphrase can instead produce an empty-looking wallet with different addresses.
Remember: Check each secret's role in the original wallet: changing a local encryption password does not change a BIP39 recovery passphrase or move the coins.
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Derivation Path
In brief The key-generation route used by a hierarchical wallet to reproduce a particular account or address.
The sequence of steps used to derive a particular key from a hierarchical wallet's root material. Different accounts, address types or receiving and change branches can use different paths. Recovery needs the intended configuration, not just a valid-looking set of words.
For example Two apps can accept the same recovery words but show different addresses if they use different accounts or derivation paths.
Common mistake Treating an empty address view as proof that the words are wrong before checking the originating wallet's path and account settings.
Full glossary entryOptional: what would make this clearer?
Choose one reason, or leave without answering.
Watch-only Wallet
In brief A wallet view that can show addresses and activity from public information but cannot sign a payment on its own.
A wallet view built from public information that can recognize addresses and transactions without holding their private signing keys. It can show a balance or help prepare a payment, but spending needs the appropriate signer or cosigners through a supported workflow.
For example Importing an address or xpub can reproduce a receiving view while leaving that wallet unable to sign on its own.
Common mistake Treating matching addresses or a displayed balance as proof that recovery also restored spending authority.
Full glossary entryOptional: what would make this clearer?
Choose one reason, or leave without answering.
Private Key
In brief Secret data a wallet uses to sign spending; one key may cover only part of a wallet and must never be shared.
Secret data used to authorize spending under the conditions attached to coins. In a simple single-key wallet, anyone with that key can spend the coins it controls. A wallet may manage many keys; never share them.
For example A wallet signs a spend using a private key; the recipient only needs your payment, not that secret key.
Common mistake Sharing a key with support or assuming one exported key necessarily backs up every address in a wallet.
Compare: Seed phrase vs private key
- Seed Phrase
- Recovery words used by many wallets to rebuild key material; the correct format, optional recovery passphrase and wallet settings still matter.
- Private Key
- A secret used to authorize spending under its key conditions; one exported private key is not necessarily a backup of every key a wallet uses.
One example A fictional simple HD wallet can derive several receiving keys from one recovery setup; exporting just one of those private keys does not preserve the others.
Remember: Identify the complete backup method for the original wallet, keep secret recovery material offline and never paste it into this website.
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Compatibility release 2026-09-27.1 · Discovery release 2026-09-27.2 · Editorial responsibility: Jarosław Wasiński · Read the experiment report
Use these results to prepare a wallet migration plan →
The key is present. Why does the wallet show zero?
New controlled experiments in release 2026-09-27.2 distinguish missing transaction history, an imported key absent from an older backup, and an address beyond a fresh restore's initial range. Read the full report and troubleshooting guide.
| Test stage | Balance · regtest LTC | History entries |
|---|---|---|
| Live source after the two payments | 5 | 2 |
| Old backup, made before the separate key import | 2 | 1 |
| Same old backup after a full rescan | 2 | 1 |
| Refreshed backup, made after the import | 5 | 2 |
| Separate blank wallet: key imported without rescan | 0 | 0 |
| Same imported-key wallet: scan starts after funding block | 0 | 0 |
| Same imported-key wallet: scan includes funding block | 3 | 1 |
The zero-balance wallet owned the funded test address and signed a verified message before finding the payment. Scanning from block 103 missed funding block 102. Scanning the fully available chain from height 0 found the 3 LTC output; a spend signed by the recovered key was then accepted and mined on regtest.
The old backup remained at 2 LTC after a complete rescan because the later imported key was absent. The refreshed backup recovered the full 5 LTC. This tests legacy wallet files on the same available regtest chain; it is not a seed-only Core restore, a pruned-history recovery or a clean mainnet node resync.
An address outside Electrum's initial prepared range
The offline Electrum-LTC 4.2.2.1 test prepared 20 receiving addresses after a native-seed restore. We manually extended the source to 36 addresses. Another fresh restore prepared 20; after an explicit test gap setting of 40, it prepared 40, matched index 35 and signed a verified message.
This is an offline address-preparation test, not an online history or balance-discovery test. Forty is a fixed experimental setting, not a general recovery recommendation.
Core run: 2026-09-27T08:50:44.388986+00:00 · Electrum run: 2026-09-27T08:54:32.210879+00:00. 14 Core assertions and 7 Electrum assertions within fixed scenarios; no recovery success rate is estimated.
What each test established
| Backup and destination | Addresses | Balance / history | Signing evidence | Boundary |
|---|---|---|---|---|
| Encrypted Core wallet file → Core 0.21.5.8 | Three owned address types restored | 3 regtest LTC restored on the same test chain | Three signed candidates accepted; one spend mined | Wallet-file RPC workflow. No mnemonic or MWEB test. |
| Native Electrum seed → Electrum-LTC 4.2.2.1 | 20 receive + 10 change addresses matched | Not tested; offline | Restored wallet signed a verified message | No graphical interface or real payment tested. |
| Electrum master public key → Electrum-LTC 4.2.2.1 | 20 receiving addresses matched | Not tested; offline | No signature: public-key-only wallet | Matching addresses do not recover private keys. |
| BIP39 phrase → Trust Wallet Core 4.8.4 engine | 42 fixed derivations matched after fresh restores | Not tested | Not tested in this engine run | Library test. No mobile app or account-discovery test. |
| BIP39-derived account private keys → Electrum-LTC | 10 P2PKH/P2WPKH addresses matched across implementations | Not tested; offline | Both imported accounts signed verified messages | Account-key import; not Electrum's BIP39 seed wizard. |
A message signature tests access to the signing key. It does not prove a transaction was accepted by the Litecoin network. Only the Core part includes a transaction accepted and mined, and only on its isolated regtest chain.
Small differences that change a recovery
A different passphrase still works
The public BIP39 fixture was restored with no passphrase, recovery-lab and recovery-lab-typo. All three created a wallet; their first addresses differed. A valid address or a successful import is not proof of the intended wallet.
An address match can be watch-only
Electrum's master public key reproduced the receiving-address list. It had no account private key and could not sign our proof message. The CLI returned a generic error, recorded in the JSON, rather than a friendly watch-only explanation. A backup plan has to preserve spending authority, not only a way to view addresses.
| Synthetic passphrase | Derived first address |
|---|---|
| Empty | ltc1qjmxnz78nmc8nq77wuxh25n2es7rzm5c2rkk4wh |
| recovery-lab | ltc1qavu8d2556s3x3hsna7nlk5nlj6rqpsmvfqy227 |
| recovery-lab-typo | ltc1q20a8z8sa6cxk9zj8efw2rs7zdj8khfm8ada59p |
The fixture set also changes the account, receive/change branch and address index. Deriving index 20 succeeds. The second release tests offline preparation out to index 35. Neither release establishes online transaction discovery beyond a gap.
Identify your backup before restoring it
This page has no recovery input or upload. Keep your wallet files, seed words and private keys off websites and out of support messages.
I have a wallet file
Record the originating application and version, file format and whether it is encrypted. Preserve the original and work from a separate copy. The first Core test covers an encrypted legacy wallet file restored on an existing regtest chain. The second release adds history rescans and a later imported-key control on a fully available test chain. Neither establishes cross-wallet file compatibility or recovery of pruned mainnet history.
I have recovery words
Identify the seed format and any additional passphrase. Word count alone is insufficient. Record the coin/network, script type, account and derivation path where relevant. A native Electrum seed and BIP39 words use different restoration paths. Compare a known address before treating an empty result as evidence that your funds are gone.
I have an extended public key
It can restore an address view without restoring signing authority. Locate the corresponding signing backup or device and, for multisig, the full wallet policy and sufficient cosigner keys. This experiment does not cover multisig recovery; our separate Core multisig experiment explains that distinction.
- Authenticate the software and identify the exact backup format.
- Reproduce a known receiving address using the intended configuration.
- Check history discovery, change addresses and the relevant account or wallet policy.
- Verify signing capability using an appropriate controlled procedure; a displayed balance alone is insufficient.
- Record the scope and limitations of the check, and retain the original backup.
Inspect and reproduce the observations
Core: 2026-09-26T23:41:18.979963+00:00. Electrum: 2026-09-26T23:53:53.620108+00:00. Wallet Core: 2026-09-26T23:41:04.950Z. Timestamps are UTC. All cases use synthetic wallets. The reproduction package intentionally includes a public Electrum test phrase; it must never be used for funds.
Reproduction scripts and dependency lock
Original observations and diagrams are published under CC BY 4.0; our reproduction scripts under MIT. Dependencies retain their own licences. Cite the release number and this page. Software versions are pinned for reproducibility, not presented as security recommendations.
Prepared using AI-assisted coding and drafting, actual software runs and scripted checks. No independent human review is claimed. Report discrepancies through the corrections process, citing the release and case.
Versioned source repository
Download the research code and original observations as a source ZIP, or restore the Git repository from its bundle. The repository contains two tagged releases, synthetic fixtures, the experiment runner and confirmation-archive control tests. It is hosted here on Litecoin.watch.
Two different checks
python run.py verify checks the downloaded files, stored observations and collection-rule tests. It does not rerun wallet software. The experiment command in the README actually starts fresh, isolated Core and offline Electrum runs after checking the supplied executable hashes. Software is obtained from its original publisher; wallet binaries are not included.
The bundle can be cloned after downloading it: git clone litecoin-watch-research-2026-09-27.2.bundle litecoin-watch-research. Repository import timestamps are separate from the actual execution timestamps recorded inside results.
Independent reproduction
The review checklist defines what to reproduce and what evidence to report. A successful file check is not an independent wallet test. No external reviewer or human review is claimed; any future review must identify its author, date, exact release and tested scope.