The seed phrase was supposed to simplify recovery. Instead, it taught people to treat one plaintext object as the wallet, the backup and the single point of failure.
We spent a decade improving the durability of the backup without asking whether we had chosen the right object to back up.
This article began as a voice-dictated reply to someone who made what sounds like a completely reasonable argument:
If an attacker gets my encrypted Bitcoin Core wallet file and the passphrase that unlocks it, I lose my bitcoin. If an attacker gets his BIP39 mnemonic and the passphrase attached to it, he loses his bitcoin. Therefore, the threat model is identical, and the rest is simply personal preference.
At the very end of the failure chain, that is true.
If the attacker obtains everything required to spend, the attacker wins.
But the fact that two systems can reach the same final failure does not make their threat models identical. It tells us nothing about how many ways each system can reach that failure, what each individual backup object gives an attacker, how safely the components can be copied, how easily ordinary people can understand the model, or how the system behaves when someone makes a perfectly normal human mistake.
Those are not secondary details.
They are the security architecture.
And the more I think about this, the more convinced I become that we spent the last decade teaching people a mental model that made Bitcoin self-custody far harder than it needed to be.
Remember the first time you explained a seed phrase
If you have ever orange-pilled a friend, helped a family member buy bitcoin, or walked a complete beginner through self-custody, you probably know this conversation.
First, you show them the wallet.
Then the wallet shows them twelve or twenty-four words.
You explain that those words are extremely important. They must never lose them, because losing them could mean losing the bitcoin. They must never show them to anyone, because anyone who sees them may be able to take the bitcoin. They should not photograph them, type them into a phone, email them to themselves, save them in cloud storage or place them inside an ordinary digital document.
Paper can burn or decay, so perhaps they should engrave the words into steel.
They should probably have more than one backup, because one location can flood, burn or become inaccessible.
But they should not make too many copies, because each additional copy is another place from which the entire wallet can potentially be stolen.
If they want stronger protection, they can add a BIP39 passphrase.
But now they must preserve that too.
They must not store it with the mnemonic. They must not forget it. Their heirs must understand that the mnemonic without the passphrase may lead to a different wallet. A typo in the passphrase does not produce a clear “wrong password” error; it produces another perfectly valid wallet that happens to be empty.
By the end of the explanation, the beginner is no longer looking at a simple way to hold bitcoin.
He is looking at a small object that must survive fire, water, theft, accidental destruction, memory loss, family confusion and his own death, while remaining invisible to every other human being for the rest of his life.
Then we smile and tell him:
Welcome to sovereignty.
I have had some version of this conversation repeatedly, and I suspect many Bitcoiners have too. I have seen the moment when a person understands that one piece of paper may effectively control the savings, and the immediate conclusion is almost always the same:
Bitcoin self-custody must be incredibly difficult.
You must be technically sophisticated.
You must be unusually paranoid.
You must become a security expert before you can safely hold your own money.
For years, I accepted that conclusion too.
Now I think we blamed Bitcoin for complexity that came from the backup architecture we chose.
We came to treat the anxiety produced by the seed model as an unavoidable property of Bitcoin itself.
The key became the vault
BIP39 is not nonsense, and it was not created without a real purpose.
It takes computer-generated entropy, adds a checksum and represents the result as a sequence of words that a human can transcribe. Its own specification presents the mnemonic as a human-readable way to transport computer-generated randomness, and explicitly says that it is not intended as a way to turn a sentence invented by the user into a wallet. That was genuinely useful. It made recovery portable, inspectable and interoperable across implementations.
The problem is what happened to that useful mechanism once it became the dominant mental model for self-custody.
The careful technical description became:
These words are your wallet.
That sentence is easy to remember, but it also concentrates an extraordinary amount of authority in one highly portable, recognizable, human-readable object.
Without an effective independent passphrase, a BIP39 mnemonic is a bearer secret. Someone who copies it does not need to steal the original. The owner receives no notification. There is no rate limit, no tamper alarm and no failed-login counter. The attacker can restore it somewhere else, at another time, using another wallet.
Steel improves durability.
It does not change that authority.
A steel plate may survive a house fire, but it can also be photographed in seconds. It may remain readable for generations, but so will the secret for anyone who finds it. It protects the user from losing the backup by making the backup harder to destroy, while doing nothing to reduce the consequences of somebody else discovering it.
This produces a basic contradiction.
For availability, we want more copies.
For secrecy, we want fewer copies.
Suppose I engrave the same unprotected mnemonic onto three steel plates and place them in three locations. I have improved my protection against fire, flooding and accidental loss. At the same time, I have created three locations from which the complete root secret can be copied.
One side of the system becomes safer as the other side becomes more exposed.
The usual answer is to add a strong BIP39 passphrase.
That can materially improve the setup. I do not deny it. A well-generated passphrase, preserved separately from the mnemonic, can prevent disclosure of the words alone from being sufficient to spend.
But notice what we have done.
We repaired the single-bearer-secret problem by creating a two-component system and telling the user to keep the components separate.
The simple promise of “just preserve these words” has now become:
Preserve the mnemonic, preserve a strong independent passphrase, never colocate them, make both available to your heirs, remember that every passphrase generates a valid wallet, preserve any additional wallet-policy information, and test the complete recovery.
That can be a strong architecture in expert hands.
It is not the simple twelve-word story we use to onboard beginners.
BIP39 also preserves root-secret material, not necessarily the complete wallet context. The mnemonic alone does not describe every script type, derivation structure, account, multisig policy, descriptor or recovery branch that future software may need. For a simple and conventional single-signature wallet, software can often search common paths. As the wallet becomes more complex, “I still have the words” becomes less equivalent to “I have preserved the wallet.”
The Core model finally gave me a simpler explanation
When I recently went back and tested Bitcoin Core as a wallet from beginning to end, something clicked.
Create the wallet.
Encrypt it.
Make a backup.
Restore it.
Construct a PSBT on another machine.
Sign it offline.
The workflow was not perfect, and Core’s interface still needs serious work, but the security model itself was much easier to reason about than I had expected.
The simplest explanation is this:
The encrypted wallet file is the vault.
The passphrase is the key to the vault.
The vault can be copied.
I can keep redundant copies of the encrypted wallet file on different media and in different locations: USB storage, optical media, another drive, another computer or encrypted remote storage, depending on my threat model.
If one copy becomes unreadable, I have others.
If somebody obtains one encrypted wallet backup, he has not automatically obtained spending authority, provided the private keys are protected by strong wallet encryption and the passphrase has enough entropy.
The passphrase is backed up separately. Use KeePassXC on the prepared, trusted computer: six independently generated random words by default, or eight if memorizing two extra words is comfortable for you. It can also have redundant copies, provided they are never stored together with the corresponding wallet backup.
Someone finding only the passphrase cannot reconstruct the wallet.
Someone finding only the encrypted wallet backup cannot unlock the private keys without the passphrase.
The rule becomes:
Keep the vault and the key apart.
That is a security heuristic ordinary people already understand.
Bitcoin Core’s wallet encryption does not make the entire wallet database an opaque blob. Public keys, transactions and some wallet metadata may remain visible, so the backup should still be treated as sensitive. But encrypted private-key material is not equivalent to a plaintext root bearer secret, and the wallet file can preserve substantially more of the actual wallet state than a bare mnemonic does. Bitcoin Core also supports constructing and signing PSBTs, allowing the private-key wallet to remain on a separate offline machine.
The final part is not optional:
Restore it.
A backup that has never been restored is a theory.
I want to periodically load a copy, verify the expected wallet, construct a transaction, inspect it, sign it in the intended environment and make sure the full procedure still works. The goal is not to feel reassured because I own an indestructible object. The goal is to know that I can recover and spend.
Redundancy no longer requires making several immediately spendable copies of the same plaintext secret.
“You were not supposed to do that” is not a security model
Operational security is not separate from wallet design.
The onboarding flow is part of the security architecture because it determines which mistakes normal people are likely to make.
I recently performed a small experiment in a popular desktop wallet. I selected the BIP39 software-wallet path and began entering words manually. I was able to supply a user-chosen mnemonic that the wallet accepted once the checksum was valid.
An experienced Bitcoiner understands that this is not how secure entropy should be created. The ability to enter an existing mnemonic is necessary for restoring a wallet, and I am not presenting that fact as a unique vulnerability in one application.
But a beginner may not understand the distinction between:
“Enter an existing seed for recovery”
and:
“Choose twelve words to create a wallet.”
The BIP39 specification itself says the mnemonic is meant to transport computer-generated randomness, not human-created sentences. Yet an ordinary user can arrive at a valid-looking wallet while bringing weak human entropy into the system at the very first step.
The expert response is obvious:
You were not supposed to do that.
Exactly.
That is the point.
A secure system is not merely one that can be operated safely by someone who already knows every hidden rule. A good onboarding flow should make the safe path obvious and dangerous misunderstandings difficult.
In the Core model, the user does not need to invent the wallet’s root secret. Core generates the keys internally. The human-facing secret is the encryption passphrase, whose job is understandable: it unlocks an existing encrypted wallet.
That does not eliminate user responsibility. The passphrase must still be strong, backed up and kept separate. The computer must still be clean. The binaries should still be verified. The recovery must still be tested.
But the human is no longer invited to touch, transcribe and physically transport the root secret from which the wallet is derived.
That is not a cosmetic UX distinction.
It changes what the user is capable of accidentally exposing.
Security includes what the interface invites a beginner to do, not only what an expert knows he should do.
The recovery phrase became a universal phishing API
Once an entire industry teaches users that recovery means entering a portable set of words, attackers receive a remarkably reusable script:
Your wallet is at risk. Enter your recovery words here.
The branding can change.
The fake application can imitate Trezor, Ledger, Coldcard or another wallet.
The message can arrive by email, text message, support ticket, search advertisement, telephone call or physical letter.
The supposed emergency can be a firmware problem, a database breach, an expiring wallet, an urgent migration, a replacement device or a mandatory security check.
The final instruction remains almost identical.
Enter the words.
Ledger’s 2020 e-commerce breach did not expose private keys, and it should never be described as though it did. It exposed something different: more than one million email addresses and approximately 272,000 detailed records containing names, telephone numbers, postal addresses and order information. That gave attackers a durable list of people who had purchased cryptocurrency-security devices and the language needed to target them convincingly. Later campaigns included extortion, fake support, physical letters and even an official-looking replacement device containing malicious instructions.
The same recovery ritual has been exploited through counterfeit applications. Users have reported losses after entering Trezor recovery phrases into fake applications distributed through official app stores. In April 2026, a counterfeit Ledger application in Apple’s App Store was linked through victim reports and on-chain tracing to at least $9.5 million in losses across more than fifty victims. The genuine hardware did not need to be broken. The attacker only needed the user to transfer the universally portable recovery secret into a counterfeit interface.
Other incidents belong to different failure classes.
The 2026 Coldcard incident was not BIP39 cryptography failing. Coinkite disclosed that affected firmware had generated seeds through a weaker-than-intended deterministic path, and public investigations linked the problem to active real-world theft. An independent strong passphrase could provide an additional barrier, and not every device, firmware version or wallet was affected. The narrower lesson is devastating enough:
A secure element can protect a weak key perfectly.
Air gaps, reputation and secure storage cannot compensate for failed key generation. Updating firmware may repair future generation, but it cannot make an already generated weak wallet stronger.
These incidents do not prove that every hardware wallet is unsafe.
They prove that self-custody is a lifecycle, not a chip.
The system includes entropy generation, firmware, build infrastructure, supply chains, companion applications, transaction construction, recovery, customer records, support channels, inheritance and the user’s own behavior. Protecting the key inside one component is valuable, but it does not make the rest of the system disappear.
The documented record is also not a complete census of every private loss or recovery mistake. That does not give us permission to invent incidents that have not been established. It does mean that public reports should be treated as evidence of known failure classes, not proof that all other failures have been reported.
Standardized recovery made wallets interoperable. It also standardized the instruction attackers need victims to follow.
Hardware isolation is real. It is not the whole wallet.
The strongest argument for a hardware wallet is real and should be stated honestly.
A properly designed hardware wallet can keep private keys isolated from ordinary malware running on an everyday computer.
That matters.
If the comparison is between a hardware wallet and a normal laptop used for browsing, email, downloading applications and opening random files, the hardware wallet has an obvious isolation advantage.
But that is not the comparison I am proposing.
I am comparing a hardware-wallet-centered system with a clean, dedicated generic computer running Linux and Bitcoin Core, kept permanently offline and used only to hold keys and sign PSBTs.
No browser.
No email.
No daily applications.
No connection to the Internet.
No cryptocurrency software ecosystem beyond Bitcoin Core.
That general-purpose computer contains more code and has its own firmware, hardware and supply-chain risks. Linux is not magic. An old ThinkPad is not blessed by cryptography. A badly administered generic computer may absolutely be worse than a well-designed hardware wallet.
The difference is that I can obtain the machine through the enormous ordinary computer market, wipe it, install verified software and repurpose it without creating a Bitcoin-specific customer record or relying on a small specialized signing-device vendor.
A hardware wallet may add a secure element and a smaller purpose-built interface, but the complete system can also add a manufacturer, shipping trail, reseller, authenticity procedure, firmware stack, firmware-signing infrastructure, update mechanism, companion application, support channel and highly recognizable recovery process.
Those are not automatically fatal dependencies.
They are dependencies that must be counted.
A hardware-wallet purchase can identify the customer as someone who probably owns portable digital assets before the device has generated a single key. The hardware wallet itself may be air-gapped. Its customer database, shipping provider and support platform are not.
For a small spending wallet, a phone or lightweight wallet may be entirely appropriate.
For meaningful long-term savings, my priority is different. I want the fewest unnecessary specialized assumptions I can reasonably achieve, and I want to understand the complete path from key generation to inheritance.
That is why “the private key never leaves the device” no longer ends the conversation for me.
The relevant question is whether the whole custody system preserves secrecy, transaction intent, availability and recoverability over its entire life.
Self-custody is not the object in your hand. It is the complete system surrounding it.
Why Electrum made perfect sense in 2011
If the Core model is so coherent, why did so much of the industry move away from using Bitcoin Core as a wallet?
In my view, the largest practical reason is not wallet encryption or backup.
It is full validation.
Bitcoin Core asks the user to obtain and validate the chain. The initial synchronization takes time, bandwidth, processing and storage. Pruning can reduce the long-term storage requirement, but the blocks still need to be validated.
People wanted to start using Bitcoin immediately.
Electrum was created by Thomas Voegtlin in November 2011 and offered a brilliant answer to that problem. Its official description still calls the feature “Instant On”: Electrum is fast because it uses servers that index the Bitcoin blockchain, while the user keeps control of the private keys and verifies transaction history using SPV. Its early slogan captured the value proposition perfectly: the convenience of a web wallet without surrendering the keys to one.
The historical context matters.
In 2011 and 2012, the alternative for a normal user was not always a beautifully configured Bitcoin Core setup. Early custodial services were already showing how badly trusted convenience could fail. MyBitcoin disappeared in 2011 and later claimed a major loss, while Bitcoinica suffered repeated thefts in 2012 before shutting down.
Electrum solved a real problem.
It let the user keep the keys locally while obtaining the blockchain view from servers. It dramatically reduced the time between downloading a wallet and being ready to receive bitcoin.
I am not presenting that as a mistake.
It was a rational and valuable design trade-off.
But it also helped establish an expectation that self-custody should begin instantly. The user should not have to wait, validate the chain or think too deeply about the foundation before receiving an address.
Later hardware wallets and seed-based onboarding pushed that experience even further.
Unbox the device.
Write down the words.
Receive bitcoin.
Done.
That is excellent product onboarding.
It may not be the right philosophy for savings intended to remain secure for several decades.
There is also an important distinction that many people miss:
The offline Bitcoin Core signer does not need a synchronized blockchain to create keys, encrypt the wallet, restore a backup or sign a properly constructed PSBT.
The online machine needs the current chain state to identify spendable outputs, construct the transaction and broadcast it.
That means the full-node cost is paid by the online validation machine, not by every offline signer or every encrypted backup.
Once I understood that separation, the model became much less intimidating.
Electrum solved the waiting problem. The question is whether instant access should remain the governing priority for long-term savings.
The real cost of Core is patience
I think of the initial synchronization like the foundation of a house.
The foundation is not the exciting part.
It takes time. It costs money. Nobody invites friends over to admire concrete while it cures.
But if the house is expected to remain standing for generations, we do not remove half the foundation because we want to use the kitchen this afternoon.
We take the time once because everything else rests on it.
That is increasingly how I see full validation.
For a spending wallet holding a small amount, convenience may deserve priority.
For long-term savings, the time horizon is different.
Bitcoin itself operates on a century-scale monetary schedule. If I am building a custody system intended to protect savings for ten, thirty or fifty years, and perhaps transfer responsibility to my family, spending additional hours or days establishing the foundation does not strike me as excessive.
It strikes me as proportionate.
This also changed how I think about inheritance.
For the first time, I feel that I can explain the basic recovery model to my own parents in language they already understand:
Here is the encrypted wallet backup.
Here is where the strong passphrase is preserved separately.
Here are the written recovery instructions.
You need the vault and the key.
Do not put them together.
Follow the restore procedure that we have already tested.
Inheritance will always involve communication, timing, people and some degree of trust. It is not the same problem as backup, and no file format removes the human part.
But “vault plus separately stored key” is a mental model I can explain.
“Here are twenty-four words, an optional passphrase that creates an entirely different wallet, a derivation convention, a script policy and a device-recovery ritual that may need to be reconstructed decades from now” is much harder.
This is why I am not convinced that Core is realistic only for technically sophisticated people.
The current interface is unfinished from a mainstream UX perspective, especially for watch-only construction, offline signing, descriptors, multisig and more complex Taproot policies.
That is a design problem.
It is not evidence that the underlying security architecture is too complicated.
The real opportunity for the next decade is not to keep making weaker mental models easier to sell.
It is to make the stronger architecture radically easier to use.
For long-term savings, a slower beginning may be the entire point.
What I am actually recommending
I am not saying that every BIP39 setup is weak.
A knowledgeable user can generate strong entropy, use a strong independent passphrase, preserve the required wallet context, keep the components separate and test recovery. That can be a robust custody system.
I am saying that this is not how the dominant beginner story is usually presented.
The industry presents twelve or twenty-four human-readable words as the simple answer, then gradually adds steel, passphrases, multisig, vendor diversification, backup products, recovery services and increasingly elaborate ceremonies to manage the consequences of concentrating so much authority in one portable object.
At some point, it is reasonable to stop asking which product we should add next and ask whether the foundation was right.
The standard is not perfection. The standard is whether each added component removes more risk than it creates, whether I understand the complete system, and whether I can reproduce and test it without depending on a specialized Bitcoin product ecosystem.
Nobody should move meaningful savings into a new architecture merely because he read one article.
Start with a small amount.
Create the encrypted wallet.
Back it up.
Restore it on a clean system.
Verify the expected addresses.
Create a watch-only wallet.
Construct a PSBT.
Inspect the destination and fee on the offline signer.
Sign it.
Broadcast it.
Then repeat the procedure until it is boring.
Self-custody is not the purchase of a box.
It is a competence.
BIP39 made recovery portable, and that was a major contribution. But portability is not automatically security, human readability is not automatically safety, and interoperability is not the same thing as preserving the complete wallet.
We do not need a better way to hide the same plaintext root secret.
We need a better mental model.
The last decade taught people to treat the key as the vault.
The next decade should teach them to separate the two.
Back to first principles.
Back to the actual wallet.
Back to independent validation.
Back to Bitcoin Core.
Separate validation, signing, backup availability and spending authorization instead of concentrating everything in one portable secret.
I am going to keep documenting and testing this workflow openly.
If you try it, please tell me where the experience is confusing, where the documentation is incomplete and where the interface makes a safe process unnecessarily difficult.
Core wallet encryption protects private key material; it does not hide every transaction record, public key or label. Keep the passphrase separately recoverable, make a fresh backup after encryption or relevant wallet changes, and test restoration. An outer encrypted archive adds privacy and another recovery step. Bitcoin Core wallet documentation.
Apply this to your situation
What would a simpler custody setup look like for you?
We can work through your threat model, Bitcoin Core workflow, backup and recovery plan, or the authority your spending policy needs to express.
Book a 15-minute introduction to outline the question and decide whether a longer session would help. If we arrange one, that session is Value for Value: afterwards, you decide what it was worth. No fixed fee or obligation.
Please keep private keys, passphrases, and wallet files out of the booking form.
Value for value
Did this help you?
Everything I publish here is openly available. If this work has been valuable to you, you can return value in whatever amount feels appropriate. Your support helps me keep Bitcoin education, articles, guides and other resources open and freely available to everyone.
