diff --git a/ch05.asciidoc b/ch05.asciidoc index b114a519..e8f34b12 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -123,14 +123,14 @@ all the user's keys between different wallet implementations. image::images/mbc2_0502.png["Deterministic Wallet"] [[hd_wallets]] -==== HD Wallets (BIP-32/BIP-44) +==== HD Wallets (BIP32/BIP44) ((("wallets", "types of", "hierarchical deterministic (HD) wallets")))((("hierarchical deterministic (HD) wallets")))((("bitcoin improvement proposals", "Hierarchical Deterministic Wallets -(BIP-32/BIP-44)")))Deterministic wallets were developed to make it easy +(BIP32/BIP44)")))Deterministic wallets were developed to make it easy to derive many keys from a single "seed." The most advanced form of -deterministic wallets is the HD wallet defined by the BIP-32 standard. +deterministic wallets is the HD wallet defined by the BIP32 standard. HD wallets contain keys derived in a tree structure, such that a parent key can derive a sequence of children keys, each of which can derive a sequence of grandchildren keys, and so on, to an infinite depth. This @@ -156,15 +156,15 @@ transaction. The public keys do not need to be preloaded or derived in advance, yet the server doesn't have the private keys that can spend the funds. -==== Seeds and Mnemonic Codes (BIP-39) +==== Seeds and Mnemonic Codes (BIP39) ((("wallets", "technology of", "seeds and mnemonic codes")))((("mnemonic code words")))((("bitcoin improvement proposals", "Mnemonic Code Words -(BIP-39)")))HD wallets are a very powerful mechanism for managing many +(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 BIP-39. Today, most +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. @@ -187,15 +187,15 @@ garbage claim echo media make crunch ==== Wallet Best Practices ((("wallets", "best practices for")))((("bitcoin improvement proposals", -"Multipurpose HD Wallet Structure (BIP-43)")))As bitcoin wallet +"Multipurpose HD Wallet Structure (BIP43)")))As bitcoin wallet technology has matured, certain common industry standards have emerged that make bitcoin wallets broadly interoperable, easy to use, secure, and flexible. These common standards are: -* Mnemonic code words, based on BIP-39 -* HD wallets, based on BIP-32 -* Multipurpose HD wallet structure, based on BIP-43 -* Multicurrency and multiaccount wallets, based on BIP-44 +* Mnemonic code words, based on BIP39 +* HD wallets, based on BIP32 +* Multipurpose HD wallet structure, based on BIP43 +* Multicurrency and multiaccount wallets, based on BIP44 These standards may change or may become obsolete by future developments, but for now they form a set of interlocking technologies @@ -218,7 +218,7 @@ The following sections examine each of these technologies in detail. ==== If you are implementing a bitcoin wallet, it should be built as a HD wallet, with a seed encoded as mnemonic code for backup, following the -BIP-32, BIP-39, BIP-43, and BIP-44 standards, as described in the +BIP32, BIP39, BIP43, and BIP44 standards, as described in the following sections. ==== @@ -293,11 +293,11 @@ Let's now examine each of the important industry standards that are used by many bitcoin wallets in detail. [[mnemonic_code_words]] -==== Mnemonic Code Words (BIP-39) +==== Mnemonic Code Words (BIP39) ((("wallets", "technology of", "mnemonic code words")))((("mnemonic code words", id="mnemonic05")))((("bitcoin improvement proposals", "Mnemonic -Code Words (BIP-39)", id="BIP3905")))Mnemonic code words are word +Code Words (BIP39)", id="BIP3905")))Mnemonic code words are word sequences that represent (encode) a random number used as a seed to derive a deterministic wallet. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the @@ -319,17 +319,17 @@ important difference makes mnemonic words much more secure, because humans are very poor sources of randomness. ==== -Mnemonic codes are defined in BIP-39 (see <>). -Note that BIP-39 is one implementation of a mnemonic code standard. +Mnemonic codes are defined in BIP39 (see <>). +Note that BIP39 is one implementation of a mnemonic code standard. ((("Electrum wallet", seealso="wallets")))There is a different standard, with a different set of words, used by the Electrum wallet and predating -BIP-39. BIP-39 was proposed by the company behind the Trezor hardware +BIP39. BIP39 was proposed by the company behind the Trezor hardware wallet and is incompatible with Electrum's implementation. However, -BIP-39 has now achieved broad industry support across dozens of +BIP39 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de facto industry standard. -BIP-39 defines the creation of a mnemonic code and seed, which we +BIP39 defines the creation of a mnemonic code and seed, which we describe here in nine steps. For clarity, the process is split into two parts: steps 1 through 6 are shown in <> and steps 7 through 9 are shown in <>. @@ -338,7 +338,7 @@ steps 7 through 9 are shown in <>. ===== Generating mnemonic words Mnemonic words are generated automatically by the wallet using the -standardized process defined in BIP-39. The wallet starts from a source +standardized process defined in BIP39. The wallet starts from a source of entropy, adds a checksum, and then maps the entropy to a word list: 1. Create a random sequence (entropy) of 128 to 256 bits. @@ -390,7 +390,7 @@ a deterministic wallet and derive its keys. ((("salts")))((("passphrases")))The key-stretching function takes two parameters: the mnemonic and a _salt_. The purpose of a salt in a key-stretching function is to make it difficult to build a lookup table -enabling a brute-force attack. In the BIP-39 standard, the salt has +enabling a brute-force attack. In the BIP39 standard, the salt has another purpose—it allows the introduction of a passphrase that serves as an additional security factor protecting the seed, as we will describe in more detail in <>. @@ -474,9 +474,9 @@ luggage oxygen faint major edit measure invite love trap field dilemma oblige+ |======= [[mnemonic_passphrase]] -===== Optional passphrase in BIP-39 +===== Optional passphrase in BIP39 -((("passphrases")))The BIP-39 standard allows the use of an optional +((("passphrases")))The BIP39 standard allows the use of an optional passphrase in the derivation of the seed. If no passphrase is used, the mnemonic is stretched with a salt consisting of the constant string +"mnemonic"+, producing a specific 512-bit seed from any given mnemonic. @@ -491,7 +491,7 @@ is in use. [TIP] ==== -There are no "wrong" passphrases in BIP-39. Every passphrase leads to +There are no "wrong" passphrases in BIP39. Every passphrase leads to some wallet, which unless previously used will be empty. ==== @@ -518,28 +518,28 @@ her family to recover the cryptocurrency estate. ===== Working with mnemonic codes -BIP-39 is implemented as a library in many different programming +BIP39 is implemented as a library in many different programming languages: https://github.com/trezor/python-mnemonic[python-mnemonic]:: The reference implementation of the standard by the SatoshiLabs team that -proposed BIP-39, in Python +proposed BIP39, in Python https://github.com/bitcoinjs/bip39[bitcoinjs/bip39]:: An implementation -of BIP-39, as part of the popular bitcoinJS framework, in JavaScript +of BIP39, as part of the popular bitcoinJS framework, in JavaScript https://github.com/libbitcoin/libbitcoin/blob/master/src/wallet/mnemonic.cpp[libbitcoin/mnemonic]:: -An implementation of BIP-39, as part of the popular Libbitcoin +An implementation of BIP39, as part of the popular Libbitcoin framework, in pass:[C++] -There is also a BIP-39 generator implemented in a standalone webpage, +There is also a BIP39 generator implemented in a standalone webpage, which is extremely useful for testing and experimentation. <> shows a standalone web page that generates mnemonics, seeds, and extended private keys. [[a_bip39_generator_as_a_standalone_web_page]] -.A BIP-39 generator as a standalone web page -image::images/mbc2_0508.png["BIP-39 generator web-page"] +.A BIP39 generator as a standalone web page +image::images/mbc2_0508.png["BIP39 generator web-page"] ((("", startref="mnemonic05")))((("", startref="BIP3905")))The page (https://iancoleman.github.io/bip39/) can be used offline in a browser, @@ -683,7 +683,7 @@ structure. Sharing an extended key gives access to the entire branch. ==== Extended keys are encoded using Base58Check, to easily export and import -between different BIP-32–compatible wallets. The Base58Check +between different BIP32–compatible wallets. The Base58Check coding for extended keys uses a special version number that results in the prefix "xprv" and "xpub" when encoded in Base58 characters to make them easily recognizable. Because the extended key is 512 or 513 bits, @@ -904,21 +904,21 @@ because the possibilities for internal organization into branches and subbranches are endless. Two BIPs offer a solution to this complexity by creating some proposed -standards for the structure of HD wallet trees. BIP-43 proposes the use +standards for the structure of HD wallet trees. BIP43 proposes the use of the first hardened child index as a special identifier that signifies -the "purpose" of the tree structure. Based on BIP-43, an HD wallet +the "purpose" of the tree structure. Based on BIP43, an HD wallet should use only one level-1 branch of the tree, with the index number identifying the structure and namespace of the rest of the tree by defining its purpose. For example, an HD wallet using only branch m/i++'++/ is intended to signify a specific purpose and that purpose is identified by index number "i." -Extending that specification, BIP-44 proposes a multiaccount structure -as "purpose" number +44'+ under BIP-43. All HD wallets following the -BIP-44 structure are identified by the fact that they only used one +Extending that specification, BIP44 proposes a multiaccount structure +as "purpose" number +44'+ under BIP43. All HD wallets following the +BIP44 structure are identified by the fact that they only used one branch of the tree: m/44'/. -BIP-44 specifies the structure as consisting of five predefined tree levels: +BIP44 specifies the structure as consisting of five predefined tree levels: ----- m / purpose' / coin_type' / account' / change / address_index @@ -951,7 +951,7 @@ would be M/44++'++/0++'++/0++'++/0/2. <> shows a few more examples. [[table_4-9]] -.BIP-44 HD wallet structure examples +.BIP44 HD wallet structure examples [options="header"] |======= |HD path | Key described