I want bitcoin to be for everyone; however, everyone who owns bitcoin, whether or not they self-custody, needs to be aware of the risks and responsibilities that come with it.
In July, Coinkite disclosed that a firmware bug in some Coldcard hardware wallets had weakened the randomness behind the seeds they generated, and attackers recreated private keys from those seeds. In October, Ledger reported that criminals had opened genuine Ledger devices, added hidden components that captured recovery phrases during setup, and put them back on sale. This week, Binance paused withdrawals after attackers drained its hot wallets.
Leaving coins on an exchange means trusting the company’s operations. A dedicated hardware wallet removes that dependence and adds others, including the maker’s supply chain, its firmware, and the randomness it uses to create your keys. Putting all your effort into mitigating against one kind of risk can leave you open to another type of risk. Every setup carries some risk, so I’d ask you which risks you’re willing to take and whether you can protect against them.
The two paths in this post use general-purpose hardware running general-purpose operating systems: a spare phone and an ordinary computer. Some people will tell you that’s reckless. Those devices do have known weaknesses, but with the precautions below (a factory reset, keeping the keys on a device that stays offline, and a backup you’ve practiced restoring from), you can reduce those risks a great deal.
If you bought bitcoin on an exchange, the exchange holds it for you. The balance in your app is the company’s promise to pay, and the company holds the keys, the secrets that authorize spending. A few of my friends have asked me what I would do, so I’ve written down the path I’d walk them through. You can do this without becoming a developer if you follow a good guide and test things before trusting them.
Better step-by-step guides than I could write already exist, so this post is my suggested reading list.
What changes when you hold the keys
Once your bitcoin sits in a wallet whose keys you control, no exchange can freeze it or lose it in a hack. Nobody can reset your password either. If you lose the keys and every backup, the bitcoin is gone. If someone else gets them, they can spend it.
So I treat the backup as most of the work. Before anyone moves anything meaningful, I want them to have restored from it at least once, stored it where it survives a fire or a lost device, and kept it away from anyone who shouldn’t see it. The two paths below back up in different ways.
Path one: Cupcake on a spare phone, with Cake Wallet
I suggest this path to friends who have an old iPhone or Android phone in a drawer and would rather tap through an app than learn desktop software.
The Cake Wallet team’s Cupcake overview describes Cupcake as a way to turn a spare iOS or Android phone into a signer: Cupcake holds the private keys and works without internet access, while Cake Wallet on your everyday device holds only the public keys it needs to show your balance, generate addresses, and prepare transactions for Cupcake to sign.
Cupcake’s App Store listing asks for iOS 12.0 or later. On Android, Google Play shows whether the phone is compatible. Cake Wallet, the companion app, needs Android 8.0 or newer, iOS 15 or newer, macOS 12 or newer, or Linux, plus a camera to scan the QR code Cupcake shows during pairing. Cake has paused its Windows desktop builds for now.
I’d start with the official Getting started with Cupcake guide. It covers creating the wallet, setting a PIN or password, writing down your recovery phrase (a list of words that can rebuild the wallet) and confirming you copied it correctly, then linking Cupcake to Cake Wallet by scanning a QR code.
The guide doesn’t cover preparing the phone itself. I’d use a phone that has only ever been yours and that you have no reason to be suspicious of, since a reset won’t fix a phone you already distrust. I’d copy off anything worth keeping, take out the SIM card, factory reset it, and install the latest system update it will accept. Then I’d install Cupcake from the App Store, Google Play, or Cake’s GitHub releases, and turn off Wi-Fi, mobile data, and Bluetooth before creating the wallet.
On this path, the backup is the recovery phrase, which I’d write by hand on paper and never photograph. Before any real money goes in, I’d practice restoring from those words.
Path two: Bitcoin Core on a laptop
I suggest this path to friends who want to understand what’s happening underneath and don’t mind a course. Bitcoin Core is the reference Bitcoin software, and it checks the network’s history itself instead of trusting someone else’s server.
The easiest-to-follow and beginner-friendly guides I found for this are by Pavao. I’d open his illustrated Bitcoin Core wallet setup, backup, and recovery guide first. In 60 to 90 minutes, by his estimate, you create a practice wallet in Bitcoin Core 31.1, protect it with a randomly generated passphrase, back up the wallet file, optionally encrypt that backup with GPG, and restore it to prove the backup opens. The wallet is for practice only, with no real bitcoin in it.
Bitcoin Core doesn’t give you a word list. Your backup is a copy of the wallet file plus the passphrase that unlocks it for spending, stored separately, and you need both to recover.
After that, I’d move on to Pavao’s full self-custody course. Part II has you practice with Signet test coins, which have no value, and prove backup and recovery. Then it splits the work across two computers: an online one that tracks the wallet without its spending keys, and an offline one that signs. His “Move to real Bitcoin” section comes after that practice and starts a fresh wallet for real funds, restores it while it’s still empty, and sends a small real payment from the restored copy.
An ordinary Core wallet on your laptop keeps its keys on an internet-connected machine, guarded by the passphrase. Pavao advises against putting meaningful savings on a daily computer and suggests a dedicated machine with a fresh Linux install. The offline signing setup keeps the keys on a computer that never goes online, at the cost of more setup.
Moving your bitcoin off the exchange
Blockstream’s short article, How and why should I withdraw my bitcoin from an exchange?, covers the basic move: paste a receiving address from your wallet into the exchange’s withdrawal form, double-check it, and expect a wait, since exchanges often batch withdrawals and may run compliance checks. I’d add checkpoints:
- Finish and test your backup first.
- Get a receiving address from your wallet. Cake’s receiving guide explains the address types. Choose Standard, the regular on-chain Bitcoin address, rather than Lightning.
- Check the whole address in the exchange form against the one in your wallet, not just the first few characters.
- If the exchange offers a choice of network, pick Bitcoin on-chain.
- Withdraw a small amount and wait until your wallet shows it.
- Prove you can spend it by sending part of that amount to a new address in your own wallet.
- Move the rest, in one go or in stages.
Receiving doesn’t need the keys online
A wallet can create receiving addresses from public information, so the device holding the private keys can stay offline while money comes in. With Cupcake, Cake Wallet on your everyday device generates the addresses. In Pavao’s two-computer setup, the online watch-only wallet does. With an ordinary online Core wallet, the keys already sit on a connected machine.
The next step: 2-of-3 multisig
Once a single wallet feels routine, I’d like my friends to move to 2-of-3 multisig, where three keys are kept in separate places and any two can authorize a payment, so one lost or stolen key no longer costs you the bitcoin. You also have to back up the wallet setup that ties the keys together, and recovery has more steps to rehearse and more ways to go wrong. Pavao’s Part III walks through building a 2-of-3 setup, backing up that policy, and testing what happens when a signer goes missing. In the coming days, I’ll write a follow-up post with a few beginner-friendly ways I think a 2-of-3 setup could look, including the risks of each and where each one gives up some “sovereign safety” for convenience.