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.
Those particular BIPs are abandoned. BIP324 takes the place of BIP151,
but a lot of this section refers to authentication, which is not in
BIP324. Also, this section mentions implementation, but BIP324 has not
been deployed as of this writing.
- Describe BIP152 compact block relay
- Describe why we still need relay networks (what they do that BIP152
can't)
- Drop FALCON relay (never used, AFAIK)
- Minor updates to relay section
- Remove images: these are incorrect and (IMO) not very useful. The
first image is a legend. The second image contains multiple errors or
confusions, such as implying that a miner needs a full copy of the
block chain or that a wallet is a routing node. The third image is a
very busy depiction of a network showing that clients connect to
nodes, which I think is fine to just say in the text.
- Revise text to not reference images.
- Maintain distinction between nodes and peers by not using terms "full
node client" or "SPV node"
- Update the count of reachable nodes
- Remove some dead full node implementations
- We revise sentence about equality among peers to make it clear that
the peers are full nodes. Clients are not peers of a full node.
- Remove clause about "reciprocity" being the incentive for
participation. I think there are varied reasons for operating a full
node, ranging from wanting to validate your own transactions
(requiring only a pruning full node) to wanting to keep mining
decentralized (e.g. by relaying transactions).
- Drop line about non-Bitcoin-P2P protocols being "extended Bitcoin
network". I think that's an unnecessary categorization.
