P2P Network

Currently, for practical purposes, any software that interacts with Bitcoin will need to either communicate using the P2P Network Protocol, or interface with another system that communicates using the P2P Network Protocol. This is a practical issue not a consensus rule. This is needed because the P2P Network Protocol is the mechanism that existing miners use to announce and distribute new blocks.

P2P Block Propagation

This topic refers to how nodes propagate new blocks across the network. It’s specific to new blocks, not downloading old blocks. There are three mechanisms:

1. Original - the original method with inv and getdata
2. Headers
3. Compact Blocks - an optimisation that has been around for a while

Other techniques exist too: Bitcoin Unlimited on the BCH network has implemented Graphene which is a refinement of the Compact Blocks method and not covered here.

Nodes on the P2P network start by assuming the Original method. If at some point a node sends the setheaders message to its peer, then it is expecting the Headers method to be used. If it sends the sendcmpct message, then it is expecting the Compact Blocks to be used. The Bitcoin SV Node implementation always tries to use Compact Blocks.

Block propagation initiates when the node updates it’s copy of the blockchain. This could be because the node has had a new block submitted to it by mining equipment, or it could be because it has received a new block over the P2P network and validated the block.

Original Block Propagation Mechanism

This is the original and default mechanism and all nodes are expected to be able to use this mechanism.

When the blockchain is updated with a new tip, the node sends out a block inv message to all of its peers which contains the block id (the hash of the block). The peers check this message and will request the block from the node with the getdata message if they need the block.

Note that the node will only send the inv message to the peers which it thinks do not yet have the block. If a peer has already sent an inv message for the same block to the node, then the node concludes that the peer already has the block so it does not bother sending the inv message to that peer. This is an optimization performed by the Bitcoin SV Node software and is not strictly required.

This mechanism causes the peer to download the entire block from the node. This is quite wasteful since the majority of the block is transaction data and its very likely that peer already has most of the transactions, which is why the Compact Blocks technique was added.

Headers Block Propagation Mechanism

This was a modification of the Original mechanism. Its a minor change. Instead of sending an inv message to its peers, a node will instead send a header message, which contains the information from the block header (which does not include the list of transactions). This will provide more data for the node to make a decision about whether it wants to obtain the block or not.

Compact Blocks Propagation Mechanism

As noted above, the problem with the original mechanism is that it sends a lot of data that the peer probably already has. Compact Blocks was designed to avoid this.

When activated, the node will send a cmpctblock message instead of the inv message (Note: I need to check this, this would be a bit wasteful if the peer already had the block). This message contains the block header, the list of transactions in the block, and the full transactions that the node expects that the peer does not already have (such as the coinbase transaction). The recipient will then check for transactions it does not already have and request those.

It’s a bit more complicated than that, but that is the main idea. It actually uses “short ids”, which are shortened forms of the transaction ids.

The specification for Compact Blocks is in BIP-0152.

Malicious Peers

Software implementations often implement a “banning” technique to mitigate against Denial of Service type attacks by peers.