Standard block relay

Two round trips and a megabyte or more, at every hop, for data the receiver mostly already had. A 2013 measurement study clocked the median node learning of a new block 6.5 seconds after it was found, with a mean of 12.6 seconds. Bitcoin Core shipped compact block relay in version 0.13.0 on August 23, 2016, and standard relay became the fallback.

How it works

Standard block relay uses three messages and assumes nothing about what the receiving node already holds.

The finder sends inv naming the new block's hash, or, since BIP130 arrived in Bitcoin Core 0.12.0, a headers message carrying the 80-byte header directly, which spares the peer a separate getheaders round trip. The receiver checks whether it has that block. If not, it replies getdata. The sender then transmits the block message: the header followed by every transaction in full serialisation, up to the four million weight unit budget that caps a block.

The waste is obvious once stated. A node that has been running for hours already holds nearly every transaction in that block in its mempool, having received each one individually when it was broadcast. Standard relay ships all of them a second time. On a block full of ordinary payments that is well over a megabyte of redundant transfer, per peer, per block.

The consequences were not merely aesthetic. Slow propagation raises the rate of stale blocks, because a miner who has not yet heard about a new block keeps grinding on the old tip. Stale blocks cost small miners more than large ones, since a big pool hears about its own blocks instantly. Faster relay was therefore a decentralisation argument as much as an efficiency one, and it drove both BIP152 and the dedicated relay networks that large pools run between themselves.

Standard relay has not gone away. It is what happens when a peer never negotiated compact blocks, when compact reconstruction fails and the missing transactions cannot be filled in, and throughout initial block download, where a syncing node requests full blocks by getdata from several peers at once, up to sixteen in flight per peer in Bitcoin Core.

Where you see it

Standard block relay is most visible while a node is catching up rather than while it is caught up.

During an initial sync, getdata for blocks dominates the traffic and the per-message counters in getpeerinfo show it plainly. Once the node reaches the tip those counters go quiet and the compact block counters take over. A machine on a slow link or with few peers falls back to standard relay more often, and the symptom is a tip that lags a minute or two behind what a public explorer is showing.

Standard block relay vs compact block relay

Standard relay sends the block; compact relay sends a description of it and lets the receiver rebuild the rest. A cmpctblock carries the header, a nonce, and a six-byte short identifier for each transaction, so a block holding a few thousand payments can be described in under twenty kilobytes instead of well over a megabyte. The receiver matches those identifiers against its own mempool, requests whatever is missing with getblocktxn, and assembles the block locally. Validation afterwards is identical: compact relay changes how the bytes arrive, never what counts as a valid block.