Self-Custody Best Practices
By now, many Bitcoiners are aware of the risk of trusting a single wallet vendor with their life savings. The low-entropy vulnerability in the Coldcard has resulted in over $100M in losses, with many users only narrowly escaping losses because they added sufficient dice roll or passphrase entropy.
This is not the fault of users, but a failure of the Bitcoin technical community to create self-custody best practices that balance complexity and security. I have been working on seed recovery tools for a while and have learned many of the ways that users fail when attempting to self-custody. Here is my attempt to draft some best practices:
2-of-2 Multisig
Multisig has often been discouraged for new users since the typical suggestion involves setting up 3 hardware wallets in a 2-of-3 multisig, importing the public keys into coordinating software, then importing the public keys into the hardware wallets themselves, plus backing up all the seed words separately. In addition, if users fail to properly backup all 3 public keys they could lose funds. However, keeping all 3 public keys together could also reveal the user’s entire wallet history if found.
To avoid the unnecessary complexity and risks of a 2-of-3 multisig, we should standardize on 2-of-2 multisig as the best practice (when not relying on third-party signers such as Unchained and Casa). The level of security and redundancy is the same as 2-of-3 when using distributed seed word backups (we can tolerate up to one comprised backup or device).
Multi-vendor
It appears some multisig users relied on Coldcards for 2 of the signers, which negated the security advantages of multisig. Had 2 different vendors been chosen in a 2-of-2 multisig, these funds would still be secure.
Although hardware wallets (Trezor, BitBox, Foundation, Coldcard) store secrets differently in their secure elements, they all rely on the same secp256k1 cryptographic library to perform critical operations such as signing. Although unlikely, if a vulnerability appeared in that library it is possible that multiple vendors could be comprised simultaneously. For these reasons, we should extend multi-vendor to include no shared cryptographic code.
While this does limit choices for our second-signer, there are at least two options.
-
Sparrow Wallet, being written entirely in Java performs cryptography using the BouncyCastle libraries, making it a good multi-vendor option so long as users choose a strong password to encrypt their secret key on disk.
-
Ledger Wallet is the only wallet that performs cryptography within the Secure Element via its proprietary BOLOS operating system, making it arguably more secure albeit closed-source.
User-Generated Verifiable Entropy
Often it is said that users are bad at generating entropy compared to dedicated security chips. However, this is only the case when users are asked to come up with passwords they can remember. And as demonstrated by the Coldcard bug, when users do not create their own entropy they cannot verify the entropy of their wallet is truly random.
For this reason, we suggest users choose 11 of the 12 seed words. The best way to do this is to mix up a bag containing all 2048 BIP39 words, either cutout from paper or a product like seed sticks. However, there are many creative alternatives such as using a shuffled deck of cards. The wallet should provide choices for the 12th word to ensure the checksum is valid. Advanced users can verify the software derives public keys from seed words correctly using third-party tools to keep the vendors honest.
We see no advantage in using 24 words since it adds no additional output entropy and takes twice as long to backup. 100 dice rolls is more difficult to generate and verify. We should not add complexity if we do not get more entropy.
For similar reasons, users should not use a passphrase. Passphrases provide no additional output entropy and often provide little input entropy. Furthermore, passphrases follow no standards for backup and are often forgotten, making it more likely a user will lose access to their funds.
Backup Practices
As demonstrated by Jameson Lopp’s tests, the best backups are steel / titanium plates that are punched or stamped. Punching is slightly preferable since it is more forgiving and easy to “erase” by punching all boxes.
After creating backups, users should wipe and restore the wallet using only their seed backups. This critical step ensures the backups are actually correct in case of device failure.
Backups and devices should be stored in different locations that are difficult for attackers to access. If a single location is compromised, the user should lose no funds. The locations chosen in practice will depend on the threat model of the individual user.
Transaction Practices
After setting up a wallet, users should perform a small receive-and-send test before sending a large amount of bitcoin to the wallet. Users should always confirm the receive address, amounts, and change address using the display on their signing devices.
Whether the transport is USB, QR code, or MicroSD is mostly irrelevant so long as at least one of the devices is not comprised. General-purpose devices that act as signers such as Sparrow on desktop or Blue Wallet on mobile should be used exclusively for Bitcoin to avoid running malicious code that might steal secrets from the signing program’s memory.
TLDR
-
Setup a 2-of-2 multsig between one of (Trezor, BitBox, Foundation) and (Sparrow, Ledger).
-
Select 11 words from a mixed bag of the 2048 BIP39 words to generate seed words for both wallets.
-
Optionally, verify the wallet generates your keys correctly using a third-party tool (and then select another set of random words).
-
Backup your seeds by punching them into a steel plate.
-
Wipe your devices and restore them from backups
-
Send a small test transaction, remembering to always confirm the receive address, amounts, and change address using the displays of both signing devices
If you need hand-holding, use Casa or Unchained.
NOTE: I have no affiliation with any of the products / companies mentioned in this post