diff --git a/ch05.asciidoc b/ch05.asciidoc index 48a25275..e8b384c5 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -196,34 +196,202 @@ subsidiaries, specific functions, or accounting categories. We'll provide a detailed exploration of HD wallets in <>. -==== Seeds and Mnemonic Codes (BIP39) +==== Seeds and Recovery Codes -((("wallets", "technology of", "seeds and mnemonic codes")))((("mnemonic -code words")))((("bitcoin improvement proposals", "Mnemonic Code Words +((("wallets", "technology of", "seeds and recovery codes")))((("recovery +code words")))((("bitcoin improvement proposals", "Recovery Code Words (BIP39)")))HD wallets are a very powerful mechanism for managing many -keys and addresses. They are even more useful if they are combined with -a standardized way of creating seeds from a sequence of English words -that are easy to transcribe, export, and import across wallets. This is -known as a _mnemonic_ and the standard is defined by BIP39. Today, most -bitcoin wallets (as well as wallets for other cryptocurrencies) use this -standard and can import and export seeds for backup and recovery using -interoperable mnemonics. - -Let's look at this from a practical perspective. Which of the following -seeds is easier to transcribe, record on paper, read without error, -export, and import into another wallet? - -.A seed for an deterministic wallet, in hex ----- -0C1E24E5917779D297E14D45F14E1A1A +keys and addresses all derived from a single seed. If your wallet database +is ever corrupted or lost, you can regenerate all of the private keys +for your wallet using your original seed. But, if someone else gets +your seed, they can also generate all of the private keys, allowing them +to steal all of the bitcoins from a single-sig wallet and reduce the +security of bitcoins in multi-signature wallets. In this section, we'll +look at several _recovery codes_ which are intended to make backups +easier and safer. + +Although seeds are large random numbers, usually 128 to 256 bits, most +recovery codes use human-language words. A large part of the motivation +for using words was to make a recovery code easy to remember. For +example, consider the recovery code encoded using both hexadecimal and +words in <>. + +[[hex_seed_vs_recovery_words]] +.A seed encoded in hex and in English words ---- +Hex-encoded: +0C1E 24E5 9177 79D2 97E1 4D45 F14E 1A1A -.A seed for an deterministic wallet, from a 12-word mnemonic ----- +Word-encoded: army van defense carry jealous true garbage claim echo media make crunch ---- +There may be cases where remembering a recovery code is a powerful +feature, such as when you are unable to transport physical belongings +(like a recovery code written on paper) without them being seized or +inspected by an outside party that might steal your bitcoins. However, +most of the time, relying on memory alone is dangerous: + +- If you forget your recovery code and lose access to your original + wallet database, your bitcoins are lost to you forever. + +- If you die or suffer a severe injury, and your heirs don't have access + to your original wallet database, they won't be able to inherit your + bitcoins. + +- If someone thinks you have a recovery code memorized that will give + them access to bitcoins, they may attempt to coerce you into + disclosing that code. As of this writing, Bitcoin contributor Jameson + Lopp has + https://github.com/jlopp/physical-bitcoin-attacks/blob/master/README.md[documented] + over 100 physical attacks against suspected owners of bitcoin and + other digital assets, including at least three deaths and numerous + occasions where someone was tortured, held hostage, or had their + family threatened. + +[TIP] +==== +Even if you use a type of recovery code that was designed for easy +memorization, we very strongly encourage you to consider writing it down. +==== + +Several different types of recovery codes are in wide use as of this +writing: + +BIP39:: + The most popular method for generating recovery codes for the + past decade, BIP39 involves generating a random sequence of bytes, + adding a checksum to it, and encoding the data into a series of 12 to + 24 words (which may be localized to a user's native language). The + words (plus an optional passphrase) are run through a _key-stretching + function_ and the output is used as a seed. BIP39 recovery codes have + several shortcomings which later schemes attempt to address. + +Electrum v2:: + Used in the Electrum wallet (version 2.0 and above), this word-based + recovery code has several advantages over BIP39. It doesn't rely on a + global word list that must be implemented by every version of every + compatible program, plus its recovery codes include a version number that + improves reliability and efficiency. Like BIP39, it supports an optional + passphrase (which Electrum calls a _seed extension_) and uses the same + key-stretching function. + +Aezeed:: + Used in the LND wallet, this is another word-based recovery code that + offers improvements over BIP39. Similar to Electrum v2 recovery codes, + it includes a version number that eliminates several issues with + upgrading wallet applications. It also includes a _wallet birthday_ + in the recovery code, a reference to the date when the user created + the wallet database; this allows a restoration process to find all of + the funds associated with a wallet without scanning the entire + blockchain, which is especially useful for privacy-focused wallets. + It includes support for changing the passphrase or changing other + aspects of the recovery code without needing to move funds to a new + seed--the user need only back up a new recovery code. One + disadvantage compared to Electrum v2 is that, like BIP39, it depends + on a global word list that all Aezeed-compatible wallet programs must + implement. + +Muun:: + Used in the Muun wallet, which defaults to requiring spending + transactions be signed by multiple keys, this is a non-word code which + must be accompanied by additional information (which Muun currently + provides in a PDF). This recovery code is unrelated to the seed and + is instead used to decrypt the private keys contained in the PDF. + Although this is unwieldy compared to the BIP39, Electrum v2, and + Aezeed recovery codes, it provides support for new technologies and + standards which are becoming more common in new wallets, such as + Lightning Network support, output script descriptors, and miniscript. + +SLIP39:: + A successor to BIP39 with some of the same authors, SLIP39 allows + a single seed to be distributed using multiple recovery codes that can + be stored in different places (or by different people). When you + create the recovery codes, you can specify how many will be required + to recover the seed. For example, you create five recovery codes but + only require three of them to recover the seed. SLIP39 provides + support for an optional passphrase, depends on a global word list, and + doesn't directly provide versioning. + +[NOTE] +==== +A new system for distributing recovery codes with similarities to SLIP39 +was proposed during the writing of this book. Codex32 allows creating +and validating recovery codes with nothing except printed instructions, +scissors, a precision knife, brass fasteners, and a pen--plus privacy +and a few hours of spare time. Alternatively, those who trust computers can create recovery codes +instantly using software on a digital device. You can create up to 31 +recovery codes to be stored in different places, specifying how many of +them will be required in order to recover the seed. As a new proposal, +details about Codex32 may change significantly before this book is +published, so we encourage any readers interested in distributed +recovery codes to investigate its https://secretcodex32.com[current +status]. +==== + +.Recovery code passphrases +**** +The BIP39, Electrum v2, Aezeed, and SLIP39 schemes may all be used with an +optional passphrase. If the only place you keep this passphrase is in +your memory, it has the same advantages and disadvantages as memorizing +your recovery code. However, there's a further set of tradeoffs +specific to the way the passphrase is used by the recovery code. + +Three of the schemes (BIP39, Electrum v2, and SLIP39) do not include the optional passphrase in the +checksum they use to protect against data entry mistakes. Every +passphrase (including not using a passphrase) will result in producing a +seed for a BIP32 tree of keys, but they'll won't be the same trees. +Different passphrases will result in different keys. That can be a +positive or a negative, depending on your perspective: + +- On the positive, if someone obtains your recovery code (but not your + passphrase), they will see a valid BIP32 tree of keys. + If you prepared for that contingency and sent some bitcoins to the + non-passphrase tree, they will steal that money. Although having some + of your bitcoins stolen is normally a bad thing, it can also provide + you with a warning that your recovery code has been compromised, + allowing you to investigate and take corrective measures. + The ability to create multiple passphrases for the same recovery code + that all look valid is a type of _plausible deniability._ + +- On the negative, if you're coerced to give an attacker a recovery + code (with or without a passphrase) and it doesn't yield the amount of + bitcoins they expected, they may continue trying to coerce you until + you give them a different passphrase with access to more bitcoins. + Designing for plausible deniability means there's no way to prove to + an attacker that you've revealed all of your information, so they may + continue trying to coerce you even after you've given them all of + your bitcoins. + +- An additional negative is the reduced amount of error detection. If + you enter a slightly wrong passphrase when restoring from a backup, + your wallet can't warn you about the mistake. If you were expecting + a balance, you will know something is wrong when your wallet + application shows you a zero balance for the regenerated key tree. + However, novice users may think their money was permanently lost and do + something foolish, such as give up and throw away their recovery code. + Or, if you were actually expecting a zero balance, you might use the + wallet application for years after your mistake until the next time + you restore with the correct passphrase and see a zero balance. + Unless you can figure out what typo you previously made, your funds + are gone. + +Unlike the other schemes, the Aezeed seed encryption scheme +authenticates its optional passphrase and will return an error if you +provide an incorrect value. This eliminates plausible deniability, adds +error detection, and makes it possible to prove that passphrase has been +revealed. + +Many users and developers disagree on which approach is better, with +some strongly in favor of plausible deniability and others preferring the +increased safety that error detection gives novice users and those under +duress. We suspect the debate will continue for as long as recovery +codes continue to be widely used. +**** + +FIXME:label export + ==== Wallet Best Practices ((("wallets", "best practices for")))((("bitcoin improvement proposals",