The Problem
Mining centralization remains a largely unmitigated tail risk to Bitcoin’s censorship resistance. This risk stems from multiple distinct vectors rather than a single root cause. One is pool centralization, driven by the economic incentive to eliminate payout variance. Another is supply chain concentration, where the manufacturing of mining hardware is effectively monopolized. There is also infrastructural asymmetry, where advantages in energy costs and network latency inherently favor large-scale, geographically specific operations. Because these pressures are structurally independent, no silver bullet exists. Addressing them requires a targeted suite of countermeasures.
Over the years, the network has seen these pressures manifest in different forms. From 2010–2016, three independent pools reached dangerously high proportions of the network’s hashrate. More recently, while no single pool has directly approached that threshold, something more insidious has emerged: the block templates produced by pools representing a substantial share of hashrate are being sourced from a single entity, often referred to as “Antpool and Friends.” These “proxy pools” appear independent, but have effectively ceded their autonomy.
One accessible vector for countering proxy pool derived centralization lies in empowering miners to construct their own block templates. The Stratum v2 protocol, alongside other client-side block templating implementations (e.g. DATUM), represent meaningful progress here. These tools lower the technical and operational barriers for miners who wish to exercise autonomy over template production. Complementary efforts like P2Poolv2 and renewed interest in solo mining infrastructure further expand the design space, creating more avenues for users to produce and broadcast their own templates rather than outsourcing this function to concentrated pool operators.
The Solution
Although client-side templating has not yet reached meaningful adoption, we remain hopeful and excited for their future impact on the ecosystem. So excited in fact, that we decided to get involved. While we have many yet-to-be-announced plans in this area, today we have one special item we’d like to share with the community: the resurrection of the FIBRE network!
FIBRE stands for the Fast Internet Bitcoin Relay Engine. It’s a protocol that enables data to propagate across the world near the speed of light bound in fiber. This is made possible through the introduction of UDP and Forward Error Correction (FEC) in a patchset to Bitcoin Core that anyone can download and run.
FIBRE is not a new concept. It is the evolution of research done by Greg Maxwell and Matt Corallo over 10 years ago. Matt Corallo took this research and deployed the Bitcoin Relay Network, later developing his learnings into the original FIBRE network which he operated from 2016 to 2017. Since then, development and operation of FIBRE has been dormant (although its UDP and FEC implementation have lived on in the Blockstream Satellite codebase) due to the significant maintenance burden born by a single maintainer.
In observing the mining ecosystem, it was clear to us that as client side template protocols increase in popularity, so too does the importance of fast block relay. Today, stale block rates appear low. Yet this metric is artificially suppressed by the very centralization it obscures. When large swaths of hashrate draw templates from a single source, the latency inherent to the Bitcoin network is effectively sidestepped.
Additionally, for those stale races that do occur, only a subset actually propagate far enough to be detected. Without a STALEHEADER-style compact block message, it’s impossible to know just how many stale blocks there are. Just recently, at block height 936988 a stale was detected by Fork Monitor, but not by Fork Observer. And these are two services specifically designed to detect such races. That is to say, we should not be complacent about stale races. It’s easy to forget, but there was a time where some pools regularly saw their stale rates approach 5% over a one month period.
Should client-side templating gain meaningful adoption, we would expect stale rates to rise, creating a disincentive for further adoption. We believe that this can be mitigated with the appropriate tooling. We also hope to minimize the efficacy of certain classes of selfish mining attacks (e.g. accidental or explicit selfish mining attacks that are dependent upon or enhanced by slow block propagation).
Ultimately, just as the introduction of Compact Blocks helped reduce the high stale rates we saw in the mid 2010s, we believe the FIBRE network will help further reduce stale races and minimize one vector of asymmetric advantage held by large miners: slow block propagation.
What We’ve Accomplished
This project is a joint effort by Localhost Research team members w0xlt and Justin under the advisory of Matt Corallo and Greg Maxwell.
Over the course of a few months, w0xlt rebased the FIBRE protocol against Bitcoin Core v30 and designed a suite of monitoring tools that enable FIBRE Network Operators (FNOs) to easily manage their deployments.
With these tools in hand, Justin deployed a public FIBRE network with six nodes: New York, Seattle, Tokyo, Beijing, Frankfurt and London. The network is in beta and can be monitored on our public dashboard. Justin also put together an updated Setup Guide and FAQ based on his learnings.
The Localhost Research team is excited to share this deployment with the Bitcoin network as we continue to stabilize and improve upon its performance. Stay tuned for more information and feel free to reach out with any questions. If you’d like to contribute to development, please open an issue in the repository.