- Mention the reason for the long validation time is the verification of
transactions. We previously implied it was download time, but some
people have really fast internet.
- Better describe bitcoind cookie authentication and provide an example
to make it even more clear.
- Add a link to bitcoin-s
- Make the long sidebar on collision attacks even longer by descripting
a pre-image attack in addition to the previous descriptions of second
pre-image and collision. That way we don't conflate pre-image and
second pre-image.
- Remove redundant tip box about an oddity in language about compressed
and uncompressed private keys.
- Link to information about vanity address "mining" (brute forcing)
- Fix bitcoin-overview image (P2PKH address was used as "private key")
- Use receiving and sending images from Bitcoin Design Guide
(https://bitcoin.design) under CC-BY license
(https://github.com/BitcoinDesign/Guide/blob/master/LICENSE)
- Mention changeless outputs, especially as used in transaction-chain
image
- Include brief mention of best blockchain in paragraph about the cost
to miners for confirming conflicting transactions
- Drop unnecessary mentions of people from CH01
- FIXMEs: add notes for image corrections and best blockchain change
- Drop unnecessary mention of debits and credits
- Remove mention about asking block explorer for UTXOs to construct a
transaction. This is unnecessary detail and it can never entirely
work for our example if we later use it to spend the output (because
then the output won't be unspent)
- Instead of "new block" use "candidate block"
- Drop unnecessary mention of payment consolidation. We already
adequetely introduce this concept earlier in the chapter.
- Provide rough block and year when 99% of all BTC will have been mined
- Remove user-stories section. I think this section frontloaded too
much irrelevant detail. In new sections of this edition, I've
exclusively used the convential Alice, Bob, Carol, etc.---without
trying to maintain a consistent backstory. This is simpler on the
writer and, I think, simpler on the reader---if they jump into a
section of the book, they don't need to worry that there's some
important context in a previous section.
- This also necessitated a few changes chapter 2.
- Mostly remove the phrase "custody". Instead use the phares "control
the key". I think this is clearer to non-specialists and a quick grep
shows that we don't use any version of the word "custody" elsewhere in
the book.
- Drop localbitcoins.com. This service was terminated after this
chapter was updated.
- Add 'feerate' to the script for catching forbidden words. :-( This
required a change to a comment in an image source.
- Other minor changes and typo fixes
- BIPs: it's silly to repeat all BIPs in the book, especially when an
increasing number have never been used or are just silly. Instead,
use the list of implemented BIPs from the Bitcoin Core project, which
represents a list of mostly interesting BIPs.
- Add OP_CHECKSIGADD from tapscript to the Script copypasta.
- Bitcore removed per outline
- s/bitcoin/Bitcoin/ when appropriate
- Proof of work is only part of security
- Mining is separate from verificatino
- Kill BIP38 encrypted private keys section (mention seeds instead)
Previously, the text went into a lot of detail about block 277,315,
which was a long time ago. We generalize the text to make it
perpetually current (barring a hard fork).
The previous list mixed consensus rules that transaction must follow
with standard transaction policy, which I think was confusng for readers
and also a problem in a later reference where we claim that all
transactions in a block must follow the rules (true for consensus; false
for policy).
This short subsection described segwit's use of always-true
scriptPubKeys as special. It didn't mention the similar mechanism used
for BIP16 P2SH. It also doesn't mention block-focused changes like
BIP32 and BIP34, or non-script changes like BIP66, BIP68, and BIP113.
I think it should either be greatly expanded or removed, and removing is
easier right now. :-)
"Smore" sounds like "Schnorr", which could be confusing. Also, we
have upgraded signatures now without a soft fork, so the example is
confusing. Although we could add another coin with a soft fork (sort
of), it seems a lot less likely to me, so I think it's a better cadidate
for this section.
- When appropriate, use the current preferred technical term
"reorganize" to describe what a node does when the block at the tip of
the chain is removed.
- Otherwise, just use "converge".
- Orphan blocks are no longer a thing in Bitcoin Core since
headers-first download was implemented (version 0.10). Your peers
know what blocks you have; if they send you any block that doesn't
connect to one of those blocks, you just drop the connection to them.
