The Hardware Wallet Detour

How Bitcoiners Turned a Simple Security Problem Into a Security Ritual

Bitcoiners made self-custody much more complicated than it needed to be.

The original problem was real, but extremely simple:

People were using Bitcoin wallets on computers that could be compromised.

Your daily laptop might contain hundreds of applications, browser extensions, email attachments, proprietary software, old packages, random downloads, and possibly malware.

Of course that is not the ideal environment in which to generate and protect Bitcoin private keys.

But notice what the actual problem was.

The problem was not:

General-purpose computers cannot securely hold Bitcoin keys.

The problem was:

You are using Bitcoin on an unsafe computer.

The obvious first-principles solution should therefore have been equally simple.

Take another computer.

Wipe it.

Install a clean operating system.

Install Bitcoin Core.

Dedicate that machine to Bitcoin.

If your threat model requires stronger isolation, keep the signing machine offline and move PSBTs between the online coordinator and offline signer.

Problem solved.

Instead, many Bitcoiners took a very different path.

The detour begins

In 2014, Trezor launched what it describes as the world's first hardware wallet. Two of Trezor's founders, Marek Palatinus and Pavol Rusnak, were also among the authors of BIP39, proposed in 2013 as a standardized human-readable mnemonic representation for deterministic-wallet entropy. (Trezor)

The hardware-wallet model made intuitive sense at first.

If the host computer might be compromised, put the keys into a little dedicated computer and sign somewhere else.

But that architectural choice also created another problem.

You no longer had a normal Bitcoin Core wallet environment where the complete wallet could simply be treated as a wallet artifact.

So the industry increasingly normalized another mental model:

Export the root secret and make the human responsible for preserving it.

And that was the beginning of a very long detour.

Imagine if Excel worked like BIP39

The absurdity becomes much easier to see if you apply the same philosophy to normal computing.

Imagine you're working on an important encrypted Excel spreadsheet.

Today the mental model is completely obvious.

You finish your work.

You click:

File → Save

If the file is sensitive, you encrypt it.

If you want another copy, you back it up.

Years later, you open Excel and click:

File → Open

Nobody thinks this is remarkable.

Now imagine Microsoft introduced the Bitcoin Hardware Wallet School of File Management™.

You finish your spreadsheet and click Save.

Excel responds:

Great. Instead of actually preserving your workbook, here are 24 words representing the master entropy from which part of the workbook can theoretically be reconstructed.

Please engrave them into steel.

But wait.

Those words are not actually the spreadsheet.

So please also record:

• which workbook schema you were using,
• which spreadsheet format was active,
• which version of Excel created it,
• how worksheets and relationships were structured,
• whether macros existed,
• which formula-engine behavior was expected,
• which metadata another application would require,
• and perhaps export a chunk of XML describing enough of the workbook structure that another implementation might reconstruct it later.

Maybe also open Excel's source code, locate whichever serialization rules your particular workbook depended upon, print the relevant section and store it next to your steel plate.

For additional security, you can add another secret to your 24 words.

Except it doesn't encrypt the 24 words.

Instead it deterministically produces an entirely different workbook.

Every possible passphrase produces a valid workbook.

Please make sure you remember which one was yours.

Twenty years later, your children can enjoy reconstructing the spreadsheet.

And computer-security people would proudly tell you:

“See how simple this is? You only need 24 words.”

Nobody would accept this for Excel.

They would ask:

Why can't I just save the damn file?

Exactly.

Bitcoin Core already has the sane mental model

Bitcoin Core's model is conceptually boring.

That is a feature.

You have a wallet.

You encrypt the wallet.

You back up the wallet.

You restore the wallet.

The backup can preserve the wallet data as a coherent artifact rather than forcing the user to reduce the entire object to one naked human-readable root secret.

And critically, the user-facing backup primitive does not need to become more complicated as the wallet becomes more sophisticated.

A simple wallet?

Backup Wallet.

A wallet containing imported descriptors or more sophisticated policy information?

The desired abstraction remains:

Backup Wallet.

Later:

Restore Wallet.

The complexity belongs inside the software.

Not inside the user's head.

A better wallet becoming more sophisticated should not mean that inheritance and recovery become more sophisticated too.

That is backwards.

BIP39 made the user responsible for wallet archaeology

The moment the industry taught users that “the seed phrase is the wallet,” we introduced a conceptual error.

A root secret is not necessarily the entire wallet.

The BIP39 specification itself demonstrates the issue.

A 12-word BIP39 mnemonic represents 128 bits of entropy plus a 4-bit checksum. A 24-word mnemonic represents 256 bits plus an 8-bit checksum. But those words do not inherently tell future software everything about how the wallet was used. The current BIP39 document itself lists the lack of a versioning scheme as a shortcoming and notes that the mnemonic originally provided no way to determine which address format should be used; descriptors mitigate that problem precisely by preserving more wallet information outside the seed. (GitHub)

That proves the point.

The seed is not the wallet.

Now add multisig.

Add different script types.

Add account structures.

Add timelocks.

Add more sophisticated spending conditions.

Suddenly recovery can become an archaeology exercise:

What wallet software generated this?

Which path?

Which account?

Which descriptor?

Which cosigners?

Which policy?

Which assumptions?

The supposedly universal backup gets less complete precisely as the wallet gets more interesting.

That is an awful abstraction.

Then we patched the patch with a passphrase

There was another obvious problem.

If your 12 or 24 words are the naked master secret, redundancy becomes dangerous.

Put the words in one place and you have a single backup.

Put identical copies in ten places and now you have ten locations containing the complete root secret.

So another ritual became popular:

Add a BIP39 passphrase.

But here again the user's intuitive mental model can be wrong.

The passphrase does not simply encrypt the mnemonic like encrypting a file.

BIP39 uses the mnemonic and "mnemonic" + passphrase through PBKDF2 to derive a seed, and every possible passphrase produces a valid seed. (GitHub)

So now the supposedly elegant “12 words on paper” recovery model may actually mean:

12 or 24 words.

Plus another sufficiently strong passphrase.

Stored separately.

Plus whatever wallet metadata is needed for recovery.

Plus recovery instructions for your heirs.

We solved a backup problem by turning users into part-time cryptographic archivists.

Then came entropy theater

The rituals did not stop there.

After weaknesses in hardware-wallet entropy generation received renewed attention, Bitcoin discussion increasingly shifted toward users manually generating randomness with dice, cards, and elaborate entropy ceremonies.

There is nothing inherently wrong with independently generated randomness.

But the discussion often loses perspective.

Modern operating systems already provide cryptographically secure randomness. Bitcoin Core's strong RNG explicitly incorporates OS entropy such as getrandom() or /dev/urandom, mixes additional sources, and is designed to fail if the OS RNG fails. (GitHub)

We trust operating systems and reviewed cryptographic software to generate high-strength passwords, encryption keys, SSH keys and countless other secrets every day.

Password managers routinely generate cryptographically strong secrets. KeePassXC, for example, provides both random-password and passphrase generation and even supports external EFF-style wordlists. (KeePassXC)

Yet somehow Bitcoin convinced itself that a person rolling physical dice is intrinsically more serious than mature cryptographic software running on a freshly installed dedicated Linux system.

Rolling dice does not eliminate trust.

Eventually those dice results still have to enter hardware, firmware and software and be transformed into Bitcoin private keys.

Bitcoin is software.

Not physical gold.

We also chose a surprisingly inefficient human encoding

BIP39 uses a 2,048-word list.

That gives exactly 11 bits per word.

A 12-word mnemonic therefore contains 128 bits of entropy plus its checksum. (GitHub)

Compare that with an EFF-style Diceware list containing 7,776 words.

Each independently selected word carries about 12.9 bits of entropy.

So roughly ten truly random words from a 7,776-word list already reach approximately 129 bits.

In other words, if humans really need to remember or separately store a strong passphrase, there are already mature password-management conventions that can encode comparable strength with fewer words.

The Bitcoin industry did not discover some uniquely optimal human-secret format.

It standardized one format around wallet recovery and then built an enormous ritual culture around it.

Then there is the checksum illusion

People also frequently talk about BIP39's checksum as if it somehow validates the security of the generated secret.

It does not.

The checksum only validates consistency with the mnemonic encoding.

BIP39 takes the generated entropy, appends a short SHA256-derived checksum, and maps the result into words. For 12 words the checksum is only four bits; for 24 words it is eight. (GitHub)

If the underlying entropy generation procedure was weak, the checksum does not magically make it strong.

A perfectly checksummed mnemonic can still originate from catastrophically weak randomness.

Which brings us to Coldcard.

“But the firmware is public”

One of the standard answers to specialized-device risk is:

“But the firmware is open source.”

Fine.

Publicly inspectable source is clearly preferable to opaque firmware.

Coldcard publishes its firmware source, documents reproducible builds and makes hardware information available for inspection. Its current licensing is better described precisely as source-available/publicly inspectable because it adds the Commons Clause to MIT terms. (Coldcard)

But here is the uncomfortable lesson:

Public code does not review itself.

A Coldcard firmware flaw dating to March 2021 weakened randomness for affected wallets. According to TRM Labs' August 2026 analysis, a build/configuration problem caused affected devices to fall back to weak software randomness rather than the intended hardware entropy source, reducing effective strength on some devices from 128 bits to as little as roughly 40 bits. (TRM Labs)

The flaw survived for about five years.

Then attackers exploited the weak seeds.

By August 5, TRM reported roughly 1,816 BTC, worth around $116 million at the time, drained from more than 5,200 addresses. (TRM Labs)

Stop for a moment and think about what that means.

The firmware was available to inspect.

The product was explicitly marketed as a specialized Bitcoin security device.

Its users performed all the rituals.

Air gaps.

Seed backups.

Dedicated hardware.

Specialized signing.

Yet the catastrophic entropy problem remained in the specialized security stack for years.

Why?

Not because source visibility is useless.

Because source visibility and actual security review are completely different things.

Security is economic

This is the part I think the hardware-wallet conversation misunderstands most deeply.

Software is not secure because someone put the source on GitHub.

Software becomes safer because sufficiently capable people have sufficiently strong incentives to scrutinize it.

Imagine you personally had to secure $1 billion of Bitcoin.

Would spending $100,000 on an independent security review sound expensive?

Of course not.

You might happily spend several hundred thousand dollars.

You would review the signing environment.

You would examine builds.

You would test recovery.

You might audit firmware.

You might audit hardware.

You would model supply chains.

Because the marginal cost of review is tiny relative to the economic value being protected.

But then another economic insight becomes obvious.

You would not want your expensive security review to begin from zero.

You would want to start with software that already had:

years of public scrutiny,

many expert contributors,

many independent reviewers,

large amounts of economic value depending on it,

a mature release process,

and a long adversarial history.

Then your next security dollar compounds all the review that happened before you.

That is the enormous advantage of Bitcoin Core.

The economics of Bitcoin Core are different

Bitcoin Core is not merely another wallet application.

It is the reference implementation used across the Bitcoin ecosystem and has accumulated years of scrutiny from contributors, infrastructure operators, businesses, miners, exchanges and technically sophisticated users.

Its release process goes unusually far into the software-supply-chain problem.

Bitcoin Core's Guix build infrastructure is designed to make releases reproducible and bootstrappable rather than requiring users to blindly trust one person's precompiled binaries. Independent builders can reproduce release binaries and publish signed attestations of the hashes they obtained. (GitHub)

The official Bitcoin Core download documentation describes this explicitly: multiple contributors can independently reproduce identical binaries and cryptographically attest to their checksums. (Bitcoin Core)

That changes the economic structure of trust.

You are not beginning your security analysis with a $200 consumer gadget produced by one company.

You are adding your own verification on top of an enormous pre-existing body of review.

That matters.

Hardware-wallet economics are different

Now compare that with a retail hardware wallet.

A normal customer buys a device for perhaps a few hundred dollars.

They are not going to spend $100,000 independently auditing its firmware.

They are certainly not going to decap chips, inspect silicon, trace the supply chain and independently validate every hardware claim.

They assume someone else did the difficult work.

Maybe someone did.

Maybe several researchers did.

Maybe nobody looked closely enough at precisely the failure that matters to them.

And this creates a strange economic mismatch.

The vendor has a commercial incentive to explain the threats its product solves.

Compromised desktop?

Dangerous.

USB?

Dangerous.

Browser malware?

Dangerous.

Air-gap attack?

Dangerous.

Supply-chain seal?

Use our special packaging.

Entropy?

Perform our special ritual.

And suddenly generic hardware begins to sound impossibly dangerous.

But what receives much less attention are all the attack surfaces that exist because the specialized Bitcoin product now exists.

The targetedness problem

A hardware wallet is not only a security device.

It is information.

Buying one tells someone something economically valuable:

This person probably owns Bitcoin.

The hardware-wallet manufacturer may know.

The payment processor may know.

The fulfillment provider may know.

The shipping company may know.

The email marketing system may know.

Support infrastructure may know.

And when those databases are breached, leaked or abused, the attack does not have to involve cracking a secure element or discovering a zero-day.

In many cases that would be economically stupid.

Why spend millions developing an exploit if you can simply impersonate customer support?

Send a convincing security alert.

Send a fake firmware update.

Tell the target their wallet is compromised.

Ask them to “verify” their backup.

Build trust over weeks.

Run a recovery scam.

Run a SIM attack.

Attempt extortion.

Or, in the worst case, use the shipping address to turn a digital security problem into a physical one.

The hardware wallet can remain cryptographically flawless while its owner becomes dramatically easier to attack.

That is targetedness.

Commodity hardware changes the economics

Now compare that with a used ThinkPad.

There are enormous numbers of generic laptops circulating through a gigantic commodity market.

Nobody looking at Lenovo's customer database knows:

This person bought this laptop specifically to secure Bitcoin.

It might belong to an accountant.

A student.

A developer.

A grandmother.

A warehouse worker.

A dentist.

A Bitcoin holder.

Nobody knows.

Could generic hardware theoretically contain malicious hardware?

Of course.

But security is not about listing theoretically possible attacks.

It is about threat models and economics.

Seeding random commodity laptops at the hardware level in the hope that one of them eventually becomes an offline Bitcoin signer has radically different economics from targeting a known population of specialized devices whose entire purpose is storing valuable cryptographic keys.

And the obvious second-hand software risk is trivial to address.

Wipe the machine.

Install Linux from verified installation media.

Install Bitcoin Core.

Done.

The black-box irony

Hardware wallets were supposed to eliminate trust in general-purpose computers.

Instead, they frequently move trust into a much smaller specialized stack.

Custom hardware.

Custom firmware.

Custom bootloaders.

Secure elements.

Specialized displays.

Firmware-update procedures.

Companion applications.

Manufacturing.

Shipping.

Vendor infrastructure.

Even when schematics are available, independently validating the actual physical device in your hand at chip and supply-chain level is far more expensive than reading source code.

And this brings us straight back to economics.

For a billion-dollar custody operation, perhaps that expense makes sense.

For a retail buyer with $20,000 of Bitcoin?

It obviously does not.

The retail buyer is therefore still trusting.

They have simply been taught to call the trust ceremony “verification.”

Multi-vendor multisig does not magically remove this

The latest version of the ritual often says:

Use multisig with hardware wallets from multiple vendors.

To be clear, multisig can absolutely reduce important classes of risk.

A compromised key does not necessarily compromise the wallet.

One defective device need not destroy security.

Different implementations can reduce correlated failure.

Those are real advantages.

But security has multiple dimensions.

On the targetedness and operational-complexity axis, buying devices from three specialized Bitcoin companies can mean:

three manufacturers,

three customer databases,

three shipping relationships,

three firmware ecosystems,

three update procedures,

three vendor lifetimes,

three sets of recovery assumptions,

and more complexity for whoever inherits the setup.

So you can reduce one risk while increasing another.

The tradeoff needs to be modeled honestly.

If you wanted to manufacture a truly gigantic operational headache for yourself, you could simply buy one device from every hardware-wallet manufacturer in existence.

There is certainly no shortage of them.

You would create a beautiful collection of specialized dependencies while repeatedly telling companies and third parties:

Hello. I own Bitcoin. And apparently enough Bitcoin that I take custody very seriously.

Once you see the targetedness problem, you cannot unsee it.

Complexity is itself a security cost

This is the principle underlying almost everything above.

Every additional component introduces:

another assumption,

another failure mode,

another thing to document,

another thing an heir must understand,

another dependency that must still exist ten years from now,

another opportunity to make a mistake.

Bitcoiners frequently treat complexity as evidence of sophistication.

It is often the opposite.

Real security engineering tries very hard to remove things.

A security system with five moving parts is not automatically better than one with two.

A ritual involving steel plates, dice, multiple vendors, firmware verification, derivation-path documentation, passphrase separation, descriptor backup and inheritance instructions is not automatically safer because it feels serious.

Sometimes you have simply created more ways to fail.

Go back to the original problem

Strip away more than a decade of accumulated hardware-wallet culture and ask the original question again.

I do not want my Bitcoin private keys on my potentially compromised daily computer. What should I do?

My answer is almost embarrassingly simple.

Get another computer.

It does not need to be fancy.

Generic commodity hardware is fine.

A used ThinkPad is fine.

Install a clean, boring Linux distribution such as Debian Stable.

Verify Bitcoin Core.

Generate the wallet there.

Encrypt it.

Back it up.

Test the restore.

Do not use that machine for random daily computing.

If the value and threat model justify stronger isolation, make it an offline signer and move PSBTs between systems.

That solves the actual problem.

And the backup should remain boring

The final irony is that we spent years teaching Bitcoiners elaborate recovery rituals around something computer users already understand perfectly.

Files.

Your wallet should be treated as a coherent artifact.

Encrypt it.

Back it up redundantly.

Keep the encryption secret separate where appropriate.

Periodically test that your backups restore correctly.

The computer industry has spent decades figuring out how to preserve files.

You can copy an encrypted artifact to multiple USB drives.

Optical media.

SSDs.

Remote storage.

Different buildings.

Different jurisdictions.

Whatever redundancy matches your threat model.

Because the file is encrypted, redundancy does not have the same security property as making ten naked copies of the root secret.

And when somebody needs to recover it, the desired user experience should remain:

Restore Wallet.

Not:

“Here are twelve words. Good luck reconstructing what Grandpa was doing in 2034.”

Security should compound, not restart from zero

This is ultimately why I keep coming back to Bitcoin Core.

I want my own security efforts to build on top of the largest possible accumulation of previous security work.

I want boring commodity hardware.

A mature operating system.

A clean dedicated environment.

The most reviewed Bitcoin implementation available to me.

Reproducible builds.

Independent attestations.

A normal encrypted-file backup model.

And as few Bitcoin-specific dependencies as possible.

Then, if the amount of Bitcoin being protected becomes large enough to justify additional independent audits, those marginal security dollars compound an already enormous existing body of work.

That is how security should scale.

Not by inventing another gadget.

Not by adding another ritual.

Not by creating another human-readable master secret.

Not by adding another vendor.

Keep it simple

Hardware wallets began by trying to solve a legitimate problem.

But I think Bitcoin took the wrong architectural lesson from that problem.

The answer to:

“My computer might be compromised.”

did not need to become:

“Let's create an entire specialized hardware industry, export wallet root secrets into human-readable words, and teach users an increasingly elaborate set of security ceremonies.”

It could simply have been:

Don't use the compromised computer.

Use clean dedicated hardware.

Use a mature operating system.

Use Bitcoin Core.

Keep your backups boring.

Test recovery.

And remove everything you do not need.

Generic hardware. Linux. Bitcoin Core.

Everything else should have to justify the additional trust, complexity, targetedness and attack surface it introduces.

Practical context

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.