This guide explains BIP 38 Passphrase-protected private key in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 38 defines printable Base58Check records for private keys encrypted under a passphrase. It was designed around paper wallets and physical bitcoins, including an EC-multiply mode in which a manufacturer can create a funded address without learning the owner’s passphrase-derived private key.
- Why it matters: BIP 38 remains a defined encrypted-key format, but it concentrates recovery in one passphrase, one record and correct legacy software. Treat every 6P string as sensitive, test recovery before funding and prefer maintained deterministic custody for new deployments.
- Current position: Its status is Deployed, but the BIP comments discourage new implementation, and password loss or weak entropy can still make funds unrecoverable or stealable.
BIP 38 Passphrase-protected private key in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
What a 6P record contains
A BIP 38 string is a 58-character Base58Check record beginning with 6P. Prefix and flag bytes identify non-EC-multiply or EC-multiply form and compressed-key handling. Salt, encrypted halves and address-derived check data follow. The string is encrypted private-key material, not a wallet seed or an ordinary address.
Non-EC-multiply encryption
For an existing private key, scrypt derives key material from the passphrase and a four-byte address hash. AES-256 encrypts two halves of the private key after XOR processing, and the result is encoded with the format prefix and flags. Decryption must recreate and compare the address hash to reject a wrong passphrase or wrong compression interpretation.
EC-multiply workflow
The owner creates an intermediate code from a passphrase-derived factor. A printer combines it with independently chosen seed material to produce an address and encrypted key without learning the final private key. Optional lot and sequence values organise batches. Confirmation codes let the owner verify that a generated address depends on the intended passphrase.
Password and Unicode risk
scrypt slows guessing but does not rescue a short, reused or predictable passphrase. Unicode normalisation is part of interoperability: visually identical text can have different bytes if software handles it incorrectly. Recovery notes should state the exact characters and language method without placing the passphrase beside the encrypted record.
Address-hash leakage and false matches
A 32-bit hash of the resulting address is stored in plaintext as salt and a decryption check. It permits correlation with a likely address and can collide by chance. Software must derive the complete address and compare the defined bytes while treating a hash match as a check, not proof of ownership or balance.
Operational limitations
Paper degrades, QR print quality fails and single encrypted keys do not provide deterministic change-address recovery. Importing a key into an online wallet exposes it at decryption time, while sweeping requires fee and destination verification. Modern descriptor and hardware-wallet backups often give clearer recovery and audit properties.
Recovery rehearsal
Validate both encryption modes with official test vectors on offline, maintained software. Confirm compressed and uncompressed address cases, wrong passphrases, Unicode samples and confirmation codes. Then sweep a disposable test key into a new wallet rather than reusing it.
Frequently asked questions
What is BIP 38 Passphrase-Protected Private Keys?
BIP 38 defines printable Base58Check records for private keys encrypted under a passphrase. It was designed around paper wallets and physical bitcoins, including an EC-multiply mode in which a manufacturer can create a funded address without learning the owner’s passphrase-derived private key.
Is BIP 38 Passphrase-Protected Private Keys active or supported today?
Its status is Deployed, but the BIP comments discourage new implementation, and password loss or weak entropy can still make funds unrecoverable or stealable.
Why does BIP 38 Passphrase-Protected Private Keys matter?
BIP 38 remains a defined encrypted-key format, but it concentrates recovery in one passphrase, one record and correct legacy software. Treat every 6P string as sensitive, test recovery before funding and prefer maintained deterministic custody for new deployments.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 38 remains a defined encrypted-key format, but it concentrates recovery in one passphrase, one record and correct legacy software. Treat every 6P string as sensitive, test recovery before funding and prefer maintained deterministic custody for new deployments.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
