Big bitcoin mining pools are not a centralization risk
Why large mining pools aren't a realistic vector for 51% attacks from the perspective of a mine operator.
In early January yet another article came out trying to make the case that large mining pools pose a centralization risk to Bitcoin. I saw it in a tweet, replied that I thought it was off-base, and was asked by someone to write a Substack explaining why.
My issue with it was that it was not reflective of the facts around how mining pools and mine operators interact. It also mischaracterized the role that Bitmain and Foundry play in our industry, but I’m not really interested in spending time debunking that because it’s largely irrelevant to the more important point here.
Rather than try to talk in very sophisticated or abstract terms that are likely beyond my technical understanding of how Bitcoin Core works, I’m just going to speak from the perspective of a miner. I’ll define the contours of the debate, the central risk people are concerned about, and then walk through step by step how easy it is for large miners to change pools to demonstrate how low of a risk there is of any one pool amassing more than 51% of global hashrate.
To be clear, there are likely other concerns around centralization that have more to do with the social layer of bitcoin rather than the infrastructural layer. The Block Size Wars and the attempt by a few major exchanges and miners to force a protocol change against the consensus of the economic majority (full node runners) is indicative of this concern, but this is not where I am focused today. I am focused solely on the centralization risks and mitigations strategies at the interaction between the infrastructure layer of bitcoin (steel in the ground, ASICs in racks) and the bitcoin core protocol. Let’s dig in.
Here is the key line in the article that gave me pause:
“However, Bitcoin’s centralization is a problem that concerns the entire market, especially now when only two mining pools produce the majority of its blocks.”
The implication here is that two mining pools producing over 50% of the blocks (per the author, Antpool and Foundry were responsible for 51.48% of block production since mid-December) means that Bitcoin is somehow “centralized.” Though she never really defined that term, one can infer that she is primarily concerned about the centralization of governance decisions and the risk of a 51% attack. Most miners are not concerned about this for reasons we’ll get into, but I think there is still some confusion amongst the broader population of bitcoin users and watchers, so I think this is an important discussion to have.
A note on the governance structure of bitcoin
It’s beyond the scope of this article (and frankly my own technical expertise) to get into the technical specificity of bitcoin core protocol governance. Suffice to say that the main governance stakeholders are miners and full node operators (known as the economic majority). Both can, in their own way, signal support for changes to the consensus rules (rules around how transactions are structured, what data can be contained in transactions, changes to block size limits, etc.) which can lead to “soft forks,” or backwards compatible changes to the protocol that (in theory) tighten up the rules and make the protocol better. For different Bitcoin Improvement Proposals (BIPs, the code-changes that ultimately lead to soft-forks if they are voted in), there are typically different super-majority consensus thresholds that need to be met before they are implemented.
There are two general categories of soft fork: A miner activated soft fork (MASF, e.g. miner-controlled), and a user-activated soft fork (UASF, e.g. a full-node or economic majority-controlled). To egregiously over-simplify, MASF are generally more common, and typically require a 95% super majority of miners actively “signaling” support for the proposal in order for it to be activated. You may remember reading headlines of miners signaling for Taproot back in spring 2021. This was essentially miners voting support for the Taproot BIP by injecting a unique and agreed upon piece of data into the block templates they mine on.
When the miner (or most likely, mining pool) wins a block, their template gets appended to the longest chain, and thus they effectively “signal” their support. In the image above, the green blocks are blocks that contain the signaling data in support of Taproot.
UASF, on the other hand, is the “coordinated activation of a bitcoin soft fork on a specified date enforced by a super majority of full nodes rather than relying on miners alone.” In the past, a UASF was successfully carried out to activate the P2SH soft fork (BIP16), but they are less common than MASF.
Both UASF and MASF require super-majorities (in all cases I’ve seen well above 80% consensus). For this reason, it is unlikely that a single actor could ever amass enough control over either the mining network or the economic majority of nodes to threaten governance. It is a valid concern that a cartel of pools could form that could come close to the 95% threshold, but still quite unlikely. The largest risk of concentration/centralization with the lowest threshold for impact has less to do with abuse of governance and more to do with fundamental chain security. This is the 51% attack, which is where we’ll focus for the rest of the article.
What is a 51% attack?
A 51% attack on Bitcoin is a theoretical scenario where a miner (most likely a mining pool, for reasons we’ll get into) controls more than 50% of the network's mining power. With this much control, they could manipulate the network in several ways:
Double Spending: The attackers could use their control to confirm fraudulent transactions and revert legitimate transactions, allowing them to spend the same Bitcoins multiple times.
Block Reversion: The attackers can choose to not confirm valid transactions, effectively reversing already confirmed transactions and causing a disruption to the network.
Alternative History: The attackers can create a new version of the blockchain that excludes certain transactions, essentially rewriting the history of the network.
The idea behind a 51% attack is that with enough mining power, an attacker could manipulate the block reorganization feature of PoW networks that is designed to clear up incidences when two miners have mined the same block. When this happens, the system normally reverts to the longest chain as the “valid” chain. In a 51% attack, however, the attacker could mine “faster” than the rest of the honest miners on the network, creating a longer chain and tricking the system into rendering the honest miners’ block invalid.
Bitcoin has never suffered a 51% attack, but we can glean insights as to what would happen by looking at attacks on other blockchains. In July and August of 2021, the Bitcoin-forked cryptocurrency “Bitcoin Satoshi Vision” (BSV) suffered five separate 51% attacks. The attackers re-org’d the chain, creating multiple chain tips and sewing confusion amongst node operators as to which was the valid chain. During the last of the attacks in August, hashrate dropped over 50%, though it’s not clear whether this was due to miners leaving the network or because miners were mining on two separate chains (the “honest” and the “dishonest” chain), leading to block explorers seeing a significant decrease in overall block production.
Although there is certainly a direct economic cost to a 51% attack, they are expensive and difficult to maintain for any extended period of time (even on tiny irrelevant chains like BSV). The real danger comes from the reputational damage that comes to a chain that is successfully attacked. No one really takes BSV seriously, but Bitcoin’s reputation rests on the fact that in its 14 years of existence it has never once had a security breach of this nature. Its security is as important as its scarcity for the value proposition that it is relying on to drive adoption. A successful 51% attack would call this security into question, and it is unclear whether Bitcoin’s reputation could survive. This is why it is of such concern.
The cost and logistics of a 51% attack
At the block height of this writing (775,039), Hashrate Index estimates network hashrate at around 278 exahash per second (EH/s) on its 3 day SMA chart:
To put into perspective how expensive and logistically challenging it would be to execute a 51% attack at the infrastructure layer (the world of power generation, steel in the ground, hundreds of thousands of ASICs, hundreds of miles of cat6 cable, etc.), consider the following statistics around what 139 EH/s would look like and cost (the rough amount to reach 51% of the network at today’s hashrate).
The following rough calculations assume:
Bitmain S19J Pro (100TH/s) ASICs
Current average market price for ASICs at $15/TH
All-in infrastructure and EPC cost per MW of $600,000
All-in cost of electricity of $40/MWh
100 MVA high voltage transformers
3750 KVA low voltage transformers
Facility PUE of 1.05
36 ASICs per PDU and network switch
55,000 square feet of building space per 100MW of mining.
So, in order to build your way into a 51% attack you would need roughly $5B in infra CAPEX, $5M/day in power OPEX, and a supply chain unlike anything in existence today. For example, current lead times for high voltage transformers (50-100 MVA) is over a year in most cases for individual or small (single digit) orders. At this scale, it would be years, and if you tried to rush it you’d experience such extreme upward slippage on price that you’d immediately cost yourself out. Same theory applies for the massive amount of low voltage transformers, PDUs, and switches.
A separate infrastructure layer strategy could be to go out and try to acquire 51% of the existing physical network hashrate by buying up mining operations. Think through the logistics of this for a second (finding the mines, contacting management, term sheet negotiation and closing DD, running that many distributed teams, etc.) and then put this idea to rest in your mind.
The point I’m making is that long ago when Bitcoin entered the age of the ASIC, a physical infrastructure approach to the 51% attack became all but impossible. Which has left mining pools, the global aggregation points of bitcoin hashrate, as the most likely and maligned potential threat vector.
Hashrate distribution and control over time
So why am I not concerned about large mining pools and centralization? Just watching Foundry’s ascent alone in the last years seems like cause for concern, doesn’t it?
This is Pools Dominance data from the Mempool app on my Umbrel node, which shows share of global hashrate by pool over the last 12 months (even without a node, you can access the same data on a web browser here). The bottom band in red is Foundry USA Pool, which seems to be slowly creeping up towards 40% of network hashrate. This is a rough look at average percentage of blocks mined, and shows growth (or decay) over time for each pool.
For a more instantaneous look, we move to the Pools Ranking data on Mempool. You can sort temporally, so we’ll click on Pools Ranking for the last 24 hours, which shows the percentage of blocks mined in the last 24 hours by pool:
As you can see, in the last 24 hours Foundry USA mined roughly 30% of the blocks, or roughly 44 of the last 144 blocks mined. A quick side note here - this is why you need to be careful to understand the data you are looking at when you are trying to understand pool data: The length of the look back period will determine which pool shows which share of the blocks mined, because of the probabilistic nature of mining. For example, using the same data from my node but extending the look back period out to 1 year, we see a very different picture:
Here, Foundry looks less dominant, and we start to see other name-brand US pools like Luxor on the list. This is because we are now looking at roughly the last 52,500 blocks mined, which is much more accurately representative of hashrate distribution over time.
Still, to go back to the question of hashrate centralization risk at hand, the most relevant metric is the 24 hour data because this shows the distribution of global hashrate in near-real-time. This, in turn, is a good data proxy for whether we are getting danger-close to the 51% threshold of hashrate control in any 24 hour (144 block) period.
The negligible switching cost of changing pools
If you were to go into a good industrial scale mine, you would likely see several large screens in their Network Operations Center (or Control Room if you’re mine is connected to a power plant) displaying a series of dashboards. This is how we run the mine: We ingest data from a variety of physical and virtual sensors, display that data on a series of dashboards configured to the specific design requirements of the mine, and then make operational decisions based on that data in real time. If miners in a certain section seem to be slow in responding, we know we probably have some kind of a network issue and we go out to investigate. If we see hashrate drop in a certain zone, we likely have a PDU that just dropped, a series of intake fans that dropped, etc.
One of the screens on the dashboard of a large mine (running a material share of the network) would almost assuredly be the 24 hour Pools Ranking chart shown above, pulling data from an on-prem node run by the mine operator (so we can be sure the data is not being tampered with). This would live on one of the many screens in the Control Room and the mine operator would be passively monitoring it to see if any one pool looked to be creeping up towards the 51% threshold. In the event that this looked to be the case, or if news broke on Twitter or any of the myriad Discord or Telegram channels miners love to hang out in that pool dominance was nearing a dangerous threshold, the mine operator would immediately take action. And this gets to the mechanics of why I’m unconcerned with large (30-40% market share) pools.
From the time the alarm went off, it would take a good mine operator running a good mining management software platform like Foreman.mn a rough maximum of one hour to successfully switch the entirety of their hashrate to a fail-over pool (which presumably would be non-dominant). All prudent miners are onboarded with multiple pool operators and have multiple stratums from different operators configured into all their ASICs to insure against a single pool stratum being DDOS’d, etc. To illustrate just how truly easy failing over to a different stratum is, I’ll walk through it step by step below, with indicative time stamps assuming an 8:00am shift change time.
8:00am: Shift-lead identifies hashrate centralization threat using on-prem node Mempool data during shift change-over brief
8:01am: Shift-lead notifies on-call system administrator of hashrate centralization threat per Operational Policies and Procedures handbook
8:04am: System administrator validates centralization threat on his own node, and then initiates Change Pools protocol
8:05am: System administrator logs in to the mine’s Foreman dashboard at Foreman.mn
8:05am: System administrator remotely initiates Change Pools protocol by first navigating to the Foreman Pickaxe agent that enables direct remote control of all miners configured to it
8:05am: Clicks the gear drop down on the top right, and then clicks “Show Miners,” navigating to the list of all miners configured to that PickAxe
8:05am: Clicks “Bulk Edit Miners” button to enable selecting all miners
8:06am: Selects all miners, and then clicks “Edit”
8:06: Clicks input field labeled “Choose items to edit for selected miners” and then clicks “Change Pools (Remote)”
8:07am: Inputs fail-over pool stratum URL, pool username, and pool password into the appropriate fields
8:08am: Double checks all data is correct
8:08am: Clicks “Apply” and then “Yes” when prompted for verification of change
8:12am: System administrator verifies Change Pools command was received by spot checking a handful of individual miners on selected PickAxe by navigating to “Miners” tab, clicking “Actions” next to an individual miner, clicking “Details”, and scrolling down to identify the “Active Pool” for that miner.
At this point, if the mine is running only one PickAxe, the Change Pools protocol is complete and the mine is no longer submitting hashrate to the pool that poses the centralization threat, effectively contributing to the mitigation of that threat. If the pool is large and running multiple PickAxes, steps 5 and 6 would be repeated for each individual Pickaxe, adding roughly 7 minutes to the process. For a mine running 8 PickAxes, one could expect it would take roughly one hour to fully execute the Change Pools protocol.
Concluding thoughts
Miners are very sensitive about their hashrate. It’s not unreasonable to think that major mine operators (e.g. running greater than 1% of network hashrate, or around 3 ExaHash) around the world would have a similar protocol in place as the one described above. Though they may seem reclusive to the public, they are also social beings that coordinate quite closely in closed Telegram channels, and it would be highly likely that any type of pool centralization threat would be identified early in these social channels by the first miner to notice it. A call would go out and we would all change off of the large pool in question.
Unfortunately for our heroic pool operators that provide such a valuable service to miners and ensure true hashrate decentralization, mining pools are largely commoditized at this point. The major mining pools all provide more or less equivalent services and products, with some notable exceptions (e.g. Luxor’s hashrate NDF and RFQ platform are examples). But from a pure pool perspective, pool fees are going to zero because there really isn’t any differentiation, which means it’s very easy and almost zero cost for big miners to switch back and forth between pools. Although this sucks for pool operators, it is actually an important feature of the bitcoin network that is helping to ensure adequate decentralization and hedge against a pool-derived 51% attack.
At the end of the day, there are many risks to the decentralization of the bitcoin network, but from where I’m sitting, pool dominance is not one of them. I would love to hear feedback as to why I’m wrong - I am always willing to revise my views in light of new information, so please let me know if you think I’m off-base here!
Thanks for reading.