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