Frequently Asked Questions

What is the FIBRE protocol?
The Fast Internet Bitcoin Relay Engine (FIBRE) is a specialized patchset on Bitcoin Core that enables a low-latency network of nodes to relay blocks near the speed-of-light bound in fiber.
Why does fast block propagation matter?
Fast block propagation minimizes the window during which miners are working on divergent tips, thereby reducing stale block rates and improving the effective hashrate utilization of the network. This is particularly important given the significant disadvantage smaller miners have in stale block races. Fast propagation thus reduces the advantage larger miners or regions with many miners have.
But stale block rates have been fairly low since the deployment of Compact Blocks (BIP 152), why is this necessary?
Stale races should be minimized at all costs–even if perceived rates are low at any given moment, it only takes small increases to cause significant harm to low-margin mining operations. Additionally, Bitcoin mining has become highly centralized–there exists a very small subset of block template proposers. We believe this, at least in part, keeps the stale rate artificially low. However, we hope to see the Bitcoin network move to more client-side templating and decentralized pooling schemes. In a world with more block template producers, stale rates are poised to increase. In this scenario, the existence of FIBRE and FIBRE-like networks is critical to reducing the occurrence of stale races.

Notably, there are likely more stale blocks occurring than the network detects. With the introduction of a STALEHEADER Compact Block message, we likely would detect more.
What is Compact Blocks and how does it relate to the FIBRE network?
Compact Blocks is a relay protocol that minimizes both the bandwidth and latency required for block propagation by utilizing techniques of compression and reconstruction. Instead of propagating a full block and its contents, peers announce compact blocks with shortened transaction ids. The receiving peer can, to the extent possible, reconstruct the block utilizing the contents of their local mempool. The FIBRE protocol utilizes Compact Blocks as a foundation for its patchset, upon which it introduces additional logic.
What is included in the FIBRE protocol’s patchset?
The FIBRE protocol is a patchset that is maintained against Bitcoin Core. Within this patchset are two primary changes: the introduction of the UDP transport protocol as well as logic to support Forward Error Correction. There are also additional configuration options and some modifications made to the Compact Block peering logic.
Why introduce UDP?
Bitcoin Core uses TCP, which delivers an in‑order byte stream. Its reliability depends on ACKs and retransmission, so loss can trigger long tail latencies. Moreover, widely deployed loss‑based congestion control favors shorter‑RTT flows, penalizing long‑haul fiber paths that can contribute to block propagation delays. UDP enables one-way push, eliminating TCP’s ordering and retransmission constraints, enabling FIBRE to deliver blocks with latency bound in fiber rather than transport-layer limitations.
Why introduce Forward Error Correction (FEC)?
Unlike TCP, UDP does not resend dropped or corrupted packets. To balance this limitation, FIBRE utilizes FEC; FEC adds redundant data to a transmission so the receiver can correct errors or recover lost pieces without requesting retransmission, reducing delay from packet loss. In the context of Bitcoin, we must transmit enough extra data that the receiving peer can reconstruct the entire block even though some packets were lost on the way.
What data is sent with FEC?
Because Compact Block was being designed at the same time that Matt Corallo started his work on FIBRE, the cmpctblock message format was structured to ensure it fits neatly into a UDP-FEC-based relay mechanism. The primary difference between FIBRE and the standard Compact Blocks protocol is that FIBRE sends messages over UDP with FEC, and instead of relying on a round-trip to request any missing transactions in our mempool, FIBRE sends the block’s transactions immediately, again with FEC.
Why was the wirehair FEC scheme selected for use?
During FIBRE’s initial design phase, Matt Corallo and Greg Maxwell researched a number of FEC schemes designed by Chris Taylor, including leopard and fecal. Given network conditions at the time, wirehair was most performant. If you are familiar with erasure codes and are aware of a more performant FEC scheme that you would like to propose, please open an issue.
What other changes were made to Bitcoin Core’s Compact Blocks implementation in the FIBRE patchset?
Compact Block has two modes: low-bandwidth and high-bandwidth. In the low-bandwidth mode, compact block delivery requires a communication round trip. In high-bandwidth mode, compact block announcements include the block’s short transaction IDs, thus avoiding a round trip. Currently, Bitcoin Core only supports three high-bandwidth peer slots. These slots are reserved for the best performing peers (i.e. the peers who deliver blocks to you the fastest). FIBRE relaxes this limit such that it can offer more of these slots to its potential peers.

Additionally, FIBRE nodes relay individual packets to their peers as soon as they arrive (i.e. before validating them), thereby avoiding latency introduced by additional hops.
Why isn’t the FIBRE logic implemented directly in Bitcoin Core?
It’s possible that one day some of the logic in FIBRE may make its way upstream to Bitcoin Core. For now, we hope to utilize the FIBRE network as an opportunity to re-establish the value of the patchset and find new ways to improve upon it.
So there is a network of UDP-connected FIBRE nodes that maintain high-bandwidth Compact Block slots with Bitcoin Core nodes? And these Bitcoin Core nodes are ultimately peered directly with the Bitcoin gossip network? Who runs the Bitcoin Core nodes that connect to the FIBRE network?
That’s correct! In theory, anyone can run a Bitcoin Core node that connects to the FIBRE network. In practice, FIBRE Network Operators (FNO) may choose to selectively peer with block producers to ensure the lowest possible latency of block propagation across the network.
Who is running the FIBRE network?
Anyone can deploy a FIBRE network and become a FNO. One such production network is operated by the non-profit research center, Localhost Research. Currently, Localhost Research operates a network that connects New York, London, Frankfurt, Beijing, Tokyo, and Seattle. You can observe the network statistics here.
How do I connect to the FIBRE network operated by Localhost Research? Do I need to run a FIBRE node?
No, you don’t need to run a FIBRE node! You are only required to run Bitcoin Core or similar software that is compatible with the Compact Blocks specification. Once you have selected a FIBRE node with ideal peering to your mining operation’s template producer, you can simply use the -addnode configuration option. We’ll have more information on how to connect in the coming weeks.
But doesn’t it improve performance if I peer with the FIBRE network using my own FIBRE node?
The FIBRE protocol trades off DoS resistance for latency. To ensure that packets are relayed as quickly as possible, they are not validated. This means that nodes within the FIBRE network must be operated with strong trust assumptions and that external parties can only peer with it over TCP utilizing the standard high-bandwidth Compact Blocks protocol.
Isn’t that centralized? Can a FNO censor specific participants?
While any single FIBRE network is centrally operated, anyone can spin up a network of FIBRE nodes. In fact, we strongly encourage independent FIBRE network operation and are happy to assist anyone with questions not answered here and in our setup guide.
What is the history of FIBRE?
The FIBRE network is the successor to Matt Corallo’s Bitcoin Relay Network). With his experience operating and studying the Bitcoin Relay network from 2014 to 2016, alongside some research done by Greg Maxwell, Matt Corallo designed, implemented, and maintained the FIBRE protocol from 2016 until April 2017. In 2025, the maintenance of the project was taken over by w0xlt and Justin of Localhost Research under the advisory of Matt Corallo and Greg Maxwell.
How does the FIBRE protocol differ from the original Bitcoin Relay Network?
FIBRE improves on the design of the Bitcoin Relay Network primarily in two ways: it eliminates latency spikes by utilizing FEC and leverages the Compact Blocks protocol that has since become available in Bitcoin Core. For additional historical context, please read Matt Corallo’s The Future of The Bitcoin Relay Network(s).