Block Submission Network
A block submission network is the relay infrastructure miners use to deliver new blocks across the Bitcoin network fast enough to avoid orphan risk.
Definition
A block submission network is the set of connections, protocols, and relay infrastructure a miner or pool uses to deliver a newly found block to the Bitcoin peer-to-peer network. The goal is simple: get the block validated and propagated before a competing block at the same height wins the race. Submission networks range from a single Bitcoin Core node to multi-continent relay meshes with sub-second latency.
How It Works
When mining hardware finds a nonce that satisfies the difficulty target, the result must be assembled into a complete block template and submitted. The path depends on the setup:
Solo mining: The miner’s own Bitcoin node validates and relays it to connected peers, which forward it across the P2P network.
Pool mining: ASICs submit shares via the Stratum Protocol to the pool server. When a share meets network difficulty (making it a valid block candidate), the pool validates and broadcasts it. The miner never touches the P2P network directly.
A typical pool path: ASIC → Stratum → pool server → pool’s dedicated full nodes → relay peers → broader P2P network. Pools add redundancy with nodes in multiple regions and direct connections to other large pools’ nodes.
Relay Infrastructure
The Bitcoin network has evolved several layers of relay technology to minimize block propagation time:
-
Standard P2P relay: Bitcoin Core nodes forward blocks to connected peers via
inv/getdata/blockmessages. Typical propagation across the full network: 5–15 seconds. -
Compact Blocks (BIP 152): Sends a compact header plus short transaction IDs instead of the full 1–4 MB block. Receiving nodes reconstruct from their mempool, requesting only missing transactions. Cuts bandwidth ~95% and propagation to under 2 seconds between well-connected nodes.
-
FIBRE (Fast Internet Bitcoin Relay Engine): A UDP-based relay network by Matt Corallo using forward error correction to tolerate packet loss without retransmission. Nodes at major internet exchanges achieve sub-second propagation across continents. Complements the P2P network — blocks flow through both paths simultaneously.
-
Blocksonly mode: Nodes with
-blocksonlyskip transaction relay, requesting only blocks. Cuts bandwidth ~90% but cannot serve compact block reconstructions to peers. -
Direct pool-to-pool connections: Large pools maintain private peering links, bypassing the public P2P network. Blocks propagate in milliseconds — the fastest path, though it raises centralization concerns.
Timing and Orphan Risk
Every millisecond of propagation delay increases the chance that another miner finds a competing block first. Before compact blocks and FIBRE, the median block propagation time was 6–12 seconds and orphan rates ran 1–2%. Today, with compact blocks as the default in Bitcoin Core and FIBRE covering key infrastructure, median propagation is under 2 seconds and the effective orphan rate is near zero for well-connected miners.
The worst-case scenario is a block found during a propagation gap — when a large miner’s block is still spreading and a smaller miner finds a second block at the same height. The smaller miner’s block may propagate faster (shorter path to relay nodes) and win the race despite being found later. This is why submission latency, not just hashrate, determines block acceptance probability.
Why It Matters
For miners and pools, block submission infrastructure is revenue protection. A valid block that propagates too slowly becomes an orphan block, forfeiting the block reward and transaction fees. For a pool finding several blocks per day, even a 0.1% orphan rate represents thousands of dollars in lost monthly revenue.
The decentralization angle matters equally. If only the largest pools have sub-second relay infrastructure, they gain a structural advantage over smaller operators. Open-source tools like FIBRE and Bitcoin Core’s built-in compact blocks help level the field, but smaller pools still lag in direct peering arrangements.