Bitcoin Self-Custody Got Weird. It’s Time to Simplify It.
How hardware wallets, BIP39 ceremonies and fragmented security stacks became the default — and why Bitcoin Core on generic hardware deserves another look.
How hardware wallets, BIP39 ceremonies and fragmented security stacks became the default — and why Bitcoin Core on generic hardware deserves another look.
For more than a decade, Bitcoin self-custody has been moving in one direction:
Buy a specialized device.
Generate 12 or 24 words.
Write them on paper or steel.
Learn derivation paths.
Learn fingerprints.
Learn coordinator exports.
Learn firmware updates.
Learn which wallet supports which hardware wallet.
Learn which version of which standard works with which other implementation.
Then, if something goes wrong, learn another ceremony for recovery.
Somewhere along the way we should probably ask a very simple question:
Did we actually make Bitcoin custody simpler and safer?
Or did we build an entire industry around compensating for complexity that we introduced ourselves?
I’ve spent the last few weeks arguing about this with hardware-wallet developers, wallet developers and Bitcoiners on X.
And the more I dig into it, the more convinced I become that we may have taken a very long detour.
How much of the self-custody stack do we actually need?
Then Coldcard happened.
In July, a seed-generation flaw that had existed in affected Coldcard firmware since 2021 was exploited.
The problem wasn’t Bitcoin.
The attacker didn’t need to steal the devices.
The attacker didn’t need to compromise an air gap.
The problem was much simpler and much worse:
the wallets had generated weak secrets.
Coinkite itself now describes the incident as a firmware bug that weakened seed generation. Subsequent chain analysis reported roughly 1,816 BTC across more than 5,200 addresses swept during the attack waves. (COINKITE Blog)
The bug had survived for years in publicly inspectable firmware. (Source and licensing)
That sentence should permanently change the way Bitcoiners use the phrase:
“But it’s open source.”
Open source is enormously valuable.
But open source does not mean reviewed.
And reviewed does not mean reviewed by people with sufficient motivation, context and time to find the bug that matters.
That distinction is now impossible to ignore.
The attacker may be the most motivated reviewer in the room.
@jackmallers made essentially this point recently.
In his new @BTCsessions interview, the discussion around open-source security starts at about 57 minutes.
Then, around 1:02:04, he says something remarkably simple:
“Just use Bitcoin Core.”
His example is basically: go buy an ordinary laptop and use Bitcoin Core rather than assuming that a Bitcoin-specific device must inherently be safer.
His reasoning is more interesting than the recommendation itself.
Bitcoin Core has something a small security product cannot manufacture:
an enormous accumulated economic incentive to review it.
That deserves much more attention.
Shared software lets security review compound. Every separate stack needs its own review.
Security has economies of scale.
Imagine Strike finds a bug in Bitcoin Core.
Coinbase benefits.
A miner benefits.
A custodian benefits.
I benefit.
You benefit.
Even Strike’s competitors benefit.
Nobody has to rebuild the security work from zero.
The next reviewer starts on top of everything reviewed before them.
This is a profoundly unusual incentive structure.
Bitcoin Core is depended upon by an enormous range of economically motivated actors. That gives those actors a shared interest in keeping the same underlying implementation correct.
The marginal review dollar compounds.
The marginal engineering hour compounds.
The marginal bug report compounds.
That does not make Bitcoin Core bug-free.
Nothing is.
But it creates a very different security economy.
Now compare that with an ecosystem containing dozens of hardware devices, firmware implementations, secure elements, companion apps, coordinators, update mechanisms, seed implementations and vendor-specific features.
Each additional stack needs its own review.
And every hardware manufacturer has a perfectly rational commercial incentive to differentiate its product from its competitors.
Security review fragments.
That is the opposite of compounding.
And then there is targetedness.
This is the part of the hardware-wallet threat model I think Bitcoiners systematically underestimate.
Suppose I order:
BITCOIN ULTRA SECURE SIGNING DEVICE™
The manufacturer knows what it is for.
The distributor knows what it is for.
Potentially the fulfillment company knows what it is for.
Anyone compromising that supply chain knows exactly what type of asset the device is likely to protect.
Now compare that with buying a random used ThinkPad.
There are millions upon millions of generic laptops in the world.
They belong to students, accountants, mechanics, schools, offices, grandmothers, programmers and dentists.
Nothing about the hardware tells anyone:
“This machine will protect Bitcoin.”
That enormous heterogeneous commodity market becomes a kind of hardware anonymity set.
Then I specialize the machine.
Not the manufacturer.
Not the distributor.
Me.
Buy an ordinary computer. Decide what it protects after it reaches your hands.
“But a generic laptop has Wi-Fi.”
So remove networking.
This is where I think people sometimes confuse generic hardware with generic configuration.
Debian + Bitcoin Core + the minimum required to operate the machine.
No browser.
No email client.
No LibreOffice.
No random desktop applications.
No networking in the signer configuration.
It can run stateless from a USB image in RAM.
Boot it.
Create or load a Core wallet.
Sign a PSBT.
Shut it down.
In a live session without configured persistence, the working wallet must be backed up to separate storage before shutdown. The release instructions will specify what persists in each boot and installation mode.
You can also install the same environment permanently onto an old laptop and effectively turn that commodity machine into a Bitcoin signing appliance.
If your threat model is sufficiently extreme, physically remove the Wi-Fi/Bluetooth hardware too.
But now notice what happened:
generic hardware became specialized hardware — after I bought it.
That distinction matters.
“But USB is an attack surface.”
Yes.
Everything is an attack surface.
QR parsers are attack surfaces.
Cameras are attack surfaces.
SD cards are attack surfaces.
USB stacks are attack surfaces.
Firmware update parsers are attack surfaces.
Your coordinator is an attack surface.
The question is never:
“Does this have an attack surface?”
The useful question is:
“What additional complexity am I introducing, and what threat am I buying that complexity to defend against?”
For most people I would rather start with the smallest understandable system and add complexity only when their actual threat model demands it.
If USB transport genuinely bothers you, harden the transport.
Use dedicated media.
Use hardware write protection.
For some extremely rare, extremely high-value movement, you could even use write-once optical media.
The point is not that one transport is magically perfect.
The point is that security architecture should be modular instead of ceremonial.
Then we arrived at dice.
This may be my favorite example of where Bitcoin custody culture has ended up.
After Coldcard, people understandably became nervous about entropy.
So now we have people sitting at tables rolling physical dice to generate Bitcoin secrets.
I understand the logic.
I just think we should zoom out for a second.
Bitcoin Core already has mature cryptographic randomness infrastructure. GetStrongRandBytes() incorporates operating-system entropy and is designed to fail if OS randomness cannot be obtained. Core key generation uses that strong RNG path. (GitHub)
Modern operating systems rely on CSPRNGs for security-critical randomness constantly.
Passwords.
Keys.
TLS.
Disk encryption.
Authentication.
Yet somehow, once Bitcoin enters the room, otherwise rational computer users become convinced that perhaps what the computer really needs is:
me, 256 coin flips and a worksheet.
You certainly can do it.
It is educational.
It might even be fun.
But I don’t think that should be the destination of mainstream self-custody.
More ceremony does not automatically mean better randomness.
BIP39 (kind of) solved a problem.
That doesn’t mean it should define Bitcoin custody forever.
Twelve or twenty-four words feel normal to Bitcoiners because we have spent years around them.
Step outside the bubble.
Imagine explaining self-custody to an otherwise competent 65-year-old business owner.
He knows how files work.
He knows what encryption means.
He understands making three backups.
He understands keeping copies in different locations.
He understands restoring a file.
Then tell him:
Here is an encrypted wallet.dat.
This file contains the wallet material you need.
We make redundant encrypted backups.
We separate the encryption secret.
Once a year we restore the wallet on a clean machine and prove the recovery procedure still works.
That mental model looks remarkably similar to normal computing.
Now explain seed words, BIP39 passphrases, derivation paths, account fingerprints, descriptor origins, compatibility between wallets, coordinator files and which parts of the wallet the seed does and does not reconstruct.
Which model is inherently more intuitive?
I think Bitcoiners have been inside the current paradigm so long that we no longer notice how strange it looks from outside.
And no, this does not mean everyone should keep their life savings on their daily laptop.
Quite the opposite.
Dedicated is the important word.
For a straightforward threat model:
generic dedicated computer
clean Linux
Bitcoin Core
For stronger isolation:
online Bitcoin Core node
offline Bitcoin Core signer
PSBT
The online machine has public wallet information and constructs transactions.
The offline machine owns the private keys and signs them.
Private keys never need to touch the online machine.
That is a remarkably simple security architecture.
And for single-sig, most of the ordinary wallet workflow is already available through Bitcoin Core’s GUI.
The CLI becomes necessary mainly when you want more advanced construction.
Multisig.
Descriptors.
Miniscript.
Timelocks.
Taproot policy trees.
Which brings us to the next part.
Bitcoin Core doesn’t necessarily need to become everything.
Its interfaces can become better.
For the last few months I’ve been building Core Explorer.
The idea is not to build another wallet.
It is to make the capabilities already available through Bitcoin Core understandable visually.
Imagine the good multisig workflow of Sparrow.
Recovery paths like Liana.
More advanced Miniscript and Taproot policies.
PSBT coordination.
But instead of introducing another key-management implementation underneath it, the GUI speaks to Bitcoin Core.
Core handles keys.
Core handles signing.
Core handles descriptors.
Core handles PSBTs.
The interface translates human intent into Core operations.
And yes — that interface itself becomes security-sensitive.
If a GUI incorrectly translates:
“Alice OR Bob after one year”
into the wrong policy, it does not matter that the cryptography underneath was perfect.
That translation layer needs tests and adversarial review too.
But this suggests a much healthier architecture:
put cryptography and key management in the most reviewed layer you have, and make everything above it as thin, inspectable and replaceable as possible.
Core handles keys and signing. A thin, replaceable interface translates human intent into Core operations.
AI changes this equation too.
Ten years ago, telling a normal person to install Linux and learn a few commands was a real usability obstacle.
Today?
Paste the error into an AI.
Ask what the command does.
Ask it to explain every flag.
Ask it to inspect a configuration.
Ask it to teach you Linux interactively.
The cost of understanding computers has collapsed.
The cost of producing interfaces has collapsed too.
A small project can now prototype UX that previously required a funded software company.
That does introduce new risks — especially people shipping AI-generated code they do not understand.
But it also destroys one of the strongest historical arguments for vertically integrated hardware-wallet ecosystems:
“Normal people need us to package all of this for them.”
Maybe they did.
Maybe increasingly they won’t.
I think Jack Mallers is noticing the same transition.
What caught my attention in his latest interview was not merely that he recommended Bitcoin Core.
It was why.
His argument was essentially economic.
A tiny open-source repository can be public while still having relatively few economically motivated defenders.
Meanwhile an attacker may have an enormous financial incentive to find the one bug everyone else missed.
Bitcoin Core is different because so much of the Bitcoin economy already depends on it.
That creates scale.
That creates network effects around review.
And that creates something no “open source” badge alone can provide:
continuous economic demand for correctness.
This is the security property I think deserves far more attention after Coldcard.
The future of Bitcoin self-custody may look strangely boring.
No exotic device.
No Bitcoin-branded package arriving at your house.
No mandatory twelve-word initiation ceremony.
No proprietary ecosystem.
Maybe just:
An ordinary computer.
A minimal operating system.
Bitcoin Core.
A wallet file.
Good encryption.
Redundant backups.
A recovery drill.
And, when appropriate, another ordinary computer kept offline for signing.
That sounds less futuristic than a tiny signing gadget with secure elements, QR scanners and a dozen recovery standards.
Good.
Security should probably be boring.
An ordinary computer. Minimal Linux. Bitcoin Core. Encrypted backups. A recovery procedure you have actually tested.
Maybe we optimized the wrong variable.
For years the self-custody conversation has often been:
Which hardware wallet?
Which secure element?
Which seed storage plate?
Which multisig coordinator?
Which air gap?
Which entropy ceremony?
I increasingly think the better question is:
How much of this stack can I delete?
And underneath whatever remains:
Can Bitcoin Core do it instead?
Coldcard didn’t teach me that hardware wallets are evil.
It taught me something more interesting:
specialization is not automatically security.
Open source is not automatically review.
Air-gapped is not automatically safe.
DIY is not automatically untargeted.
More entropy ceremony is not automatically better randomness.
And more features are definitely not automatically more security.
Maybe the next era of Bitcoin self-custody is not about inventing another device.
Maybe it is about finally taking the software that already secures Bitcoin seriously as wallet infrastructure.
Generic hardware. Minimal Linux. Bitcoin Core. Everything else has to justify its existence.
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.
