The problem with Bitcoin is that mining pools tend to get biggerThe problem with Bitcoin is that mining pools tend to get bigger
In Bitcoin mining, there's a number of reasons to get in a pool. Two of these reasons are variance and latency.
- Variance. A miner working by themselves has to wait until they find a block to get paid (really, they have to wait until they find a block and then wait another 100 blocks because block subsidies can't be spent immediately). But all along (perhaps long before they actually get any bitcoin), they have to pay power bills and whatever other bills they have. This is called variance. If you work with a pool, maybe you can find blocks more frequently and help each other by splitting the rewards.
- Latency. Miners also have this problem where the longer it takes them to learn about a new block, the worse off they are. If you have a miner and you're grinding along trying to find a block but you don't know there's already a new block that's been found and all the other miners are building on top of that one, you might be wasting your hash power. You want to be building on a new block as soon as you possibly can. However long it takes you to learn about a block is the size of your disadvantage. If you work with a pool, especially a big one, maybe they can help cut down the latency (every time your pool finds a block, you learn about it very quickly -- the bigger your pool, the more likely they are to find blocks).
Because of these two reasons, and things like economies of scale, large pools have an advantage over smaller miners operating on their own -- which means smaller miners have an incentive to join pools, which means mining pools tend to get bigger.
Big pools are big badBig pools are big bad
Everybody knows that one of the major risks for Bitcoin is a 51% attack. If one entity gains control of more than half the mining power, the censorship resistant properties of Bitcoin begin to weaken. You have probably seen a chart of the share of hash rate wielded by various pools. Lately it looks like this:
Foundry USA has found just over 30% of the blocks in the last month. You probably also read @0xB10c's report from 2024 that a number of other pools seemed to be receiving block templates from Antpool and that this group (Antpool and Friends) may represent an aggregation of hash power rather larger than is represented by the tradition of self-reporting in a coinbase transaction when they find a block. The only solace in the face of this seemingly dire centralization is that at least there are lots of small pools. Maybe other small miners will join them.
Does having more mining pools make things better?Does having more mining pools make things better?
While having lots of pools seems like a good thing, if you think about it, it doesn't actually fix the problem. Whether there are three pools or thirty, individual miners still have to work against variance and latency and those miners who join bigger pools will still have an advantage.
It might be a lovely world where there are ten different mining pools spread across the world each with ten percent of the hash power, but we would expect the same pressure towards centralization in that lovely world as there is in our Foundry-and-Antpool-and-Friends-dominated world. More pools might seem like it is better for censorship resistance, but nothing about having more pools changes the incentives point toward larger pools getting larger.
Indeed, I would expect more pools to always tend to aggregate into less pools. Maybe local regulations or the proclivities of the mining operators get in the way of this centralization, but one thing that I don't think gets in the way is having more pools to choose from.
What if we fix the latency problem?What if we fix the latency problem?
Recently, Localhost Research announced that they are reviving the FIBRE network (#1438268). The FIBRE network is a special patch to Bitcoin Core nodes that spreads block information using UDP rather than TCP:
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.
Additionally, FIBRE network nodes don't validate blocks before relaying them, which also results in a hefty reduction in latency. When a new block is shared by the peer-to-peer relay network each node has to validate the block header before it will relay the block to other nodes. This is one of the ways the network protects itself from DoS attacks. But this little bit of validation adds latency to the block's propagation such that a small miner who relies solely on Bitcoin's peer-to-peer relay network may wait a little longer to learn about a new block than a large mining pool that is broadcasting new blocks to all its members.
While anyone can run a FIBRE network (just like, in theory, anyone can run a mining pool), such a network is most effective at reducing latency if it has nodes that are geographically dispersed and if it has access to lots of large block producers (so it can learn about blocks as soon as they are found).
The idea is that a small miner could point their node at a FIBRE network node that is nearest to them and learn about blocks as soon as they are found, rather waste time mining on stale tips until they hear about a new block through normal block propagation methods.
Is adding a new relay network different than adding a new pool?Is adding a new relay network different than adding a new pool?
In the immediate term, this seems like it will reduce the advantage the large pools have over the small pools. Small pool operators (or small individual miners) will able to connect to the FIBRE network and learn about new blocks with very low latency.
This ought to increase the profitability of these miners and pools. Which ought to allow them to increase their hash rate.
However, it seems to me that the FIBRE network doesn't really reduce any of the centralization pressure on mining. It just adds a new wedge to the pie chart.
I don't see a big difference between Antpool and Friends and the various miners who will connect to a specific FIBRE network (FIBRE and Friends?). In both cases we have an entity upon which miners are relying for an efficiency gain, and which the miners have to trust to some extent in order to realize that efficiency gain.
The FIBRE website is clear that anyone can run a FIBRE network. And indeed they have made a really good set up guide should you want to do this, however, it's not clear how this actually reduces a miners incentive to join with a larger group -- it's just a new group for the miner to join.
I've been reading Cryptoeconomics again, and this is an attempt to work through some of the ideas in the chapter called "Relay Fallacy" which I am copying below.
The peer-to-peer network disseminates blocks and unconfirmed transactions. The protocol itself allows nodes to protect against denial of service. Consequently this communication requires no identity. This protection is how the network avoids the need for permission to participate.
However this protection comes at a cost in terms of announcement latency, and because of the advantage to proximity, lower latency translates into higher apparent hash power. Therefore miners compete for reduced latency. One way to reduce latency is pooling, another is to use a more efficient dissemination network. Given that pooling surrenders power to the operator, presumably the latter option is preferable.
One way to improve dissemination is to optimize the peer-to-peer network. The other is to join a distinct network, called a relay, that has lower latency due to elimination of denial-of-service protections, for example:
[T]he cmpctblock message format was designed to ensure it fits neatly into a UDP-FEC-based relay mechanism. The only difference is that we send it over UDP with FEC... This way, extra hops do not introduce more latency. Sadly, due to the nature of our FEC encoding, we cannot know if individual packets are a part of a legitimate, or any, block, and thus only enable this optimization between nodes run by the same group.
bitcoinfibre.org
The relay accepts communication from a set of miners, over the peer-to-peer or other protocol. The relay consists of a set of machines under the control of the relayer. It communicates the announcements within its internal network and eventually to the joined miners.
The important security observation is that communication within the relay is under the relayer's control. Due to the removal of denial-of-service protections central control is necessary to the scheme. The relayer can delay certain blocks based on miner, region, signal, non-payment, etc. A relayer sells reduced latency, and is therefore in the mining business. From a security standpoint it matters not if this service is offered for free. Miners may similarly offer grinders free reduced latency and variance.
Relays are aggregations of miners and miners are aggregations of grinders. The greater the hash power aggregation, the more profitable is the mine, as is the relay. One may consider that grinders are free to leave mines and miners are free to leave relays, and it is of course possible for a grinder to run his own mine and his own relay. But larger aggregations are more profitable, so leaving the largest relay or mine increases relative cost.
A theory holds that relays reduce pooling pressure. This is an error. Any pooling reduction caused by a relay does not disappear but is transferred to the relay as a pooling increase. Relay statistics are never presented alongside mining statistics, masking the power transfer. This leads people to believe that mining is less strongly-pooled than is the case. This may lead people to believe that mining is less strongly-pooled than is the case.
I don’t get the argument that a relay network centralizes mining similarly to a pool. You don’t have to commit to a single relay mechanism. Pools and miners can connect to one or more relay networks in addition to the open network without that influencing what they’re mining on. Participating in additional relay networks can only reduce overall latency.
This is a good point. A miner could listen to as many relay networks as they like, while they can only mine in one pool.
If a miner is connected to a FIBRE network and the open network, they still might experience centralizing pressure if the FIBRE network picks certain blocks to not relay.
eg. Imagine a FIBRE network only relays blocks for Cheater Pool and doesn't relay anything when miners who are not a part of Cheater Pool find a block. People listening to this FIBRE network will be more likely to build on Cheater Pool blocks as opposed to others because they learn about Cheater Pool blocks very quickly when Cheater Pool finds them. Obviously, this wouldn't be a very useful FIBRE network, and I imagine most miners wouldn't waste their time with it for very long. But if Cheater Pool represented a significant amount of hash power (40%?) it might make sense for a miner to listen to that FIBRE network. Wouldn't this tend to increase the profitability of Cheater Pool?
Now, if there is another FIBRE network that is relaying blocks from all miners, and lots of miners are listening to it, perhaps this is not the case. But isn't it the case that any given FIBRE network can't listen to all miners, but only a subset? Those miners who a popular FIBRE network receives blocks from will tend to produce less stale work than those miners who that FIBRE network does not listen to.
Doesn't the centralization pressure occur at the level of those miners to whom the FIBRE network is listening? Instead of becoming a benefit to mine with the biggest pool, it becomes a benefit to be feeding blocks to the biggest relay.
(I am far out on my limb of knowledge here, so please forgive me if I'm just saying inane things)
The efficient number of mining pools is.... probably about 1-3.
Resonated.
I wonder if there’s a way to design a system that actually makes smaller miners competitive without just creating a new ‘advantage hub.’ Ideas?
The idea is to give a playing field as level as possible to all miners, i.e., to reduce the advantage of larger miners as much as possible. There are some inherent advantages of scale, unfortunately, but minimizing latency is one that we can help with at network level.
It is impossible to give an advantage to small miners, as large miners could always operate as if they were multiple small miners.
As the Localhost Research post points out, Stratum v2 and DATUM might help because they make allow miners to construct their own block templates while still operating as a part of a pool.
But I think the Bitcoin protocol itself has kind of baked-in the problems with variance and latency.
Aren't we seeing these military grade facilities dropping mining in favour of AI?
If a large enough player pivots over to the new thing, won't that potentially decentralize the pie?
Insert difficulty adjustment slash hashrate, when AI bubble bursts, they'll come crawling back 😳
It doesn't seem to me like that many miners have been unplugged. Hash rate is down a little from all time highs, but it's still quite close.
I suppose we could link the sentiment of miners with bip110, ultimately we should see them signalling and as you say, there Isn't any.
Is that the beauty of viewing the protocol as an organism?
It's aliveIt's alive
This gets at something I think about a lot with mining economics. The variance problem is real and unavoidable — a solo miner with modest hash rate could literally wait years between blocks. Pools solve that, but you're right to worry about what comes next: if all the hash rate concentrates in a few large pools with centralized block selection, we've traded one problem for another. The promising angle here is that decentralized pool protocols like Stratum V2 let miners contribute hash to a pool while maintaining the ability to choose their own transactions. After years of tracking how mining incentives actually work, I think this is the real lever — not fewer pools, but pools where individual miners retain sovereignty over what gets mined. The pooling mechanism itself isn't the problem; centralized control over block construction is. The architecture matters more than the pool count.