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.
Remove text about dumping a private key:
- Example using Bitcoin Core is no longer supported for descriptor
wallets.
- Dumping private keys is very bad practice with HD wallets due to risk
of compromising the whole wallet.
- Because of safety risks, and lack of need, most modern wallets don't
support private key export or import
- Explain why almost nobody uses vanity addresses any more---HD wallets
killed them, plus they suck for privacy.
- Remove example code. It's only useful for base58check addresses, but
those are no longer recommended and (as mentioned above) almost nobody
uses vanity addresses any more, so there's not much point in updating
it for bech32(m).
- Remove vanity address security section with unvetted security claims.
- Replace outdated claim about miners using GPUs.
- Remove specific amount for cost of vanity address pooling and URL for
a pool. That pool doesn't work, I don't know of any others, and I
have no idea what the pricing would be even if there were existing
pools.
- Briefly mention segwit and the need for new addresses. Mention that
getting wallets to a new base58check version would probably be only a
little less work than upgrading to an entirely new address format.
Describe the problems with base58check and the solutions provide by
bech32. Illustrate some of the problems and solutions.
- Describe the bech32 length extension issue and provide an example.
- Introduce bech32m as the solution to the lengith extension issue.
- Provide examples using the bech32m reference library for Python for
encoding and decoding a bech32m address (mentioning the backwards
compatibility with bech32 addresses).
- Ask wallet authors to ensure they support forward compatibility with
future segwit versions.
- Start with a description of the problem that P2SH helps solve, the
ability for the receiver to specify a script without having to
communicate all the details of that script to the spender (and having
the spender pay the tx fees for it).
- Mention that P2SH uses base58check. Provide the prefix and continue
using an existing example, but don't go into too much detail since
bech32m addresses are now the preferred format
This is extraneous information. Any programmer who understands how to
create a base58check address can convert to it, or from it, using any
byte encoding supported by their programming language or one of its
libraries.
- A section for scriptPubKey and scriptSig allow us to explain how the
hashes for P2PKH work.
- A section for P2PK allows us to connect P2PKH payments to the original
Bitcoin paper and help us understand the underlying use of pubkeys and
signatures
- A section on P2PKH explains why we use a hash commitment (to save
space) and allows us to separate base58check (and addresses in
general) from scripts. It also helps set up a later section for P2SH.
