- Explicitly describe what BIPs are before we start dropping references
to them.
- Mention that addresses don't encode a message, so using a unique
address that the receiver has privately associated with a spender is
the only guaranteed way to identify payments from that spender.
- Correct how many blocks need to elapse before an output can be spent
by an input with a relative lock time.
- Many other small edits.
Edits to the implementation details section to conform to updated
language (wallet->wallet application/database, hardware wallet->hardware
signing device, mnemonic->recovery code) and also to update some
descriptions.
Previously this section described all the "best practices" technologies
in detail. We dropped the best practices section, since there are
multiple valid alternatives, so we need to describe now why we're only
focusing on a subset of the available technologies.
I think it's probably confusing to people learning about this to see
that BIP32 takes up to 512 bits of entropy, BIP39 accepts up to 256
bits, and Aezeed uses 128 bits, not to mention all the other possible
combinations. This commit adds a sidebar explaining why you can't get
any better than 256 and that 128 is probably appropriate.
Even in the hands of an expert, the security of these things is dubious.
When used by a novice, there's a pretty high chance of them leaking or
breaking their keys.
The previous version of this chapter focused on a single set of
technologies: BIP32 HD wallets, BIP39 seeds, and BIP43/44 paths. The
previous Best Practices section described these as a de facto standard.
In the rewrite of this chapter, we've introduced several alternatives
for BIP39 seeds and BIP43/44 paths, all of which are good practices. I
have my opinions about what might best, but I think it's entirely
possible for a reasonable person to conclude one of the other choices is
best, so we remove that section.
The Using A Wallet section was redundant; we've already introduce all of
those concepts.
Previous text said that extended keys were 512 bit concatenations, but
BIP32 includes extra data, including the depth, fingerprint, child
number, and a null byte for private keys. Update to be less precise but
more accurate.
- Previously this chapter recommended using the BIP43/44 family of
implicit paths. New text starts with an introduction to why path
information is necessary (thsi was previously at teh end of the
chapter) and then uses that to describe the two modern ways of dealing
with paths:
- Implicit paths, e.g. BIP43/44
- Expilict paths, e.g. output script descriptors
An often-overlooked backup concern among both wallet developers and
users is labels, which can't be restored from an HD seed. Also,
wallets for LN and other contract protocols may have additional data
they need to recover all funds. Mention these concerns and describe the
method used by several wallets (including LND) of encrypting wallet data
to one of the wallet's BIP32-derived keys.
- Rename from Seeds and Mnemonic Codes (BIP39) to Seeds and Recovery Codes
- Describe several notable alternatives to BIP39 and how they improve
upon it, such as Electrum v2, Aezeed, Muun, and SLIP39.
- Provide a sidebar that goes into detail about recovery code
passphrases, discussing the tradeoffs related to plausible
deniability.
- Rename to HD Key Generation to avoid confusing use of the term
"wallet"
- Remove detail that's now redundant thanks to the introduction of the
newly added previous sections.
- Lightly edit the rest.
As we rewrite the opening of the chapter to introduce HD wallets in
stages, this introduces the penultimate part: the ability to create
derived public keys without access to the corresponding private keys.
There are no modern wallets applications which use
independently-generated keys, except when providing backwards
compatibility, so we reduce the amount of text devoted to this
concept.
We also begin trying to be consistent about using the terms "wallet
application" and "wallet database" it disambiguate the term "wallet".
- Retitle from "wallets" to "wallet recovery". The existing chapter is
entirely about generating keys in a way that can be recovered after a
data loss. I worry that calling this chapter "wallets" results in ignoring
many other aspects of wallet design, such as how they scan for
transactions (important for privacy) and how they sign (important for
security and wallet interoperation).
- Re-introduce the chapter, given the changed name.
The commit ab5ae32bae is the last commit
for the second edition, so all changes since then are dropped except for
several commits for the third edition authored by Andreas Antonopoulos.
No attempt is made to remove CC-BY-SA or other licensed content present
in the already-published first or second editions.
This revert may itself be reverted for versions of the book published
under CC-BY-SA.
- Replace 'seed' by 'random sequence' twice, as using the term 'seed' to refer to the initial random sequence or value encoded by the mnemonic words is confusing, as these mnemonic words are later on used to derive the real 512-bit seed.
- Introduced the term "initial seed" to clarify that the "mnemonic" random sequence (entropy) can be considered, in fact, a seed, but to avoid confusion with the root seed, or seed, used later.
- Replace 'seed' by 'mnemonic code' twice, when covering the optional passphrase in BIP-39, as the mnemonic code plus the optional passphrase is what produces the seed. It is confusing if the term seed is used to refer to the initial entropy, rather than the 512-bit seed.
- All these modifications have been carefully evaluated to minimise the number of changes and leave the original usage of the (root) seed.
Due to the recent controversy regarding bitcoinpaperwallet.com,
recommending we don't even point people to places where they can use
webpages to generate private keys and/or mnemonics.
