You restore an old Litecoin wallet, wait for the node to catch up and still cannot see an expected payment. A forum reply says “rescan.” Another says “reindex.” Someone else recommends deleting the data directory and starting again. Those suggestions can involve very different work, and none establishes that you have the right wallet.
First identify what is missing: wallet material, a wallet transaction record, historical block data or a usable node database. Repeating the largest operation will not resolve every smaller problem. In particular, rebuilding public blockchain data cannot recreate private signing material that was never in your backup.
This guide reviews Litecoin Core 0.21.5.8 source and documentation. Its three cases are fictional diagnostic examples. It does not report a new recovery experiment or promise a completion time. Mobile wallets, exchange accounts and MWEB recovery can require different procedures.
Four operations that solve different problems
Core stores several kinds of data. Its versioned file-layout documentation identifies wallet storage, raw block files, the block index and chain state separately. Keeping one of these does not preserve all the others.
| Operation | What it addresses | What it does not establish |
|---|---|---|
| Restore or load the intended wallet | Which wallet material the application uses | That historical discovery is complete or a signer is usable |
| Rescan wallet history | Recognizing relevant transactions in available blocks | That missing private keys have been recovered |
| Reindex chain state | Reconstructing the node's chain-state database from indexed blocks | That the wallet contains the intended account |
| Full reindex | Reconstructing chain state and the block index from block files | That unavailable history, a damaged disk or missing signing material is repaired |
A backup deserves its own check. The project's functional backup test explicitly restores wallet backups and checks resulting balances. Reading that test is not evidence that your particular file will restore. Preserve the original and use the documented recovery process for its actual format; a random file named wallet.dat is not a substitute.
Record the starting state before rebuilding anything
Keep the application version, network, intended wallet, expected transaction and exact error together. A remembered fiat balance is a weak reference. A known receiving destination and public transaction record give you something specific to investigate.
In an already authenticated local Core console, these are inspection commands. They do not start a rescan or rebuild:
getblockchaininfo
getwalletinfo
help rescanblockchainSelect the intended wallet before requesting its information. getblockchaininfo describes the node; wallet information describes the selected wallet. Do not paste a backup, private key or recovery phrase into a support message to answer either question.
The blockchain RPC definition identifies the network, processed height, known headers, estimated verification progress and pruning state. Record those fields together. Equal block and header heights alone do not establish that the node has the network's newest tip. Likewise, a node's verification estimate is not a wallet-discovery percentage.
If the node is still processing the relevant period, observe that progress before treating missing wallet history as a database failure. If the network or wallet identity is wrong, fix that mismatch before choosing an expensive reconstruction.
What a rescan can find
A rescan searches blocks for transactions relevant to the wallet. It needs both suitable wallet information and readable history. The wallet scanning implementation distinguishes successful completion, interrupted scanning and incomplete scans caused by unreadable data. A progress display alone does not tell you which outcome occurred.
In this release, the rescan RPC accepts start and stop heights. Its default starting point is zero; an omitted stop follows the documented tip boundary. An intentional range should cover the payments you need to discover. Beginning after a payment's block excludes that payment from that scan.
Do not choose a recent starting height merely because it makes the job shorter. Establish the earlier payment or recovery period first. For a known old wallet, the useful question is whether the requested history covers its activity, not whether the progress bar reaches the end.
Imported material also needs the right interpretation. Core's import documentation warns that related transactions may still be missing while discovery is running. Seeing an imported key recognized and seeing its transaction history completed are separate observations.
Pruning creates a historical boundary
A pruned node can validate the chain while discarding older block files. Those discarded bytes are unavailable to an ordinary local historical rescan. The pruneheight field identifies the oldest complete block in the retained contiguous history reported by this RPC. It is useful evidence about coverage, not a date at which your wallet began receiving.
Consider a fictional payment at block 1,200,000. Your node now retains contiguous blocks only from 3,100,000 onward. Scanning that retained range cannot reconstruct the earlier receipt from its original block. The height values are chosen examples, not a current Litecoin snapshot.
The rescan RPC checks the requested range for available blocks and can reject a request that crosses pruned data. Starting later to avoid that rejection does not recover the omitted history. Plan access to the required blocks as part of the wallet's recovery procedure.
Changing a pruning setting does not instantly restore deleted history. The startup implementation explicitly requires a rebuild and a full blockchain download when returning from previously pruned storage to unpruned operation. Account for disk space and connectivity before starting that route.
When reindexing belongs in the diagnosis
The release's command manual distinguishes two startup options: -reindex-chainstate rebuilds chain state from currently indexed blocks; -reindex also rebuilds the block index from block files. The same manual directs pruned-node or suspected block-corruption cases toward the full form.
These are node operations. An explicit block-database startup error is a different starting point from one missing receipt in an otherwise functioning wallet. Preserve the error and inspect storage health. Repeating a rebuild on unreliable storage can consume time without addressing the underlying fault.
Core's initialization code has separate failures and recovery prompts for loading and replaying the block database. Follow the applicable diagnosis rather than adding both flags to an online command you do not understand. A reindex remains dependent on readable input data and may require reacquisition of missing blocks.
There is no universal “this takes two hours” estimate here. Available history, storage performance, hardware and any necessary download change the work. The old storage comparison addresses disk requirements; it is not a benchmark for your rebuild.
Three cases that should lead to different next steps
These cases are teaching examples, not recovery outcomes measured on real wallets.
| Observed situation | Next evidence to establish | Unhelpful shortcut |
|---|---|---|
| The intended old wallet loads, but an old receipt is absent | Whether that wallet recognizes the destination and the required blocks can be scanned | Assuming current node synchronization proves complete wallet history |
| An empty wallet opens under an unfamiliar name | Which wallet was loaded and whether the intended backup is available | Rebuilding the node to make an unrelated wallet acquire old keys |
| Core stops with a block-database loading error | The exact failure, file availability and storage condition | Importing more wallet material into a node that cannot complete startup |
In the first case, a rescan may be the relevant operation. In the second, wallet identification comes first. In the third, node-data repair has to be considered on its own evidence. None of the examples establishes that coins were lost merely because an application displays zero.
Verify recovery at three separate levels
After the documented operation completes, check the expected destination, historical transaction and current spending setup separately. A found old receipt may already have been spent. Correct history is not the same thing as a present spendable balance.
A public-only import can also recognize transactions without supplying the missing signing material. Our balance-versus-signing guide covers that distinction. Avoid interpreting a correct number on screen as permission to discard the original backup.
Record the selected wallet, inspected chain tip, requested scan range, completion result and remaining mismatch. For support, share the relevant error through an authenticated channel and redact unrelated account details. Keep wallet backups and secrets private.
Frequently asked questions
Will reindexing restore a missing Litecoin wallet?
It reconstructs node databases from blockchain data. It does not recreate missing private signing material. Identify the intended wallet and backup separately.
Can a pruned node rescan its entire old wallet history?
An ordinary local rescan needs readable blocks for the requested range. It cannot read historical block files that have already been pruned. The recovery plan must account for obtaining the required history or another documented method appropriate to that wallet.
Does an explorer finding my transaction mean the wallet is recovered?
No. It establishes an observation from that explorer. Wallet recognition, current unspent value and signing authority remain separate checks.
Sources and scope
The linked sources are pinned to Litecoin Core 0.21.5.8 and were checked on 26 October 2026. This is a documentation and source review, not an independent security audit, a repair of a reader's wallet or a benchmark. No real wallet, mainnet payment or recovery phrase was used. The fictional cases show which question to investigate; they do not guarantee a recovery result.
