A forgotten MultiBit HD password may be recoverable when an intact supported wallet file and useful password context survive. First distinguish a password problem from missing wallet words, an archive-restore problem or an empty-wallet synchronization issue.

Identify the backup before choosing a recovery method

• mbhd.wallet.aes: the primary encrypted HD wallet.
• rolling-backup/*.wallet.aes: timestamped encrypted wallet snapshots.
• zip-backup/*.zip.aes: encrypted directory archives that can preserve additional application data.

For the documented software-wallet backup process, the primary wallet and rolling snapshots use password-based encryption; ZIP archives use a backup key derived from wallet words. An application password and wallet words are different recovery inputs. A file extension is a clue, not proof of its contents. A generic wallet.aes.json recipe is not a description of the MultiBit HD primary wallet format.

Build a practical password search

Preserve every original file and run an offline assessment on a copy. Useful context includes approximate length, language, keyboard layout and whether meaningful hints remain. A long random unknown password can make a search infeasible. Never modify the original backup to test a candidate.

Select the correct BTCRecover version and input

The maintained BTCRecover documentation describes installation requirements and supported wallet formats. The original gurnec project and maintained Python 3 versions have different environments. Follow the documentation for the actual version selected; do not combine an old repository with unrelated Python instructions or assume a generic JSON/ZIP filename is supported.

Token files and command options have defined syntax. Validate a search configuration with synthetic data before using sensitive material. This article does not provide an untested universal command or promise that brute force will recover any password.

Wallet words, password and restoration

Preserve the original words in their written order and record the original version if known. Do not identify a wallet solely by word count or assume that every HD wallet has a 13- or 18-word phrase. Keep any wallet date record: it helps choose a synchronization start point, but is not a replacement for the words.

The application password protects local wallet data. It should not automatically be entered into a modern recovery tool’s seed-passphrase field. The reviewed software-wallet creation methods use an empty seed passphrase; hardware-related and historical cases require separate identification.

The source distinguishes a BIP32 software wallet, an older beta implementation and hardware-related types. For the BIP32 software type, the source records the first receiving address at m/0'/0/0; this is not a universal recipe for every version. Verify a previously known address, receiving and change branches, and the search range before treating a zero balance as a failed recovery.

After finding a candidate

Confirm that the candidate opens the intended backup and reproduces the expected addresses. An encrypted file opening is useful evidence, but wallet selection, change branches and transaction history still matter. Modern wallets do not necessarily import an encrypted HD file directly. Plan migration as a separate step after verification.

Software and network problems

MultiBit is discontinued. A failure to synchronize or an address-format error does not prove the password is wrong. Preserve the error, wallet version and backup history, then diagnose the actual compatibility issue instead of making a blanket claim about every server or address type.

Maintained BTCRecover installation documentation

Documentation and further reading

• HD primary wallet, rolling backups and ZIP backups
• Wallet words and verification
• Wallet types, paths and the beta exception
• Original MultiBit HD source at the reviewed revision

Need help with recovery?

Email mail@keychainx.io with the wallet type, approximate date, backup extensions and error message. Describe the problem first; do not send passwords, wallet words, private keys or wallet files in an initial message. KeychainX can assess a wallet you own or are legally authorized to recover. Recovery is not guaranteed.

Technical review: 7 October 2026. Recovery depends on the surviving material and the original wallet version.

MultiBit Classic and MultiBit HD are discontinued Bitcoin wallets with different storage and recovery routes. Identify the original application and inspect the surviving backup format before choosing a tool.

MultiBit Classic: wallet files and key exports

Classic commonly uses .wallet wallet data and exported .key files. These are not the same format. An export can contain multiple private keys and can be encrypted or unencrypted. A wallet file needs a compatible wallet parser; a procedure for an encrypted key export must not automatically be applied to it.

Keep the associated wallet-data folder and its key-backup, wallet-backup and rolling-backup directories where available. Classic does not have an HD recovery phrase that replaces every original file.

Identify the backup before choosing a recovery method

• mbhd.wallet.aes: the primary encrypted HD wallet.
• rolling-backup/*.wallet.aes: timestamped encrypted wallet snapshots.
• zip-backup/*.zip.aes: encrypted directory archives that can preserve additional application data.

For the documented software-wallet backup process, the primary wallet and rolling snapshots use password-based encryption; ZIP archives use a backup key derived from wallet words. An application password and wallet words are different recovery inputs. A file extension is a clue, not proof of its contents. A generic wallet.aes.json recipe is not a description of the MultiBit HD primary wallet format.

Wallet words, password and restoration

Preserve the original words in their written order and record the original version if known. Do not identify a wallet solely by word count or assume that every HD wallet has a 13- or 18-word phrase. Keep any wallet date record: it helps choose a synchronization start point, but is not a replacement for the words.

The application password protects local wallet data. It should not automatically be entered into a modern recovery tool’s seed-passphrase field. The reviewed software-wallet creation methods use an empty seed passphrase; hardware-related and historical cases require separate identification.

The source distinguishes a BIP32 software wallet, an older beta implementation and hardware-related types. For the BIP32 software type, the source records the first receiving address at m/0'/0/0; this is not a universal recipe for every version. Verify a previously known address, receiving and change branches, and the search range before treating a zero balance as a failed recovery.

How to tell which case you have

1. Record the application name and version from the old installation or notes.
2. Keep the full original directory, including related files and dated snapshots.
3. Check file contents with a compatible diagnostic method on copies; extensions can be renamed.
4. Use a previously known receiving address to verify a proposed restoration.

Recovery limits

A remembered password does not repair every corrupted file. A word list accepted by another wallet does not prove the account path is correct. Password searches require a practical candidate set and suitable encrypted material. After verification, migrate with current wallet instructions rather than relying on discontinued software for ongoing use.

Documentation and further reading

• HD primary wallet, rolling backups and ZIP backups
• Wallet words and verification
• Wallet types, paths and the beta exception
• Original MultiBit HD source at the reviewed revision

Need help with recovery?

Email mail@keychainx.io with the wallet type, approximate date, backup extensions and error message. Describe the problem first; do not send passwords, wallet words, private keys or wallet files in an initial message. KeychainX can assess a wallet you own or are legally authorized to recover. Recovery is not guaranteed.

Technical review: 7 October 2026. Recovery depends on the surviving material and the original wallet version.

Extracting keys from MultiBit HD requires understanding the original wallet format and derivation behavior. It is not a general conversion from an encrypted JSON file to hexadecimal keys. Preserve the complete wallet and work on a separate copy.

Identify the backup before choosing a recovery method

• mbhd.wallet.aes: the primary encrypted HD wallet.
• rolling-backup/*.wallet.aes: timestamped encrypted wallet snapshots.
• zip-backup/*.zip.aes: encrypted directory archives that can preserve additional application data.

For the documented software-wallet backup process, the primary wallet and rolling snapshots use password-based encryption; ZIP archives use a backup key derived from wallet words. An application password and wallet words are different recovery inputs. A file extension is a clue, not proof of its contents. A generic wallet.aes.json recipe is not a description of the MultiBit HD primary wallet format.

What decryption does and does not provide

The primary HD wallet uses the application’s encrypted wallet serialization. Decrypting its outer layer is only one step; a compatible parser must interpret the wallet and any remaining protected key material. An encrypted ZIP backup is a different input. Renaming it or applying an ordinary archive password command does not establish a valid recovery.

Why a generic OpenSSL/WIF script is insufficient

A one-line OpenSSL command does not reproduce all format-specific derivation, initialization and serialization requirements. Likewise, converting arbitrary bytes into WIF does not prove they represent the right private key. Key compression and network settings affect the corresponding address. Verify each candidate against independently recorded wallet addresses before using it.

Wallet words, password and restoration

Preserve the original words in their written order and record the original version if known. Do not identify a wallet solely by word count or assume that every HD wallet has a 13- or 18-word phrase. Keep any wallet date record: it helps choose a synchronization start point, but is not a replacement for the words.

The application password protects local wallet data. It should not automatically be entered into a modern recovery tool’s seed-passphrase field. The reviewed software-wallet creation methods use an empty seed passphrase; hardware-related and historical cases require separate identification.

The source distinguishes a BIP32 software wallet, an older beta implementation and hardware-related types. For the BIP32 software type, the source records the first receiving address at m/0'/0/0; this is not a universal recipe for every version. Verify a previously known address, receiving and change branches, and the search range before treating a zero balance as a failed recovery.

Export, import or sweep?

An export must cover the relevant receiving and change keys; recovering one key may leave other funds unaccounted for. Importing a key retains its address in another wallet. Sweeping spends funds to a new destination. Plan migration separately after verification, using current wallet instructions and a verified destination. Do not overwrite the original backups or broadcast transactions simply to test a hypothesis.

When to seek an assessment

Incorrect passwords, damaged files, missing words and an empty restored wallet are different problems. Record the exact error and available file types without disclosing the secrets. A recovery method needs evidence that matches the case; there is no universal extraction command.

Documentation and further reading

• HD primary wallet, rolling backups and ZIP backups
• Wallet words and verification
• Wallet types, paths and the beta exception
• Original MultiBit HD source at the reviewed revision

Need help with recovery?

Email mail@keychainx.io with the wallet type, approximate date, backup extensions and error message. Describe the problem first; do not send passwords, wallet words, private keys or wallet files in an initial message. KeychainX can assess a wallet you own or are legally authorized to recover. Recovery is not guaranteed.

Technical review: 7 October 2026. Recovery depends on the surviving material and the original wallet version.

An old MultiBit HD wallet may be recoverable when sufficient wallet words or intact encrypted wallet data survive. A public address alone cannot reconstruct its private keys. Start by preserving the complete backup set.

1. Preserve the original evidence

Copy the old application data directory and external backups before opening the wallet. Keep filenames, dates and version information. Do not overwrite the only copy with a newly created wallet.

Identify the backup before choosing a recovery method

• mbhd.wallet.aes: the primary encrypted HD wallet.
• rolling-backup/*.wallet.aes: timestamped encrypted wallet snapshots.
• zip-backup/*.zip.aes: encrypted directory archives that can preserve additional application data.

For the documented software-wallet backup process, the primary wallet and rolling snapshots use password-based encryption; ZIP archives use a backup key derived from wallet words. An application password and wallet words are different recovery inputs. A file extension is a clue, not proof of its contents. A generic wallet.aes.json recipe is not a description of the MultiBit HD primary wallet format.

2. Choose the route your material supports

Complete wallet words can support reconstruction of the original wallet. An intact primary wallet or rolling snapshot can support password-based assessment. An encrypted ZIP backup needs its own archive/backup-key handling. These routes are related but not interchangeable.

Wallet words, password and restoration

Preserve the original words in their written order and record the original version if known. Do not identify a wallet solely by word count or assume that every HD wallet has a 13- or 18-word phrase. Keep any wallet date record: it helps choose a synchronization start point, but is not a replacement for the words.

The application password protects local wallet data. It should not automatically be entered into a modern recovery tool’s seed-passphrase field. The reviewed software-wallet creation methods use an empty seed passphrase; hardware-related and historical cases require separate identification.

The source distinguishes a BIP32 software wallet, an older beta implementation and hardware-related types. For the BIP32 software type, the source records the first receiving address at m/0'/0/0; this is not a universal recipe for every version. Verify a previously known address, receiving and change branches, and the search range before treating a zero balance as a failed recovery.

3. Verify before moving funds

Compare derived addresses with a receiving address recorded before recovery. Check transaction history, relevant branches and synchronization settings. A wallet interface accepting words or displaying an empty account does not prove that you restored the intended wallet.

4. Use format-aware tools

Do not apply a generic OpenSSL AES-CBC command and expect readable JSON private keys. Select a tool that explicitly supports the identified HD format and version, and test the method on non-sensitive sample data first. Do not upload wallet words to an online converter. If usable material is missing or the unknown password has no practical search space, recovery may be infeasible.

Documentation and further reading

• HD primary wallet, rolling backups and ZIP backups
• Wallet words and verification
• Wallet types, paths and the beta exception
• Original MultiBit HD source at the reviewed revision

Need help with recovery?

Email mail@keychainx.io with the wallet type, approximate date, backup extensions and error message. Describe the problem first; do not send passwords, wallet words, private keys or wallet files in an initial message. KeychainX can assess a wallet you own or are legally authorized to recover. Recovery is not guaranteed.

Technical review: 7 October 2026. Recovery depends on the surviving material and the original wallet version.