Comment explained why one 10-minute block doesn't give more security
than ten 1-minute blocks but didn't also warn about the problems with
1-minute blocks.
Previous example used python to describe how PoW works. Replace
the first example with a bash one-liner and remove the unnecessary
details.
Inspired by review comments from Jorge Lesmes
- 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.
