- 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.
- 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.
