This is the fourth in a series of articles explaining technical concepts related to on-chain network scaling, block propagation, and other related subjects

In 2009 the world was introduced to its first Bitcoin node. Here node means a computer that runs special software that can service the Bitcoin network. Transactions are then put together into a block and released to the network. The block then needs to be disseminated to all nodes in the network. As there became more demand for Bitcoin transactions, a block might not reach every node as quickly as desired.

Compact and Xthin blocks to solve propagation, and their new considerations

The Bitcoin core developers had a fix for this situation. They called their solution compact blocks. The idea is simple. Instead of broadcasting every transaction in the block. Only broadcast a list of identifiers of the transactions. As almost all transactions are stored by every node, the receiving node can then find the transactions that are identified and construct the block. The block can then be securely verified as correct. If any transactions are missing then the node can request those transactions from connected nodes. Compact blocks saves bandwidth, but it introduces a possible new step. This new step of asking for missing transactions.

Asking for new transactions involves two way communication which will introduce latency. The Bitcoin Unlimited team had a plan to reduce the need to request missing transactions. If a node asked for a block, a bloom filter of all known transactions was sent with the request. This way the sending node could predict which transactions might be missing and send them along with the list of transaction identifiers. This was called Xtreme thinblocks or Xthin propagation.

The Poison block attack to slow down propagation

Both these protocols as well as the Graphene protocol discussed in a previous article rely on transactions being available by receiving nodes in order to successfully speed-up propagation. All these protocols will eventually fall back on block propagation with no speedup if the transactions are not available.

In fact a miner could choose to include transactions in a block which have not been broadcast to the network. Such a block is called a poison block. A poison block would render the propagation speedups ineffective. Further, a failed attempt at a quicker propagation will delay sharing useful information. The result of a poison block will be a network hiccup, some nodes could be a block ahead while other nodes catch up. There is also a greater chance that a poison block will be orphaned and ignored by the network.

A poison block can only be created by a miner. Incentives are such that a miner should not want to create a poison block. Networks are resilient enough to process poison blocks and go on.