BIP38 paper wallets — one long string, one password, no second chances.

Which wallets use this format?

BIP38 is a standard, not an app — the same encrypted format appears across many tools:

• bitaddress.org (encrypt or decrypt a private key)
• Paper-wallet generators from the early 2010s
• Blockchain.com paper-wallet exports
• Offline BIP38 decryptors (e.g. bitaddress.org) — decrypt first, then sweep the recovered key into a wallet; Electrum and most wallets do not accept an encrypted 6P string as an ordinary private-key import

Wherever it was created, a BIP38 key protects exactly one private key — the string on the paper is the whole wallet.

What a BIP38 key is

BIP38 is a standard for password-encrypting a Bitcoin private key so it can be printed safely. The result is a Base58 string that always starts with 6P — and it cannot be used until the password decrypts it:

• The password is stretched with scrypt (parameters N=16384, r=8, p=8 in the standard) plus SHA-256 passes to derive the key.
• btcrecover attacks these directly (--bip38-enc-privkey) at roughly 72 guesses per second on a modern CPU — one of the slower formats.
• There is no wallet file, no backup copy, no “reset”. The encrypted string is the wallet. Lose the paper or the password, and there is nothing else to attack.

Why paper-wallet passwords are often recoverable

Paper wallets were mostly created 2014–2019 by everyday people, using tools like bitaddress.org. That era had a pattern:

• Passwords were almost always human-chosen — a memorable phrase, name + year, a sentence. That is exactly the material the memory method reconstructs.
• Many people reused a password from another account or an earlier paper wallet. Dig through every stored copy — the same password is likely in your old notes.
• If you still have the unencrypted address printed on the paper (the public key), it helps identify the target funds and verify a successful result — but it does not prove ownership by itself.

Realistic feasibility

• Human password + fragments: realistic. This is one of the most recoverable scenarios — the search space is your habit set, not all possible strings.
• A long random passphrase (e.g. 20+ random characters): not feasible. No tool changes that.
• Wrong guesses cost nothing but time — there is no lockout on an offline key. Test a candidate list at home for free with open-source tools, then widen it with better clues.

Recovery tools and speeds

BIP38 has one mainstream offline tool — and one important limitation:

*Measured on the reference CPU (Ryzen 9 9950X) — see the benchmarks & methodology page. BIP38 is scrypt with a large memory cost, so GPUs gain little and a tight candidate list beats raw speed.

Next steps

1. 1

   Copy the key exactly

   Character-perfect transcription of the 6P string, kept private.

2. 2

   Rebuild the password

   Names, dates, phrases from that era — the memory method.

3. 3

   Test offline

   Your candidate list against the key, using open-source BIP38 tools on an offline machine.

4. 4

   Try the tools, then decide

   BIP38 runs at only tens of guesses per second, so build a tight candidate list first — the btcrecover walkthrough handles BIP38 directly. Only a genuinely huge search space justifies an extended run — and on BIP38, a tighter candidate list beats more GPU time.

Common mistakes

• Confusing BIP38 with BIP39. A 6P string is a password-encrypted private key; a BIP39 seed is 12–24 words. They are recovered completely differently — what did you lose?
• Misreading the key. One wrong character makes every attempt fail. Copy the exact Base58 string and double-check it before running anything.
• Assuming the address helps crack. The printed address confirms which funds you’re after, but it does not shorten the password search.
• Believing a “guaranteed” recovery of a random passphrase. A long random BIP38 passphrase is not feasible — no tool or service changes that. Check the math first.

Frequently asked questions

Can a BIP38 paper wallet be cracked?

Yes, offline, with btcrecover (--bip38-enc-privkey) — at roughly 72 guesses per second on a modern CPU. The scrypt KDF is slow, so a human-chosen passphrase with clues is the realistic case; a long random one is not.

Does knowing the Bitcoin address help recovery?

The address confirms which funds the key belongs to and helps you identify the right key and verify a result — but an address alone does not prove ownership, and it does not reduce the password search space. Your memory and candidate list are what shrink it.

What if the BIP38 passphrase was randomly generated?

Then it is effectively impossible to brute-force — the search space is beyond any hardware. The realistic path is finding where it was stored: work the search checklist.

Related reading

Sources & references

1. BIP38 — passphrase-protected private keys
2. hashcat — example hashes (wallet formats & modes)