- Remove appendix dedicated to `bx`. They had already been slated for
deletion, as I wrote to a reviewer on 2023-07-27: "I'm also probably
going to delete the library/tool focused appendixes as I don't think
they add anything". After the disclosure of CVE-2023-39910 on August
8th, it's clear that this appendix was worse than useless: it was
harmful.
- Remove other mentions of `bx` in the book. I had not previously
intended this because it looked like a pain, but mentions of a tool
often come across as endorsements to readers and no tool created by
the team behind Libbitcoin is one I would ever want to endorse. I
regret that I didn't remove the mentions earlier in the process of
updating the book.
- Remove appendix dedicated to pycoin. I'm now aware of any problems
with pycoin, but I don't think these sort of short detached tutorials
add anything. Programming Bitcoin is an entire book built on pycoin,
and all of these tools have their own webpages that get updated more
frequently than the book.
- Drop soon-to-be-outdated mention of current block reward amount
- Aezeed: mention internal and external version sumbers. Instead of
saying "global word list", clarify that both the backup and the
recovery software need to support the same word list.
- Mention that compact block filters are something that blocks might
commit to in the future in a consensus-enforced way.
- Add links to both RGB and Taproot Assets documentation.
- Mention that taproot assets can also support native forwarding.
- Minor edits and add some FIXMEs for later changes.
- 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.
