Hi, Pablo here
+ ++
How much hashrate does a fork chain need?
+Published: 2026-10-25
+ ++ Ever since the BIP-110 chain failed, a few concerns have been bouncing around in my head (to be clear, they have + nothing to do with the ideas behind BIP-110). What caught my attention was how it + failed, and what that says about the power miners hold over Bitcoin now. +
+ ++ This post is the current state of my thinking. It is work in progress, and I'd love to be told where I'm wrong. +
+ +BIP-110 tried and died
+ ++ When BIP-110 split off, its chain got so little hashrate that not even the fanatics stayed for + long. It mined 8 blocks and was definitively abandoned within 20 days. On the first day, poolcoin + (I'll call "normal" Bitcoin that for fun) already got ahead significantly. By day 3 it was pretty much a closed + case. +
+ ++ The interesting part is that this behaviour was very decoupled from the social acceptance of BIP-110. BIP-110 + was far from any majority of proactive support, but I personally estimate somewhere around 5-20% of the network + was supportive of it, and the rest was mostly neutral. But its brutal death after the chainsplit was not + reflective of this. Why didn't all the fanatics stick around? Because there was no shortage of them. We know + because now they've all moved on to Blakecoin. Those guys were willing to run BIP-110 to the ultimate + consequence of splitting from the world, but still, they left the BIP-110 chain. Why? Because the chain was + simply unusable: +
+-
+
- blocks took days to arrive, not minutes, and +
- the difficulty adjustment that could have fixed that sat years in the future. +
Believers walked away from the chain they believed in, because using it was impossible.
+ +What actually concerns me
+ ++ That episode made something concrete for me: hashrate is decoupled from nodes and users, and + hashrate (or the lack of it) can be used to make a chain unusable, whatever its users think of it + ideologically/politically. +
+ +Put that together and you get a loop:
+-
+
- Low hashrate → long blocktimes, and a long wait for the difficulty adjustment. +
- Long blocktimes → the chain is too slow to transact on. +
- Too slow to transact → users who hold and depend on bitcoin leave the chain. +
- Fewer users → less reason to mine it → even less hashrate. +
+ Mining is heavily centralized in a handful of pools. That means a mining cartel could trigger this loop on any + chain it chooses to starve. +
+ +So I set out to answer some questions with numbers:
+-
+
- + In a chainsplit, how does a chain's share of hashrate affect the experience of the people + using it? What counts as "too little" hashrate, and what counts as "too long" a blocktime? + +
- + Given today's mining pool concentration, which combinations of pools have the power to keep + a fork chain alive, or to kill one? + +
Why a minority chain is so slow
+ +
+ When a chain splits, both sides keep the difficulty they had at the moment of the split. Suppose one side ends
+ up with a share h of the hashrate. Then:
+
-
+
-
+ Blocks arrive
1/htimes slower. Half the hashrate means 20-minute blocks; a tenth means + 100-minute blocks. +
+ -
+ It stays that slow until you mine 2016 blocks, the next adjustment. At
1/hthe usual speed, that + takes14/hdays instead of the usual two weeks. +
+ - + Even then, relief is partial: each adjustment can cut difficulty by at most 4×. A very weak + chain needs several adjustments, each one arriving sooner than the last, before it is back to 10 minutes. + +
Here is what that looks like:
+| Hashrate | +Time between blocks | +First adjustment | +Back to 10 min | +
|---|---|---|---|
| 50% | +20 min | +28 days | +28 days | +
| 25% | +40 min | +56 days | +56 days | +
| 10% | +1.7 hours | +140 days | +175 days | +
| 5% | +3.3 hours | +280 days | +1.0 years | +
| 1% | +16.7 hours | +3.8 years | +5.1 years | +
+ + The second column is what hurts, and the third is for how long it's going to hurt. Things become worse given + the importance of expectations: if users think a chain won't be usable in the future, even if it's barely + usable now, they will drop it anyways due to expectations, which triggers a doom loop. +
+ +Who uses the chain, and how long will they wait?
+ ++ "Usable" means different things to different people, so I modelled three personas, each with a tolerance for + how long they're willing to wait for a transaction to reach 3 confirmations, which for + simplicity we will define as settled. +
+| Persona | +Who they are | +Will wait for 3 confirmations | +
|---|---|---|
| Hodler | +Holds, rarely moves coins | +1 week | +
| Medium of exchange | +Pays and gets paid | +1 day | +
| Institution | +Settles business on a schedule | +3 hours | +
+ Since block arrival is random, a wait isn't a single number but a distribution. Sometimes you get lucky, + sometimes you don't. I settle that with a service level: at p90, 90% of a + persona's transactions must reach 3 confirmations within its tolerance. On the regular 10 min schedule, that p90 + wait is about 53 minutes (read as: 90% of times, you will see three blocks confirmed in under + 53 min). +
+ +Assumptions
+ +To keep this tractable, I assume:
+-
+
- 3 confirmations count as final. +
- Static hashrate: each side keeps its share of hashrate for good. +
- + Empty mempool: no fee competition, no queueing. This is the best case scenario: if you start + facing a clogged mempool, waits would be even longer for some. + +
- + The split starts at the beginning of a difficulty period, so the minority chain has a full + 2016 blocks to grind through before any relief. Note that changing this can greatly influence the delay to the + first difficulty adjustment, but I won't explore this further since for now it seems canonical that fork + activations happen on the start of difficulty periods. + +
- + Out of scope: introducing the effects of hard forks of any kind, or more generally anything + that tampers with the difficulty adjustment. + +
The numbers
+ +
+ Turning tolerances into hashrate is simple division. If a persona tolerates waits k times longer
+ than mainnet's, the chain can be k times slower, so it needs 1/k of the hashrate. This
+ is the share of total hashrate a chain needs to keep each persona on it:
+
| Persona | +Tolerance | +p50 | +p90 | +p95 | +
|---|---|---|---|---|
| Institution | +3 hours | +14.86% | +29.57% | +34.98% | +
| Medium of exchange | +1 day | +1.86% | +3.70% | +4.37% | +
| Hodler | +1 week | +0.27% | +0.53% | +0.62% | +
+ Institutions are demanding: a chain needs roughly 30% of all hashrate before they'll use it. Everyday spenders + need under 4%, and hodlers need about half a percent. +
+ +Defensive coalitions: who can keep a fork chain alive?
+ ++ Now map those bars onto today's mining pools. If a group of pools wants to keep a minority chain usable, how + many does it take? +
+| Persona | +Needs | +Smallest coalition today | +
|---|---|---|
| Institution | +29.57% | +2 pools (e.g. Foundry USA + AntPool) | +
| Medium of exchange | +3.70% | +1 pool (any of the top 7) | +
| Hodler | +0.53% | +1 pool (any of the top 14) | +
+ A single mid-sized pool committing to a chain is enough to keep it usable for hodlers and everyday spenders. A + couple make it workable even for the hypothetical institutions. +
+ +Offensive coalitions: who can force users onto a softfork?
+ +Now flip it around, because this is the scenario that worries me.
+ ++ A coalition of pools activates a softfork that users don't want. The users reject it and stay + on the chain without it, or even push for a URSF. That chain is left with whatever hashrate the coalition didn't + take. If that falls below the users' bar, the chain they want becomes unusable by their own standards, and + they're forced to either jump across to the cartel softfork, or hardfork away like the Blake boys did. +
+| Persona | +Softfork side must hold | +Smallest coalition today | +
|---|---|---|
| Institution | +over 70.43% | +4 pools (the top four, 72.34%) | +
| Medium of exchange | +over 96.30% | +11 of 18 pools | +
| Hodler | +over 99.47% | +14 of 18 pools | +
+ + If you consider AntPool to actually be AntPool and friends, then you only need the three top pools today to bend + institutions into a softfork, which you could argue already creates enough gravity across miners and users that + everyone will end up in the softfork chain. +
+ +The scenario that scares me
+ +Here's the nightmare, using the numbers above:
+-
+
- + Foundry, AntPool & friends, and F2Pool, about 72% of hashrate between them, sponsor a softfork that sets + the minimum fee to 5 sat/vB. + +
- + They go hard on propaganda: "stand aside, lady, it's for the security and future of the network." + +
- They set a short deadline that barely gives the community time to react, say four weeks. +
- + The rest of the network doesn't want this. But the rest of the network doesn't have the hashrate to keep a + user-activated chain usable, at least not for anyone who needs transactions to settle within hours. + +
- + For most users, paying 5 sat/vB is a lesser evil than risking the run-for-your-life scenario of jumping into a + hard fork (to make matters worse... which one?). And staying in the "old" chain is not feasible since it will + die starved of hashrate. + +
+ Nothing in that scenario requires breaking Bitcoin's rules. It only takes a few pools agreeing with each other, + and the loop from the start of this post does the rest. It's a fuck up in Bitcoin's design, and as far as my + knowledge goes, it's been here since the chain got started. We're just starting to see it emerge now. +
+ +The solution
+ ++ I have no solution for this. It somehow feels all the forces are pointed at making this worse. The only "happy + scenario" is Bitcoin gets slowly destroyed like email did, we lose all the usefulness it was giving us, and + we're back at square one. The community with the ethos (supply capped, permissionless, decentralized freedom + money) needs to start from scratch with some new coin/solution, with all the challenges that come with it. We + could be locked in fiat hell for decades before we pull it off. +
+ +Or perhaps the Blake boys will somehow make it. I have little faith but I wish them the best.
+ +Code
+ ++ You can find the repo where I worked this out here. +
+ ++ +