Research . Wallet forensics

The MultiBit special-character password bug

Countless MultiBit users are certain of their password, yet it won’t open the wallet. The reason is a real bug: the password that actually locked the wallet isn’t the one they typed.

Aggiornato a luglio 2026 · KeychainX — Recupero portafogli dal 2017

MultiBit Classic was one of the most popular Bitcoin wallets of 2011–2014, and it left behind a distinctive recovery problem. Passwords containing special or non-ASCII characters were altered before encryption, so re-typing the “correct” password today simply fails. This page documents that bug and how recovery reverses it.

How MultiBit encrypted a wallet

MultiBit Classic encrypted private keys with AES, deriving the encryption key from your password using an OpenSSL-compatible routine (a salted key-and-IV derivation) via the Bouncy Castle cryptography library. In normal use this is sound: the password stretches into a key, the key decrypts the .key file. The problem was never the cryptography — it was what happened to the password before it reached the cryptography.

The truncation or mangling bug

When a password contained special or non-ASCII characters — accented letters, symbols, characters outside plain ASCII — the conversion from the on-screen text to the raw bytes that were actually hashed went wrong. High bytes were altered or truncated, so the byte sequence that encrypted the wallet did not correspond to the characters the user typed. The user remembers the password perfectly; the wallet was locked with a different, mangled version of it. Typing the true password can therefore never work, which is why these cases look impossible from the outside.

How to recognise it

The signature is simple: a MultiBit Classic wallet, a password the owner is confident about, and a flat refusal to open — especially when the password included anything beyond plain letters and digits. If the password was pure ASCII, a normal search usually suffices; the moment special or foreign characters were involved, the truncation bug is the prime suspect. It is by far the most common reason a “definitely correct” MultiBit password fails.

How recovery reverses it

Recovery means reproducing the bug rather than fighting it. We take the owner’s intended password and apply the same faulty character-to-byte handling the old software used, generating the mangled byte sequences it would actually have produced across the relevant character encodings. Each candidate is tested offline against a copy of the .key or .wallet file until one decrypts a valid key. Because the mangling is deterministic, reproducing it turns an “impossible” wallet back into a straightforward decrypt.

MultiBit HD is a different problem

Note that MultiBit HD is unrelated: it uses a 15-word seed and can suffer a separate derivation-path issue where a restored wallet scans as empty even though it holds funds — the coins are fine, the software derived the wrong addresses, and checking the alternate paths reveals the balance. Establishing Classic versus HD is the first fork in any MultiBit case, because the truncation bug applies only to Classic.

Why so many MultiBit wallets are stuck today

MultiBit Classic was the easy desktop choice in the years before hardware wallets and seed phrases were standard, so an enormous number of early adopters encrypted a .key file with a password they never expected to need again. Then KeepKey acquired MultiBit and shut development down, leaving no updates and no support. Years later, many of those wallets hold balances worth far more than when they were created, and their owners return to find the software gone and the “correct” password rejected. The truncation bug turns that already-stressful situation into an apparent impossibility — which is exactly why it’s worth documenting: the wall people hit is a known, reversible bug, not a lost wallet.

After recovery: leave the dead software

Because MultiBit is abandoned, the goal is never to keep using it — it’s to extract the keys and get out. Once a key is decrypted, it should be imported into a current, supported wallet and the funds moved, then the new wallet’s seed backed up properly on paper or steel, stored separately from any device. Leaving value in an unmaintained 2013-era application is a risk in itself; recovering the key is the moment to migrate to something modern and safely backed up.

Can you reverse it yourself?

In principle the mangling is reproducible by anyone who understands exactly how the old MultiBit build converted characters to bytes and which encodings were in play — but that is the hard part, and it is undocumented. Off-the-shelf password tools test the password as typed, which is precisely what does not work here, so a normal DIY attempt fails silently no matter how many variations you try. The value we add is the reproduction itself: generating the byte sequences the buggy code actually produced, rather than the ones the keyboard produced. If a straightforward attempt on a special-character MultiBit password has already failed, that failure is the signal that you are facing the truncation bug rather than a wrong password.

Our documentation

KeychainX has reproduced this truncation behaviour across the affected MultiBit Classic versions and character encodings over many client recoveries, because MultiBit is discontinued and no supported tool handles it. We publish it so owners understand that a “correct” MultiBit password that won’t open is a known, solved failure mode. For the hands-on walkthrough see our MultiBit recovery page.

Domande frequenti