- Drop box with Wikipedia definition of digital signatures. It didn't
add anything and its accuracy was debatable.
- Use "commitment hash" earlier and more often.
- Fix some variable-name errors in the math
- Correct info about worst-case signature verification cost
During his review, Mark "Murch" Erhardt discovered that the appendix
contained several errors and many entries that were confusing. When I
looked at the upstream source on the wiki, I discover that it had extra
information that eliminated those problems. Since we only reference the
appendix twice, don't really go into detail about writing your own
scripts, and since all the information is easily accessible online for
free, we drop the appendix and replace references to it with a link to
the wiki.
- Describe OP_CMS pubkey limits for consensus, relay policy, and P2SH.
- Mention that OP_CLTV and OP_CSV leave elements on the stack, unlike
other VERIFY opcodes.
Bitcoin can do things beyond money, but (as other text in the chapter
notes) this can be controversial. Let's not oversell those other uses
here only to throw shade on them later.
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.
