Three Hardware Wallets That Scream Bitcoin. Twenty Backups That Don't.

2-of-3 multisig vs. 2-of-20 singlesig. The economics of Bitcoin self-custody, privacy, and why we've made a simple problem so complicated.

At some point Bitcoin self-custody turned into a hardware shopping hobby.

Buy a hardware wallet. Write down twenty-four words. Hide them somewhere.

Worried about losing the device? Buy another one. Worried about trusting one manufacturer? Buy a third, preferably from someone else.

Now configure 2-of-3 multisig, back up three seeds, preserve your wallet descriptors, keep the firmware updated, and figure out which software will coordinate the whole thing.

Congratulations. You've bought three little electronic billboards advertising that you probably own Bitcoin.

I prefer an ordinary laptop running Bitcoin Core, an encrypted file, and a passphrase.

I can make twenty copies of my recovery material, distribute them across different locations, and need only one encrypted file and one corresponding passphrase to recover my wallet.

Each component can be stored without revealing that it has anything to do with Bitcoin.

If I want another independent component, I add another encryption layer. If I want more redundancy, I make more copies. If I want part of my recovery process located several hours away, I arrange that too.

This is an approach to self-custody built around a simple economic question: how much does it cost me to defend my Bitcoin, and how much would an attacker have to spend to compromise it?

Multisig has a privacy problem built into its purpose

Multisig is designed to distribute spending authority.

In a 2-of-3 wallet, two signatures are required to spend. In 3-of-5, three. In 5-of-10, five.

That makes perfect sense when several independent people need to approve transactions.

But why has it become the default recommendation for someone who simply wants redundant backups of their own Bitcoin?

Multisig participants are supposed to verify what they're signing. They need to understand the spending policy and examine the transactions they're asked to authorize.

In a typical multisig arrangement, signers share a wallet descriptor containing the public keys and rules needed to reconstruct the wallet.

Someone with that complete descriptor can reconstruct the wallet's addresses and examine its transaction history and balances on the blockchain.

That's useful when independent participants are responsible for authorizing spending.

It becomes awkward when privacy is one of your main objectives.

Suppose I give a friend one of my three hardware wallets for safekeeping, along with the recovery information normally needed to restore that signer and its multisig configuration.

My friend can recognize the device. The descriptor identifies the spending policy and potentially reveals the balance being protected.

They don't have enough signatures to steal the Bitcoin, but they may now know exactly what they're helping me secure.

Multisig signers can be configured to reveal less information, and the backup material can be encrypted. Yet the normal arrangement is built around multiple participants independently verifying a common spending policy.

Keeping every participant ignorant of that policy rather defeats the purpose.

Trying to turn a distributed authorization system into an arrangement of anonymous recovery components is an awkward exercise.

The individual signer still needs private, redundant backups.

And the obvious way to protect those backups is encryption.

Which is where I'd rather begin.

My 2-of-20 Bitcoin Core singlesig

I create a wallet using Bitcoin Core on an ordinary offline computer running minimal Debian Stable.

I back up the wallet and encrypt the complete backup with GPG, using a randomly generated passphrase.

Now I have two components.

The first is an encrypted file.

Someone who finds the encrypted file has no idea what's inside. It could be anything. There's simply no way to tell from the encrypted contents.

I can store copies on USB drives, optical media, in the cloud, in bank deposit boxes, or give them to people for safekeeping. Nobody holding a copy needs to know what it contains.

The second component is the passphrase.

I use KeePassXC to generate five random English words and write them on paper.

Someone finds those five words. What are they? Who knows? They're just five random words on a piece of paper. Nothing recognizable, certainly nothing that suggests Bitcoin.

I make ten copies, put each one in an envelope, and store them in different locations or give them to people for safekeeping.

Now I have ten encrypted wallet files and ten passphrase copies, all stored separately.

Twenty backup artifacts.

To recover my wallet, I need any one encrypted file and any one matching passphrase.

I can lose nine copies from either group and still recover everything.

And none of those twenty copies needs a Bitcoin label.

The resulting recovery process is remarkably simple.

Find one encrypted file. Obtain its passphrase. Decrypt it. Restore the wallet in Bitcoin Core.

I can explain that to anyone who has used a computer.

Three friends holding backups shouldn't become a spending committee

Suppose I have three friends I trust.

I'd like each of them to safeguard one copy of my recovery material.

With my approach, I can give each friend an identical copy of the same five-word passphrase.

None of them needs to know what the words are for.

Now suppose all three friends meet, open their envelopes and compare the contents.

What have they accomplished?

They've discovered that they're holding three copies of the same five words.

Putting those copies together gives them nothing they didn't already have individually.

They still don't possess the encrypted wallet file.

Three identical passwords don't magically become three different keys.

Now imagine I've given these friends three fully usable signers from the same 2-of-3 multisig wallet.

The trust assumptions are completely different.

Any two friends who cooperate can authorize a transaction without me.

If they have the wallet descriptor, they can also inspect the balance and the spending policy.

Suddenly, storing my recovery material has turned into a question about relationships between several people.

Do they know each other? Do they know that they're holding separate signers for the same wallet? Can they communicate? What happens if their incentives change?

I've introduced collusion risk into an arrangement whose original purpose was simply protecting backups from loss.

With layered encryption, I can give ten people ten copies of the same credential without turning them into a signing committee.

They cannot gain additional spending authority merely by combining identical copies.

My friends can help me preserve access to the wallet without becoming participants in its spending policy.

I'd rather trust someone to safeguard an envelope than make that person one of the people authorized to spend my Bitcoin.

Want another component several hours away? Add another encryption layer.

Now suppose physical coercion is part of my threat model.

Someone might confront me and demand that I unlock my Bitcoin.

I'd like to arrange things so that I genuinely cannot assemble the wallet immediately.

Perhaps one essential recovery component should be several hours away.

I don't need another hardware wallet for that.

I take my existing GPG-encrypted backup and encrypt it again with GPG, using a second independent passphrase.

Now recovery requires three components: the twice-encrypted file and both passphrases.

I can keep the encrypted file and first passphrase nearby while storing every copy of the second passphrase several hours away.

I deliberately don't memorize that second passphrase or keep it on my phone. My working signer is also secured so it doesn't provide an immediate alternative way to spend.

I now have a genuine logistical barrier between myself and full wallet access.

Or I can reverse the arrangement.

I can keep the passphrases nearby and store the encrypted file remotely.

I can distribute all three components across different cities or countries.

I decide how many components are required and how far apart they must be.

Now suppose I make ten copies of each.

Thirty backup artifacts, with one copy from each group required for recovery.

Bitcoin Core itself also supports wallet encryption, which can protect the private keys inside the wallet with another independent passphrase.

And I can add more external encryption layers if my circumstances justify them.

Think of a vault with several doors.

Every door has its own key. I can make redundant copies of those keys and place them wherever I choose.

The model scales surprisingly far.

At its simplest, it's one encrypted file and one passphrase, perhaps with a few copies stored nearby.

A family might prefer three independent components distributed among several locations.

At the opposite extreme, imagine fifty consecutive encryption layers, each with a different credential.

You'd have fifty passphrases and one final encrypted file.

Make ten copies of each component and you have 510 backup artifacts.

You could distribute them across six inhabited continents, with recovery requiring one copy from every group and fifty successive decryptions.

I'd hate to organize that recovery drill, but the underlying architecture hasn't changed.

The number of required components, the redundancy of those components, and the geographical separation between them are all under my control.

I don't need to change the Bitcoin spending policy every time I decide to add another door to the vault.

The economics of brute force: a five-word passphrase can mean hundreds of billions of dollars

Security has an economic price.

KeePassXC can generate random passphrases using the EFF wordlist, containing 7,776 possible words.

Four randomly selected words give approximately 3.66 quadrillion combinations.

Five give roughly 28.4 quintillion.

Six give approximately 221 sextillion.

Every additional random word multiplies the number of possible combinations by 7,776.

Let's translate that into dollars.

Published Hashcat benchmarks show an NVIDIA RTX 4090 processing roughly 30,000 to 33,000 guesses per second against Bitcoin Core's native wallet encryption.

For a comparison, we can also model a GPG AES-256 file using SHA-512 and a high S2K count, around 65 million bytes, at an illustrative 15,000 guesses per second per GPU.

Suppose an attacker rents 10,000 RTX 4090 GPUs at $0.89 per GPU-hour.

Here's the time and rental cost required to exhaust the complete search space under those assumptions.

These are full-search calculations. A successful search takes roughly half that effort on average. Actual costs depend on the encryption settings and available hardware; the GPG column is a modeled high-iteration configuration.

But consider the relationship between the cost of attack and defense.

I can generate a five-word passphrase in seconds.

In this model, the computing resources needed to exhaust its search space cost hundreds of billions of dollars.

And an attacker finding my encrypted backup doesn't even know that the passphrase has five words.

Perhaps it has six. Perhaps eight.

They don't know whether the file contains Bitcoin. They don't know its value. They don't know whether decrypting it would simply reveal another encrypted file protected by another independent passphrase.

Even a technically capable attacker has to decide whether the potential reward justifies the cost.

My cost of adding another random word is negligible. The search space becomes 7,776 times larger.

Another encryption layer costs me practically nothing to create. An attacker who breaks the first layer may still have more work to do.

And making ten redundant copies of a credential costs almost nothing compared with the amount of redundancy I gain.

This is how I want to think about Bitcoin security.

I know exactly what I'm protecting and how the recovery components fit together.

The attacker starts with very little information.

The resulting economic asymmetry is much more interesting to me than the number of expensive signing devices I can collect.

The hardware-wallet industry has become a honeypot industry

The hardware-wallet industry has spent years explaining why specialized devices are the safest place for Bitcoin private keys.

Since July 2026, we've had an impressive demonstration of how many different things can go wrong.

Coldcard suffered a seed-generation flaw connected to approximately $116 million in stolen Bitcoin. A firmware defect weakened the randomness of certain wallets, allowing attackers to reconstruct private keys without physically accessing the devices.

BitBox patched severe firmware vulnerabilities.

Trezor had customer information exposed through its shipping provider, affecting 80,689 people. Another breach involving its email provider exposed 347,149 newsletter contacts and enabled targeted phishing.

SafePal disclosed a vulnerability affecting 39,798 customer records.

Then came the physical implants.

Ledger confirmed that genuine devices sold through the CryptoBilis reseller had been modified with unauthorized hardware designed to capture recovery words during setup and transmit them over a cellular connection.

The secure element didn't have to fail. Attackers modified the surrounding hardware before it reached the customer.

On October 30, Trezor warned customers about a credible report of a similar implant in a Safe 5 sold through the same reseller. The reported device had not yet been physically examined by Trezor.

Keystone suffered a breach that exposed customer information and its WebAuth authentication key. The compromise created the possibility of counterfeit devices passing the manufacturer's own authenticity checks. Keystone announced plans to destroy 18,835 devices from the affected inventory.

Foundation, the manufacturer of the Passport wallet, experienced a compromise of backend infrastructure that enabled phishing messages to appear as though they came from official company domains.

Different incidents, different attack methods.

Some affected private-key security. Others exposed customers, authentication systems or distribution channels.

But consider the information being accumulated around these products.

Names, home addresses, email addresses, phone numbers and purchase histories can identify people who have bought specialized equipment for securing valuable assets.

A person who has purchased a Bitcoin hardware wallet has already told someone what type of asset they probably care about protecting.

And the resulting customer databases can become targets in their own right.

Apparently, after spending hundreds of dollars on devices designed to protect private keys, the customer now needs to worry about the security of the manufacturer's shipping provider.

I would prefer not to create that dependency.

The biggest honeypots are custodians and exchanges

The same economic logic applies to centralized custodians.

Whenever someone points out a potential difficulty with self-custody, the industry has another familiar suggestion: let a professional hold your Bitcoin.

But professional custodians can be compromised too.

Mt. Gox collapsed in 2014 after the loss of hundreds of thousands of Bitcoin.

Coincheck lost approximately $530 million in 2018.

In February 2025, attackers stole around $1.5 billion from Bybit. The FBI attributed the theft to North Korea.

The compromise involved the signing workflow around a large pool of assets, illustrating how attackers can exploit the software and people surrounding an authorization system.

Then came the October 2026 Binance incident.

Binance reported approximately $6.3 billion in unauthorized withdrawals. Its preliminary investigation pointed to a compromised DevOps engineer's laptop that may have allowed attackers to access internal infrastructure and submit unauthorized transactions.

The exchange reported no evidence that wallet private keys had leaked. About $3 billion of the affected assets had been frozen by October 30.

An attacker may not need to extract private keys if they can compromise the systems that instruct legitimate signing infrastructure to authorize transactions.

And centralized custody isn't limited to exchanges.

On September 6, attackers exploited a validation bug in Elements, the software underlying Blockstream's Liquid Network.

They created approximately 4,000 unbacked L-BTC and used the network's peg-out mechanism to withdraw roughly 4,000 actual BTC from the federation reserves.

Around 3,400 BTC was subsequently returned.

Blockstream also manufactures the Jade hardware wallet. The Liquid exploit wasn't a Jade vulnerability, but it demonstrated how a concentrated pool of Bitcoin can become vulnerable through other software and operational dependencies in the surrounding ecosystem.

None of these attacks required defeating Bitcoin's underlying cryptography.

The attackers identified economically attractive targets and found exploitable paths through their infrastructure.

Large custodians can invest enormous amounts in security. They can employ specialists, develop sophisticated procedures and maintain expensive systems.

They also hold enormous amounts of value.

An attacker may find it economically reasonable to spend millions of dollars developing an attack against an institution controlling billions.

And cryptocurrency theft has already created well-funded attackers with the resources to invest in future operations.

This is a contest between the cost of defense and the expected reward from attack.

A large centralized honeypot creates a large potential reward.

An individual or family operating a private Bitcoin Core wallet presents a different economic calculation.

They can adopt the same underlying security principles used by professional operators, without concentrating billions of dollars on one operational platform.

Generic computers. Linux. Bitcoin Core. Offline signing. Encrypted backups. Carefully separated credentials.

The same engineering disciplines, adapted to an individual's circumstances.

There's no need to make the system more complicated than the risk requires.

Your privacy can leak before anyone touches your keys

Hardware-wallet software introduces another set of privacy questions.

A surprising number of people use wallets through coordinator applications connected to public servers or third-party infrastructure.

Those services may learn which wallet addresses or transactions the user is interested in. Depending on the setup, they can also observe IP addresses and related network information.

If those records are compromised, attackers may be able to correlate Bitcoin activity with information about the person using the software.

Now combine that with a leaked hardware-wallet customer database containing names, emails and shipping addresses.

Or with information obtained from an internet provider or another compromised service.

The attacker can begin assembling a picture of who owns what, where they live and which Bitcoin transactions may belong to them.

These are exactly the kinds of information leaks that make targeted attacks economically attractive.

And now consider what AI does to the cost of exploiting those records.

Cybersecurity researchers are already documenting increasingly automated attacks that use AI agents for reconnaissance, phishing and credential theft.

An attacker can use stolen customer information to create individualized messages, impersonate support personnel, and run many social-engineering conversations at once.

The old phishing email written in broken English is becoming a historical curiosity.

When attackers can automate research, personalization and impersonation, a leaked list of cryptocurrency customers becomes considerably more useful.

I'd rather avoid being on that list.

Running my own Bitcoin Core node also removes the need to send my wallet's address queries to a public third-party wallet server.

My node validates transactions independently and keeps the wallet information under my control.

The objective is straightforward: minimize how much information about my Bitcoin reaches people who don't need it.

Bitcoin Core has a different economic security advantage

Bitcoin Core occupies a very different place in the Bitcoin economy from an individual hardware-wallet vendor.

It's one of the principal implementations of Bitcoin's validation software.

Exchanges, miners, infrastructure operators, businesses and individual Bitcoiners all depend directly or indirectly on software that correctly enforces the network's rules.

Bitcoin Core's history goes back to 2009. Its code has accumulated years of public review, testing, bug fixes and real-world use.

Anyone can inspect it, build it, test it and propose improvements.

And the economic incentive to identify vulnerabilities is enormous.

Consider what happened in October 2026.

Project Loupe, an AI-assisted security research initiative at Block-backed Spiral, discovered a vulnerability in Bitcoin Core's network handling.

The bug could allow a malicious connected peer to crash certain Windows, macOS and BSD nodes by exhausting their memory.

Linux nodes were unaffected.

It was a node-availability problem rather than a way to steal wallet funds.

Gregory Sanders verified the finding. Antoine Poinsot prepared the fix, which was merged on October 26. Bitcoin Core 31.2 and 32.1 shipped with the patch the following day.

Four days after the automated scan discovered the problem, patched releases were already available.

That tells me something about the economic resources supporting Bitcoin Core.

An organization funds automated security research. Independent developers validate findings. Maintainers review and repair the code. The improvements become available to everyone.

The benefit extends well beyond the customers of a particular manufacturer.

Bitcoin Core has an unusually mature codebase, an enormous accumulated history of public scrutiny, and many participants with direct financial reasons to want it working correctly.

And anyone can use the finished software for free.

On an ordinary computer.

Your grandmother doesn't need to become a full-time phishing analyst

Bitcoin Core 32.1 arrived on October 27 with performance improvements that can make blockchain synchronization faster.

It also added something I've wanted in the graphical interface for years: Export Watch-Only Wallet.

That makes my preferred two-computer setup much easier.

One ordinary computer runs Bitcoin Core online. It independently verifies the blockchain, tracks the wallet and prepares transactions.

Another computer stays offline and holds the private keys.

You create the wallet on the offline computer, then export a watch-only copy through Bitcoin Core's graphical interface and transfer it to your online node.

The online wallet can see your addresses and balance but cannot sign transactions.

When you want to send Bitcoin, the online node prepares a PSBT, a Partially Signed Bitcoin Transaction.

You transfer that transaction to the offline computer using removable media, inspect it, sign it, and return the signed transaction for broadcast.

The normal wallet export, restoration and PSBT workflow can now be handled through Bitcoin Core's graphical interface without manually typing descriptor-import commands.

And the backup?

It's the same encrypted wallet file we've been discussing.

Think about your grandmother.

If she's ever created a Word document, saved a file, copied photographs onto a USB drive or used a password, she already understands the basic operations behind Bitcoin Core wallet creation and backup.

• Create Wallet is conceptually like creating a document.
• Backup Wallet is like saving a copy of an important file.
• Encrypting the backup means protecting a file with a password.
• Making redundant backups means copying that encrypted file.
• Layered encryption means protecting it again with another independent password.

Computers have supported these ideas for decades.

She doesn't need to begin by learning BIP39 derivation paths, extended public keys, wallet fingerprints, multisig descriptors, firmware compatibility and transaction coordinators.

Nor do I particularly want her spending the next decade years monitoring hardware-wallet security announcements and wondering whether the latest urgent email is genuine.

Imagine she's bought a hardware wallet, and her name, email, phone number and home address later appear in a leaked customer database.

Now consider a future attacker equipped with increasingly capable AI agents that can research victims, impersonate support employees, write convincing personal messages and automate phishing conversations.

Why should she have to deal with that additional exposure simply because she wanted to save in Bitcoin?

And if her shipping address becomes associated with a valuable Bitcoin holding, the concern extends beyond phishing.

The $5 wrench attack becomes more plausible when an attacker knows where a potential target lives.

Trezor itself warned that its 2026 shipping-data breach could increase physical security risks for affected customers.

This is why I care so much about privacy as part of the original custody design.

My grandmother shouldn't have to become a security analyst who constantly evaluates fake firmware alerts, AI-generated support calls, suspicious recovery instructions and possible supply-chain compromises.

She should be able to understand her wallet, operate it on an ordinary computer, and keep private backup components in places of her choosing.

Using generic hardware doesn't place her on a hardware-wallet manufacturer's customer list.

Running her own Bitcoin Core node avoids handing wallet queries to public wallet servers.

Keeping encrypted files and independent passphrases gives her recovery material that doesn't identify the asset being protected.

Those choices remove unnecessary sources of information that attackers would otherwise be happy to exploit.

It seems like a much better starting point than asking her to buy three Bitcoin-branded devices and spend the rest of her life watching for security advisories.

Use Bitcoin spending policies for the problems they were designed to solve

Bitcoin already supports more sophisticated spending rules when they're needed.

• Multisig can determine which combination of signers must authorize a transaction.
• Timelocks can determine when a particular spending path becomes available.
• Taproot and Miniscript provide ways to describe and combine more advanced conditions, with support available in Bitcoin Core.

These tools are useful when the circumstances actually require them.

A company treasury may need several directors to approve spending.

An inheritance arrangement may benefit from a recovery path that becomes available after a specified block height or time.

An institution may have multiple authorization procedures for different circumstances.

Those are genuine reasons to design a more sophisticated Bitcoin spending policy.

But most individuals don't need to begin there.

Their immediate problems are much more ordinary.

• How do I prevent someone from stealing my Bitcoin?
• How do I avoid losing access to it?
• How do I make the backups private?
• How do I recover everything years later?

Bitcoin Core, encrypted backups, independent credentials and redundancy provide a straightforward foundation.

We can add more elaborate spending policies when we can explain exactly what problem they're supposed to solve.

Understanding that distinction makes the entire custody problem easier to reason about.

Bitcoin custody in 2140

Bitcoin has completed four of the thirty-three halvings that will eventually bring the block subsidy to zero.

The fourth occurred in 2024. The final subsidy reduction is expected around 2140.

We're still early in Bitcoin's monetization, and our custody practices are still evolving.

I wonder what the landscape might look like by the time the last satoshi has been mined.

I can imagine a world with far more sovereign individuals, families and businesses holding their own Bitcoin.

Professional custody will probably continue to serve people who want it. But I'd rather see a broad market of smaller, specialized custodians than a handful of enormous institutions controlling most of the supply.

Some services might specialize in storing encrypted backup components without ever receiving complete spending authority.

Others might provide recovery administration, inheritance services or geographically separated storage.

They could apply mature security practices without concentrating every customer's funds inside one giant operational honeypot.

And individuals could use the same fundamental methods at home.

We already know how to encrypt files, separate credentials, maintain redundant backups and perform recovery drills.

Decades of computer security have given us these techniques.

• Bitcoin Core provides the wallet and signing software.
• Linux provides a mature operating system.
• Generic computers provide replaceable hardware.
• GPG and other established tools provide encryption.
• KeePassXC generates independent random passphrases.

And regular recovery drills confirm that the system remains recoverable. I prefer a complete restoration test on another trusted machine at least once a year.

The same model can serve a beginner with one encrypted backup and one passphrase, or a family with several independently protected components stored across multiple locations.

A larger institution can scale the architecture further and introduce additional signing authorities where its governance requires them.

The essential building blocks remain understandable.

That's what I'd like people to learn first.

Bitcoin self-custody is entirely achievable without turning your life into a hardware-wallet compatibility project.

We don't have to start with the industry's favorite collection of devices, seed phrases and fashionable multisig configurations.

We can begin with security principles that were well understood long before Bitcoin existed.

A generic computer. Linux. Bitcoin Core.

Encryption, independent credentials, redundant backups and regular recovery tests.

The software has been here since the beginning of Bitcoin. The underlying cybersecurity concepts have been around much longer.

Perhaps the next major improvement in self-custody won't come from another signing gadget, a new proprietary recovery scheme or another influencer explaining which three devices you should buy.

Perhaps we'll simply return to the fundamentals.

Make Bitcoin expensive to attack and cheap to defend.

That's a rather better objective than seeing how many hardware wallets we can fit into a backup policy.