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.
- 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.
- Previous illustration was cut-off, both in the source and the print
edition. We update the illustration to not only correct that but also
provide more accuracy:
- Instead of showing input values, the illustration now shows input
references to prevouts.
- Instead of using BTC denomination, it use satoshis
- Instead of putting tx fees in the output category, it shows them
outside the transaction since they're an implicit value
- The source for the new illustration is provided as a comment to
make future editing easier
- The text is updated to refer to the new illustration appropriately.
- Text now mentions the implicit input value
- We describe that we use satoshi values because that's what's in the
protocol
- Use "recovery code" instead of "mnemonic phrase" or "seed phrase". A
new tipbox describes that mnemonic implies memorization but that's bad
practice. The phrase recovery code is generic enough to apply to a
variety of schemes, including Electrum seed words, BIP38 seed words,
aezeed, and non-phrase schemes like that used in Muun.
- Be clearer about the difference between "wallet" and "wallet
software".
- Mention that restoring from a code doesn't restore labels or
offchain transaction info.
- Warn about re-entering your code into malware / phishing attacks.
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.
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.
David A. Harding