I think this is an overabundance of detail (and I'm not sure it's
correct about a 40-byte release; I think that may have been changed in
the RC phase).
There has also been recent (March 2023) discussion about making this
limit arbitrarily high, so this is something that might become outdated
quickly.
I think this could be confusing. It's not so much that the money is
programmable---in Bitcoin, your money won't go out and take actions on
its own based on programming. Instead, Bitcoin allows contracts to be
enforced by deterministic full nodes rather than a more arbitrary justice
system.
Some of the information necessary to validate a transaction is contained
within the transaction executing the script, such as the data the
signature commits to plus its locktimes for OP_CLTV & OP_CSV.
Although I understand the desire to use more human-friendly terms than
scriptPubKey, scriptSig, redeemScript, witness program, and witness, I
think it makes things less clear, particularly when we switch from
legacy to legacy P2SH to segwit v0 to segwit v1.
An additional problem is that, with scriptSig no longer being executed
(and witnesses never being executed), it's not quite accurate to use the
phrase "unlocking script".
This commit replaces "locking script" and "unlocking script" with either
the specific data type or with non-specific phrasing.
This chapter, containing parts of previous chapters 6 and 7, is almost
entirely rewritten.
- Instead of introducing concepts in a somewhat arbitrary order, almost
every section except the last three (coinbase txes, weight, and legacy
serializitaion) follows the order of transaction fields as seen in
a P2P serialized transaction.
- We leave details of scripts for the next chapter (authorization &
authentication), signatures for the chapter after that, and fees and
fee bumping for the chapter after that (reflecting the increased
importance of fees).
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.
