Bitcoin Cash mining centralization has now reached the point where just two pools currently control precisely 50% of the hashrate (pictured above).
According to reports, the Craig Wright affiliated Coingeek and Wright’s BMG Pool reached as high as 58% at some point today.
This considerable increase in hashrate may be due to variance, but even for the past seven days the two pools controlled 44% of the hashrate, which may now rise further.
As far as we are aware, the two pools have different operators, but Wright and Calvin Ayre of Coingeek are fairly close, so collusion and an intentional 51% attack can be on the cards.
In that situation, all they’d be able to do is double spend their own coins, which might mean exchanges may start increasing confirmation requirements for BCH as long as this situation continues.
This new hashrate, however, is probably intentional showing of “muscle” as Bitcoin Cash nears a November fork which may split the currency potentially into three.
On one chain there may be Wright’s own BitcoinSV coin, then the Bitcoin ABC chain, and then there might be a “vanilla” chain that makes no changes.
Exchanges will of course freeze BCH deposits and withdrawals at least 24 hours prior to such split and at least 24 hours after, but in this case it may be until the situation resolves.
This chain-split is on the table because Wright himself and his nChain devs are taking issue with all of ABC’s proposals. That’s after nChain publicly welcomed the ABC proposals in spring.
The chief matter in dispute is canonical ordering (CTOR). That’s a highly technical modification aimed at further compressing data for efficiency gains and higher scalability.
“86% of the data that Graphene without CTOR needs is for transaction order information, so if we fork in CTOR, Graphene will be able to get ~700x compression, or 28x better than what we currently have.”
Interestingly, Toomim finds the BCH network can not currently operate above 20MB blocks without it collapsing into a centralized coin with just two pools. That’s because of orphan rates.
As you may know, now and then in public blockchains, different miners find a block at close to the same time, with a race then developing as to which block makes it into the final chain.
For a brief period of time, therefore, there are effectively two chains, but the next block that is found effectively ends the race in most circumstances because that extends one chain, which becomes the longest chain. The other one is effectively discarded, with the block orphaned.
It is in these sort of situations where all are running the same rules that hashpower decides. Where miners however are running different clients with different rules, say SV and ABC, then they just ignore each other and keep mining on their own chain.
There is no orphaning as blocks mined by different rules are automatically invalid. Nor can hashpower change the rules nodes run. It can only determine which is the longest chain within the rules of the nodes.
Because of this orphaning within the same rules, there are some technical limits as to how much data can be processed while maintaining a decentralized network. Toomim says:
“Unfortunately, 128 MB blocks are not at all reasonable at this point in time. They would likely take around 250 seconds to propagate, which would result in orphan rates of about 34% and a 7–10% overall revenue advantage for large pools like CoinGeek.”
Wright and Coingeek are planning to increase the blocksize limit to 128MB in their SV client, even though the BCH network could not really go much beyond 20MB in the stress test, with about 2 million transactions processed.
Which suggests the 128MB proposal is probably more of a gimmick, with SV really being more against things than for things.
Yet with them now controlling 50% of the hashrate, and with Wright seemingly being hostile to the main BCH client and other miners, we may soon find out just how well public blockchains operate under adversarial or hostile conditions.