A wallet password can stop someone opening the wallet file on your computer. It cannot reach into an older copy and change the keys already stored there. To test that distinction, we used two copies of an encrypted Litecoin Core wallet and gave the older copy its original password. The copy signed and broadcast a payment, which we confirmed in a test block after the password change.
The original password was known in this experiment. We did not crack an encrypted backup. That detail matters: an encrypted file with an unknown password presents a different problem from a copied private key, exposed recovery phrase or backup whose password is already known.
The older file keeps its own password
Think of a wallet file as a container for signing material. Changing the password changes how that particular container opens. Litecoin checks whether a transaction satisfies the output's spending conditions; it does not ask which wallet file supplied the signature.
In the pinned Core implementation, walletpassphrasechange re-encrypts the existing master encryption key. It does not replace the spending keys with an independent set. That is why changing local encryption and changing control of an on-chain output are different operations. Core 0.21.5.8 implementation.
What we tested in Core
We used Core 0.21.5.8, wallet A and a consistent backupwallet snapshot loaded as B. Both copies were already encrypted before A's password change. The test funds existed only on regtest, Core's private test network. We recorded the password checks, signing responses and transaction-acceptance results separately. A successful unlock alone is weaker evidence than a signed transaction that the node accepts.
| Check | Current wallet A | Earlier copy B |
|---|---|---|
| Unlock with the original password after A's password change | Rejected: RPC error -14 | Unlocked |
| Unlock with the replacement password | Unlocked | Rejected: RPC error -14 |
| Sign the controlled original output | Not tested in this signing step | complete: true |
| Node accepts the copy's signed candidate | Not a password check | allowed: true |
Each password check started with walletlock. A changed its opening password; B retained its original one. The funded address's public key and the reported HD seed identifier remained unchanged.
These cases concern one wallet copy and a known password. They do not measure password strength, theft frequency or response time during a real leak.
Four different things people call a password
Before resetting anything, identify the secret involved. A password field can look similar while controlling a different part of the system.
| Secret | Its role | What changing it does not establish |
|---|---|---|
| Core wallet encryption password | Unlocks signing material stored in that wallet file. | Another copy has stopped holding the old signing material. |
| BIP39 recovery passphrase | Participates with the recovery words in deriving a seed. | Funds have moved from the wallet derived with the previous passphrase. |
| Hardware-device PIN | Controls access to the device under its specific security design. | A recovery backup disclosed elsewhere has been invalidated. |
| Exchange-account password | Authenticates access to an account with a service. | A self-custody private key has changed, or every active session and withdrawal permission has been removed. |
BIP39 uses the optional passphrase in seed derivation. Entering a different one normally selects different key material; it is not a reset button for the wallet containing your existing coins. Core's file-encryption password is not this BIP39 feature. If your wallet uses that optional recovery passphrase, distinguish exposure of the words alone from exposure of the words and the passphrase together. BIP39 specification.
For a hardware example, Trezor documents that the device PIN is independent of its recovery backup. Coinbase's password-reset instructions concern access to a service account. Neither workflow was performed here. Trezor PIN documentation · Coinbase account-password documentation.
A new receiving address may still belong to the copied wallet
A fresh address is useful for avoiding unnecessary address reuse. It is not, by itself, evidence that the underlying secrets are independent of an old backup. Hierarchical wallets can derive many keys from one seed, and a saved wallet file can contain keys prepared for future use. BIP32 key-tree construction.
After changing A's password, we requested another address from A. B reported that it owned this address and produced a message signature that Core verified. This case concerns the copied wallet's particular keypool. It does not show that every backup contains every future address. A backup containing only an individually imported key has a different scope from one containing the wallet's derivation material.
Ask whether the destination has independent recovery material, rather than whether its address looks new. See our receiving-address guide for normal address changes and our recovery experiments for backup contents and discovery limits.
What changed after the transfer to an independent wallet
We created a separate wallet C. B spent the controlled 1 LTC input to C, delivering 0.9999 LTC with a 0.0001 LTC fee. We broadcast that transaction and mined one confirming block. We checked two different objects: the original output after its confirmed spend, and the new output controlled by wallet C.
| Candidate | Recorded result | What it establishes |
|---|---|---|
| Copy B attempts to spend the original output after the transfer confirms | Signature complete; rejected: missing-inputs | The original input was spent, although its old key could still create a signature. |
| Copy B attempts to sign the new output belonging to C | complete: false; candidate rejected | Whether B supplied the required signing material for that specific new output. |
| Independent wallet C signs a candidate spending its new output | complete: true; mempool allowed | A valid-signature and mempool-admission control; this second candidate was not mined. |
B still signed a different candidate for the already-spent input. It could not sign C's new output; C could, and its candidate passed the mempool check. We did not broadcast that second candidate. The old key is not revoked across the network. If someone later pays its address again, that creates another output under the old spending conditions. Update saved withdrawal destinations, payment requests and recurring invoices as part of a migration.
A real transfer needs a checked destination, suitable fee and confirmation. We did not test an attacker racing the owner or malware substituting an address. A small destination check does not protect the old key while you wait.
Changing a future transaction's date also leaves its ordinary input under the same key holder's control. Our timelock experiment tests that distinction and compares it with a condition actually required by an output's script.
A status message was not enough to prove new keys
While reviewing the source, we found another reason to check the actual operation. The encryptwallet response includes the phrase “new HD seed was generated”, while the pinned implementation comments out seed replacement for MWEB key management. During setup, the reported hdseedid was also identical before and after initial encryption. This is one observed setup case, not a claim of a security vulnerability. RPC response · corresponding implementation.
The password-change experiment still uses an already-encrypted snapshot. Neither its method nor its spending proof relies on the initial-encryption status message.
Match the response to what was exposed
| Situation | First distinction to make | Do not assume |
|---|---|---|
| Someone saw a public receiving address | Public information versus signing material. | The address alone lets them spend your LTC. |
| An encrypted backup file may have escaped | Whether its original password was also exposed; preserve the file's encryption context. | A password change updates the escaped file. |
| A private key or complete recovery material was disclosed | The affected keys, accounts and spending policy. | A new PIN or address within the same wallet removes the disclosed secret. |
| The computer may still be compromised | Whether it can observe new secrets or substitute payment details. | Creating another wallet on it establishes a clean destination. |
Do not upload recovery words, wallet files or private keys to a “revocation”, “validation” or rescue website. A public transaction ID is enough to inspect a transfer in our transaction checker; it cannot establish that your devices or backups are secure.
A migration checklist you can keep
- Write down what may have escaped: a public address, encrypted file, old password, individual key or recovery material. Keep secrets out of the incident notes you share.
- Identify the affected wallet and backup format. Use our recovery-plan checklist when the format is unclear.
- If replacing control, prepare independent recovery material through a trusted wallet procedure on a suitable device. Check its backup before depending on it.
- Verify the complete receiving address through a trusted display or channel. Do not rely on the first and last characters.
- Record the actual transaction ID, destination output, fee and confirmed status. Confirm the intended amount arrived; a broadcast notification is not a completed migration.
- Replace old payment requests and saved destinations. Keep the old backup's original password context in mind if you must retain it for historical records.
A forgotten password without suspected copying is a different problem. Identify your backup and the wallet's documented recovery procedure first. This experiment does not tell every person who forgets a password to move funds.
Files and reproduction
Recorded password-test results · runner · offline verifier · migration worksheet · instructions · complete research package. The 6 October 2026 release records 12 password-study cases. A repeat in another fresh test directory matched all 12 case outcomes. The package contains the controlled setup, recorded results and reproduction instructions. Tests used synthetic wallets and regtest funds; no customer's wallet, seed phrase, exchange account or hardware device was accessed. Do not send real LTC to any test address.
The hero is an AI-generated editorial illustration, not a photograph of the experiment. Research, code and drafting were AI-assisted; the original diagram explains the mechanism. No independent external review is claimed. Report a reproducible discrepancy through our corrections page.
