How should I store my bitcoin?
Over the years, I’ve gotten this question a lot.
As the saying goes, security and usability are often competing interests. How you decide to store your bitcoin is a function of how much you have and how much you value your own time.
Bitcoin makes it possible for everyone to be their own bank, but that doesn’t mean it’s easy.
$1k USD: Use a Trusted Service
Use a trusted and centralized service like Coinbase/Gemini/Xapo. It’s simple to use, and they claim they’ve got your back for all kinds of little mistakes that might cause you to lose money. Be sure to enable 2FA!
- Very easy to use, your parents can probably do it.
- In theory, you (or your heirs) can eventually recover your funds even if you lose everything (email, password, 2FA device, 2FA seed, etc).
- Some exchanges have various licenses and trusts that might come with more stringent security, auditing, and reserve requirements. However, keep in mind those regulations also come with KYC and other privacy/control restrictions that may negatively effect you.
- Fully trusted, there’s no way to know if they’re even solvent now! Customers were still depositing to Mt Gox for a very long time not knowing that they were insolvent. Coinbase/Gemini seems to be run and backed by competent people, but if $1BN disappeared due to loss/theft, even in the best circumstances they wouldn’t be able to make users whole. Note that Xapo customers can check their own balances on the public blockchain, so they have a decent guarantee of their solvency.
- Even if they are solvent today, they could easily take/lose all your funds tomorrow. The incentives for a retirement attack are massive, especially since it’s hard for law enforcement to tell the difference between internal and external theft.
- They may or may not let you keep coins on other forks of bitcoin, and they probably won’t let you claim air-dropped coins (see Stellar and Byteball for recent examples).
- You don’t actually have bitcoin, just an IOU to redeem some bitcoin in the future. They have their own policies and procedures, and you could get frozen out of your funds with little recourse.
- They require a lot of private information about you that makes them a target for privacy breaches like the recent 140+ MM US citizens whose records Equifax failed to secure.
$50k: Use the Breadwallet App
It’s pretty secure, and very easy to use. If you store a lot in here, you should use a dedicated mobile device and not the same phone that you carry around with you 24/7. You can repurpose an old phone and turn it into a dedicated bitcoin wallet!
- Open source, with key generation and transaction signing taking place client-side.
- Standard BIP 32/39/44 implementation. Here’s a script I wrote to recover your breadwallet funds even if they go out of business or your phone dies.
- Easy to backup just your seed once and then transact nearly infinite times (with a new address for each transaction)
- Simple UI that your parents could probably use
- Simple Payment Verification (SPV) clients are great for scale as they validate block headers and your transactions only. Block header disk usage grows at just ~5 MB/year, which is trivial to store. Proof-of-inclusion on a Merkle Tree is very fast with O(log(n)) verification time.
- While not easy, owning your own keys means that you have the ability to not lose coins on other forks as well as sign messages to claim airdropped coins (advanced users only).
- Mobile, easy to take your money with you and spend it on the go.
- SPV clients verify only block headers (which include Proof of Work) and cannot validate that every BTC transaction follows the consensus rules. Because of this, there are some theoretical attacks against them as well as some difficulty being sure you’re on the right chain during a contentious chain split. Since you control your own private keys, the best course of action during times of uncertainty is to just stop transacting and wait until a solution is announced.
- Mobile phones are more secure than general purpose computers, but are still targets for malware.
- It’s hard to verify that the software you’re running is actually what’s on the github repository.
- Managing updates is a security risk. If auto-updating is turned on, you’re one malicious upload to the app store away from running software that steals your private keys. (Of course there are benefits to running the latest software as well).
- Some loss of privacy using SPV. While breadwallet has no centralized account (so no email address, password, etc), it would be possible for an attacker to run an SPV server and use that to try and figure out which addresses are linked. You can prevent this by running your own SPV server, but that is much more complicated.
- Requires buying a dedicated mobile device, though you could use your existing day-to-day mobile phone (for smaller amounts). If you’re going to spend money on a dedicated mobile device, you’re probably better off just buying a hardware wallet!
$250k: Use a Hardware Wallet
Hardware wallets use a very similar security model to breadwallet. Most of the pros/cons from breadwallet apply here.
Here are the differences:
- Hardware wallets are purpose-built to do just one thing, so they’re better in many subtle ways (less ambiguous about updates, more likely to use a secure element, and able to design hardware custom to the UX).
- Hardware wallets have full support for more advanced configurations (third party integrations, signing messages, segwit, multiple/deniable passwords, etc).
- While better than a mobile phone, it’s still hard to verify that the software you’re running is actually what’s on the github repository.
- Hardware wallets cost money (around $50–$150), but at this level of holdings you can afford it.
Most hardware wallets use standard BIP 32/39/44 implementations. Here’s an old script I wrote to recover Trezor funds even if they go out of business or your device stops working.
Hardware wallets make private key management easier, but not easy. Be sure to read about your device and understand how to best make use of all its features (like using a strong password/PIN). You also still have to deal with securing backups of your seed, and potentially having multiple passwords for deniability (one with limited funds).
$2 MM: Build Your Own Hardware Wallet with Electrum on Tails OS (with Airgap)
While hardware wallets are great, the device signing the transaction is still plugged into an internet connected machine that we treat as compromised (if we believed that the computer was safe it would be easier to just run a wallet directly on the computer). We’d prefer a protocol that was truly airgapped, which Electrum/Tails gives us.
The amnesic incognito live system (Tails) is a live operating system that comes with Electrum pre-installed. It’s specifically designed to leave no trace on the host operating system. It wipes RAM on shutdown and doesn’t even use the file-system!
Like hardware wallets and breadwallet, Electrum is still an SPV client so it’s subject to a similar security model. Here are the main differences:
- The electrum client that signs the transactions can fetch transactions from your internet connected computer (which has a watching only address), validate the data, and send back signed transactions all via QR code. The airgap is maintained, with the ability to validate the data at each step in case the online computer is compromised.
- You can be confident you’re running the software you think you are. Feel free to build from source!
- You want a dedicated machine to run this on, so you’ll have to buy that. An old laptop works great, so you may already have one lying around. Tails requires a 64 bit x86 processor and only 2GB RAM. It is recommended to boot via a live DVD and not a USB drive, and a webcam is needed if you want to use QR codes for your airgap (recommended).
$2+ MM: Bitcoin Core Full Node (with Airgap)
Congratulations, you’re bitcoin rich! Maybe your grandkids will one day ask you what it was like to hold > 1 BTC.
Bitcoin core is the gold standard when it comes to securing your bitcoin and validating the network. It can do everything you want and more, but is not the easiest to use.
- Best in class security. This version has the most contributors and reviewers auditing the code.
- Full feature completeness. Not only can it support anything bitcoin can do, but it is the first to support new features.
- Standard implementation. Whatever bitcoin core adopts is very likely to be the best practice that others follow.
- Not easy to use. Command line skills will likely be needed.
- While it does have a GUI, this is not the focus and you will have to be careful to avoid any pitfalls.
- Requires downloading (and validating) the whole blockchain, which is currently ~150 GB.
- Requires dedicated hardware that may cost in the hundreds of dollars.
The glacier protocol has an in-depth guide on how to use bitcoin core via airgap. You could also use something like BitKey. Armory Wallet deserves an honorable mention for best-in-class security, but is no longer recommended as it is maintained almost entirely by one developer.
So, does this mean you’re now secure? Hardly!
If someone holds a gun to your head, it’s game over. But given a long enough time horizon, the same is true for all your traditional assets as well. There’s a reason why companies sell Kidnap & Ransom insurance.
What You Should Never Do
We’ve talked about the best practices, but we haven’t talked about all the worst ones to avoid. While security and usability are often necessary tradeoffs, there are some sub-optimal systems that lack both security and usability. These should never be used with non-trivial amounts of money, as there are options that are strictly superior:
- Unknown custodial/trusted web wallets. They have all the negatives of centralized services without the reputation to mitigate those risks.
- Any wallet that is not deterministic (deterministic wallets derive nearly infinite addresses from a single seed). Exhausting all the addresses in your keypool can cause your backups to become worthless, and this isn’t a process you should be manually managing. Most deterministic wallets these days will be HD wallets that follow BIP 32 (and perhaps BIPs 39 & 44), but this is not the only acceptable format.
- Any wallet that doesn’t dynamically adjust fees based on market conditions.
- Any setup that only has one copy of your private key material. Hard drives fail and buildings can burn/flood. You need multiple backups.
- Storing unencrypted private key material. If anyone finds this, you are done.
What You’re Still Doing Wrong
99% of the bitcoiners I talk to are not using Shamir’s Secret Sharing Scheme. The original paper was published in 1979 and at less than two pages long is an enjoyable read.
If your private key material is encrypted (see “What You Should Never Do” above), you need a way for your heirs to access the password if you get hit by a bus. Of course you could give them the password, but then you’ve significantly weakened your security. A better solution is to split the password multiple ways. For example, I use 6-of-11. This means that any 6-of-11 trusted people I previously designated can combine their Shamir shares to get just the password (only) to decrypt my USB drive. Of course that doesn’t give them physical access to the USB drive, which has to be handled separately (I recommend safe deposit boxes at banks).
The most popular library to use is ssss because it has been in most common linux distributions for a really long time. I wish the code were more readable. PassGuardian has a simple UI that anyone can use (offline!), and Ryan Shea’s python implementation appears very well written.
Note: you might instead be doing p2sh (multisig), which can work but has two problems:
- The protocol is inflexible and doesn’t scale. It works great for 2-of-3, but if something is important you need to be able to lose more than 2 keys and still recover your funds. After all, imagine 2 of the keys are with 2 loved ones who are in the same car crash. That’s why I like 6-of-11, you can even have great geographic diversity and spread across many families.
- It’s complicated. Don’t do this unless you’re an expert, you’re more likely to screw up.
One nice thing about p2sh is that you never recombine all the keys on a single machine.
What if you’re a 1337 h4x0r who hand-crafts their own artisanal key management and transaction signing software? In the words of cryptography.io:
This is a “Hazardous Materials” module. You should ONLY use it if you’re 100% absolutely sure that you know what you’re doing because this module is full of land mines, dragons, and dinosaurs with laser guns.
With that said, rock on! Here are some starter questions to ask yourself:
- Are you using deterministic k values (see RFC6979)? The lazy test is to see if signing the same message/TX twice results in the exact same signature. Of course this is no way to guarantee a correct implementation.
- When generating keys/seeds, are you including user-supplied entropy to protect against a compromised random number generator (or a freshly booted VM without much entropy)?
- Are you handling change address properly? Address re-use is a bad practice for many reasons. Also, a deterministic wallet will help you avoid backup failures once you exhaust your keypool. Following BIPs 32, 39, and 44 is a good best practice.
- Are you sure your transaction fee math is accurate? There is no hard-coded fee field in bitcoin transactions, the implicit fee is just all the inputs less all the outputs. You don’t want to accidentally include a massive fee, like this transaction that paid a 291 BTC fee!
- Is your fee estimation robust? Stalled transactions and 10x overpaid fees won’t explicitly lose your funds, but they can be a huge pain. In extreme cases, accounting mistakes can cause someone to accidentally pay the same invoice twice (not a double-spend).
- Do you have an RBF/CPFP solution ready for transactions that have stalled? You don’t want to have to write one on the fly.
You will be fine as long you don’t ever make a mistake; there are no bailouts in bitcoin.
I have only $10 worth of BTC and I run my own full node using hardware I built myself (and bought with cash). Everyone should do that. If you’re not validating the whole chain, you’re not running bitcoin.
First off, nicely done!
Respectfully, I have to disagree. It’s great that you’re supporting the network, and in a perfect world everyone would do that.
However, an airgapped SPV client vs using a trusted exchange offer tremendously different security levels to end users. We should encourage users first and foremost to own their own private keys, and only after that’s accomplished is it worth trying to convince them to validate more and more of the network.
But you didn’t mention X as a secure wallet?
The above are the only services I recommend. I think others are not implemented in a way to get the most security relative to their usability. If you disagree, please comment on why another service deserves to be mentioned.
What about a paper wallet?
Paper wallets can work well for storage, but you still need protection during key generation as well as when you go to spend your funds. If you don’t have these parts already figured out, then you’re liable to make a mistake when you try to access the funds.
The HD wallets recommended above can effectively be represented as a paper wallet (by writing the seed on a piece of paper). Of course this has an obvious problem, as paper is hard to encrypt. How to solve this is different for each wallet and beyond the scope of this article. So while you may be able to successfully convert one of these recommendations into a paper wallet, I don’t think paper wallets on their own are the best option.
Where did these numbers come from?
These ranges are my best guesses only and are open to debate, but my goal is that they’re at least directionally accurate. You’re always encouraged to use a more secure method to store a smaller amount of bitcoin, if anything it means you won’t have to worry about upgrading should the price rise.
As always, please use caution and understand the risks you’re taking. My advice is free, but unfortunately there are no refunds.
Thanks to Richard Kiss, Jimmy Song, Aaron Caswell & Nicolás Arqueros for reviewing earlier versions of this post. As always, reviewing a blog post does not constitute endorsement of the contents.