- 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.
- Describe topological order to help readers understand how that solves
the double spend problem
- Mention that transactions can be safely relayed one block before their
locktime allows them to be included in a block because they'll be
valid next block.
- Be a bit clearer about when subsidy becomes zero due to rounding and
when BIP42 makes it zero unconditionally.
- Describe the creation of the witness merkle root before the block
header merkle root
- Move up note about the retarget off-by-one bug
- Make "best blockchain" an inherent property and not an alias for a
current chain. When a new block arrives that triggers a reorg, we
don't switch best blockchains---the new chain is the best blockchain
and we switch to using it.
- Combine two sections about forks that were repetitive
- Mention that pool miners also need to prove they paid the pool's
preferred coinbase transaction template
- Add a todo to clarify terminology around the 51% attack. The existing
text used this in a way that's consistent with how it was used in
early Bitcoin history, but it's potentially confusing because it
doesn't actually require a majority of hashrate to make the attack and
it confuses it with a censorship attack that does require a majority
(or at least a selfishing mining minority) to maintain.
- Reduce the situations we describe as "double spends". Consensus
prevents double spending within a valid chain; the other situations
are about unconfirmed transactions, which might better be described
using other terms that won't confuse readers into thinking Bitcoin's
double spend protection doesn't work.
- Add warning about backing up more than your seed when multisig or
complex contracts are in use.
- Add a todo to fix "millibits" situation, which might involve image
changes.
- Note that the first commitment transaction (the refund) needs to be
signed before the funding transaction in LN channels.
- Pluralize "bitcoin" as necessary (somehow missed this before).
- Drop mention of tumblebit and teechan, which nobody is working on
AFAIK.
The description of SPV in the original paper assumed full nodes would
warn SPV clients about invalid blocks. Such fraud proofs are not used
in production, so lightweight clients are (arguably) not SPV clients.
- 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.
- Mention an example of Bitcoin Core sending a BIP151 transacation in
advance, alas it's the only case implemented.
- Mention that FIBRE is software (since Matt's main network for it was
shut down)
- Add fRelay to the node announcement message. We've only had it for 11
years.
- Clarify descriptions mention the genesis block as part of the block
chain
- Mention that BIP157/8 is not able to relay unconfirmed transactions
- Update assertion that the mempool is only stored in memory (on Bitcoin
Core, it is now written to disk on shutdown; on libbitcoin, it's
always written to disk)
- HUGE FIX: correct inverted enumerator and denominator on feerates. So
embarrasing!
These were absurdly hard to write and, as often happens when something
is that hard to write, they don't appear to be helpful, as judged by
Murch. The last time I tried to explain the theory[1], it also sucked,
so maybe this isn't what I'm meant to do. :-)
The removed text introduces the term "mempool" for this chapter, so a
small edit is made later on to compensate.
[1] https://en.bitcoin.it/wiki/Miner_fees#The_market_for_block_space
- 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
