Block Relay

What Is Block Relay?

Block relay is the peer-to-peer process of propagating newly mined blocks across the Bitcoin network. When a miner discovers a valid block header that satisfies the current difficulty target, the block must reach every other node on the network so they can validate it, update their local copy of the blockchain, and begin mining or building on top of it.

The relay process involves a specific sequence of P2P protocol messages: a node announces a new block, peers request its contents, the receiving node validates the block against consensus rules, and then forwards it to its own peers. This cycle repeats until the block has reached every reachable node on the network.

Block relay performance is one of the most critical factors in Bitcoin's health. Slow relay increases the rate of stale blocks, wastes mining energy, and creates centralization pressure. Decades of protocol engineering have gone into reducing relay latency from tens of seconds to sub-second timescales.

How It Works

Block relay has evolved through several protocol generations. Modern Bitcoin Core nodes use headers-first synchronization with compact block support, but understanding the full evolution provides important context.

Legacy Blocks-First Relay

Prior to Bitcoin Core 0.10.0, blocks were relayed using a simple inventory-based system:

1. A miner finds a valid block and sends an inv (inventory) message containing the block hash to connected peers
2. Each peer responds with a getdata message requesting the full block
3. The originating node sends a block message containing the complete serialized block data
4. The receiving node validates the block (checking proof-of-work, transaction validity, and UTXO state) and then repeats the cycle with its own peers

This approach had significant limitations. Nodes downloaded blocks sequentially from a single sync peer, making the process vulnerable to slow peers. Blocks were stored before proof-of-work validation, creating disk-fill attack vectors. And the round-trip overhead for every hop added substantial latency.

Headers-First Synchronization

Bitcoin Core 0.10.0 introduced headers-first sync (PR #4468 by Pieter Wuille), which fundamentally improved both initial block download and ongoing relay:

1. A node sends getheaders requesting up to 2,000 block headers at a time
2. Headers are partially validated (proof-of-work check on 80-byte headers) before requesting full blocks
3. Blocks are fetched in parallel from all available outbound peers using a 1,024-block moving download window, requesting up to 16 blocks per peer simultaneously
4. Stalled peers are automatically disconnected, preventing a single slow node from blocking progress

Headers sync completes in fewer than 200 round trips (approximately 32 MB of header data), after which block downloads proceed in parallel. This made disk-fill attacks require valid proof-of-work, since only blocks with validated headers are requested and stored.

Direct Headers Announcement (BIP 130)

Bitcoin Core 0.12.0 added BIP 130, which eliminated an entire round trip from new block relay. During the connection handshake, a node sends a sendheaders message signaling that it prefers to receive block announcements as headers messages rather than inv messages.

When a relay node validates a new block, it immediately sends the header to peers that signaled sendheaders support, skipping the inv/getheaders round trip entirely. During chain reorganizations, all new headers are sent (not just the tip), often preventing extra round trips.

Compact Blocks (BIP 152)

The most significant relay optimization came with compact blocks, authored by Matt Corallo and included in Bitcoin Core 0.13.0 (August 2016). Instead of transmitting every full transaction in a block, compact blocks send a sketch containing:

• The 80-byte block header
• A nonce used for short ID computation
• 6-byte short transaction identifiers for all transactions in the block
• Prefilled transactions the sender predicts the receiver lacks (at minimum, the coinbase transaction)

The receiving node matches short IDs against transactions already in its mempool and reconstructs the full block locally. Only genuinely missing transactions need to be requested via a getblocktxn message. A typical 1 MB block can be reconstructed from approximately 9-20 KB of compact block data: a 97-99% bandwidth reduction.

# Compact block relay message flow

# High-bandwidth mode (0.5 RTT best case)
Peer A → Peer B: cmpctblock (header + short IDs)
Peer B: reconstructs block from mempool
# If transactions missing:
Peer B → Peer A: getblocktxn (request missing txs)
Peer A → Peer B: blocktxn (provide missing txs)

# Low-bandwidth mode (1.5 RTT best case)
Peer A → Peer B: inv or headers (announce block)
Peer B → Peer A: getdata MSG_CMPCT_BLOCK
Peer A → Peer B: cmpctblock (header + short IDs)
Peer B: reconstructs block from mempool

Compact blocks operate in two modes. In high-bandwidth mode, peers send the compact block immediately after checking proof-of-work, without waiting for full validation. Over 90% of blocks propagate in a single message without needing additional transaction requests. In low-bandwidth mode, peers first announce via headers, then the receiver requests the compact block, trading latency for reduced duplicate bandwidth. For a deeper look, see the compact block relay propagation research article.

Relay Latency and Mining Centralization

Block propagation speed has direct economic consequences for miners. Any miner who has not received the latest valid block is wasting hashrate mining on a stale chain tip. The resulting stale blocks represent lost revenue and wasted energy.

This creates a structural advantage for larger, better-connected mining operations. Research shows that under 10-second propagation conditions, a 5 EH/s mining operation could gain approximately $100K in additional annual revenue by connecting to the largest pool instead of the smallest. Slower propagation effectively subsidizes miners with superior network connectivity.

Protocol improvements have dramatically reduced this centralization pressure. Before 2015, median block propagation exceeded 6 seconds. Today, median propagation is under 1 second, with the 90th percentile under 10 seconds. Current stale block rates are well below 0.1%, compared to simulated rates of 1.85% without relay optimizations. For more on the economic dynamics, see the mining centralization and pool risks research article.

Geographic Disparities

Relay latency varies significantly by region. European nodes average approximately 3.5 seconds for block reception, while nodes in North America and Asia average 5.7 seconds. Oceania averages 8.5 seconds, and nodes in Africa and South America can experience latencies 84% or more above the European average. These disparities mean that mining operations in well-connected regions have a measurable advantage in stale block avoidance.

The FIBRE Network

The Fast Internet Bitcoin Relay Engine (FIBRE) was a dedicated relay network created by Matt Corallo in 2016 to replace the earlier Bitcoin Relay Network. FIBRE combined three technologies to achieve near-speed-of-light block propagation:

• UDP transport instead of TCP, avoiding retransmission delays caused by packet loss
• Forward error correction (FEC), sending redundant data so nodes can reconstruct transmissions even when some packets are lost
• Compact blocks (BIP 152) to minimize the data that needs to be transmitted

FIBRE achieved global block relay times of approximately 100-300 milliseconds, with nodes positioned across China, Europe, North America, Russia, and Southeast Asia. The network was designed as a Bitcoin Core patchset so anyone could run their own relay node, rather than depending on centralized infrastructure.

The original FIBRE network was shut down around 2020 due to maintenance constraints. Localhost Research relaunched the network in March 2026. FIBRE demonstrated that dedicated relay infrastructure could dramatically reduce propagation latency, increasing the cost of selfish mining attacks and reducing empty block generation from SPV mining.

Transaction Relay and Erlay

While block relay moves completed blocks across the network, transaction relay (the process of propagating individual unconfirmed transactions through the mempool) has a direct impact on block relay efficiency. Compact blocks work best when the receiving node already has most of a block's transactions in its mempool. Better transaction relay means better compact block reconstruction rates.

Erlay (BIP 330) addresses the bandwidth cost of transaction relay. Currently, approximately 50% of a node's bandwidth goes to transaction announcements, with 85% of those announcements being redundant. Erlay uses a hybrid approach: flooding transactions over a small subset of connections, then periodically reconciling transaction sets with remaining peers using Minisketch-based set reconciliation.

Erlay reduces transaction announcement bandwidth by approximately 84% and total node bandwidth by about 40%. This enables nodes to maintain more peer connections at near-zero bandwidth cost, improving network connectivity and resilience. Indirectly, this improves compact block reconstruction success rates by ensuring transactions propagate to more nodes before the block containing them is mined. See the Erlay transaction relay protocol research article for a deeper analysis.

Use Cases

Block relay underpins every aspect of Bitcoin's operation, but certain use cases depend especially heavily on relay performance:

• Mining operations rely on fast relay to minimize stale blocks. A miner who receives new blocks even one second faster than competitors gains a measurable revenue advantage, making relay speed a factor in mining profitability
• Full nodes validating the blockchain depend on efficient relay to stay synchronized with the network tip. Compact blocks make it practical to run a full node on limited bandwidth connections
• Layer-2 protocols like Lightning and Spark depend on timely block confirmation for security. Force-close transactions and penalty transactions must be mined promptly, making reliable block relay essential for dispute resolution
• SPV clients and light wallets use compact block filters (BIP 157/158) to track relevant transactions without downloading full blocks, a design that builds on the same bandwidth optimization principles as compact block relay

Risks and Considerations

Network Congestion and Reconstruction Failures

During periods of heavy network congestion, compact block reconstruction success rates can drop significantly. In late 2024, congestion events caused reconstruction rates to fall below 50% in some cases, forcing nodes to fall back to full transaction requests. This added hundreds of milliseconds to seconds of additional relay latency, temporarily widening the gap between well-connected and poorly-connected miners.

Centralization of Relay Infrastructure

Dedicated relay networks like FIBRE improve propagation speed but introduce questions about centralization. If miners depend on a small number of relay nodes operated by a single entity, that entity gains influence over block propagation timing. The open-source, run-your-own design of FIBRE mitigated this, but the tension between optimization and decentralization remains inherent to relay network design.

Eclipse and Partitioning Attacks

An attacker who controls all of a node's peer connections can manipulate which blocks that node sees, potentially enabling double-spend attacks or delaying a miner's awareness of new blocks. Bitcoin Core mitigates this through peer discovery mechanisms, outbound connection diversity, and anchor connections that persist across restarts. For a broader view of network resilience, see the P2P network topology and resilience research article.

Bandwidth Requirements

Even with compact blocks, running a full node requires meaningful upstream and downstream bandwidth. Compact blocks reduced per-block relay from ~1 MB to ~9-20 KB, but nodes must also relay transactions, headers, and maintain connections to multiple peers. Erlay promises further reductions, but until it is deployed, bandwidth remains a barrier to running nodes in regions with limited internet infrastructure.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.