- 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.
- Explicitly describe what BIPs are before we start dropping references
to them.
- Mention that addresses don't encode a message, so using a unique
address that the receiver has privately associated with a spender is
the only guaranteed way to identify payments from that spender.
- Correct how many blocks need to elapse before an output can be spent
by an input with a relative lock time.
- Many other small edits.
- New introduction to fees
- More detail about how the fee market works
- Adds RBF and CPFP fee bumping
- Adds transaction pinning
- Adds package relay
- Adds CPFP carve out
- Small edits to 'Adding fees'
- Tiny edits to fee sniping
- "Ephemeral key pair" -> nonce; makes it consistent with schnorr
section and better composes with section about avoiding nonce reuse
- Changed variables to be consistent with schnorr section
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.
