Craig Wright’s BMG Pool And CoinGeek Control 50%+ Of Bitcoin Cash Hash Rate
Based on the latest reports on Bitcoin Cash’s centralized mining, Coingeek and BMG Pool (both affiliated with Craig Wright) have reached a height of 58% of the pool now. Even though some investors believe that the cause of the increase could be variance, but the last week has reported 44% of the hashrate, so it is increasingly possible that the numbers are legitimate.
What is interesting about this circumstance is that, even with the affiliation, these pools are run by different entities. However, both Wright and Calvin Ayre (of Coingeek) are still close. That brings up another question – how likely is a 51% attack?
In the event of an attack, the only thing that these parties could actually do is spend their own coins at double the pace that they normally do. This might require the exchanges to make changes to confirmation requirements to keep up, but only if this circumstance continues to play out. Still, the most likely cause is an “intentional showing of ‘muscle’”, according to Trust Nodes. After all, Bitcoin Cash is getting closer to a fork in November, which could take the cryptocurrency to three different sections.
One of the chains could be Wright’s BitcoinSV coin, followed by BitcoinABC, and a “vanilla” chain that would cause any changes. If the split happens, the protocol in place dictates the that exchange would put a freeze on any type of withdrawal or deposit of BCH for a minimal of 24 before the split. The freeze would most likely last until 24 hours after the split, but it could go longer, if the issue remains active.
Wright and the nChain devs are the whole reason that a chain-split is even being considered at this point, since there seems to be concerns about all of the ABC proposals, despite being welcomed months ago. The biggest issue being discussed is canonical ordering (CTOR), which is a modification that would compress data to get better performance from the platform. Basically, it would afford the opportunity for both higher scalability and efficiency gains.
One miner-dev, Jonathan Toomim, commented on the BCH stress test that took place for this matter, saying,
“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.”
The concern is that the network seems unable to operate beyond 20MB blocks, due to orphan rates.
For those who are unfamiliar, a public blockchain sometimes involves separate miners discovering a block at a similar time, racing to see what can reach the chain first. For a small moment, this causes two chains, but the block’s addition to the chain basically ends the “race.” The faster miner posts the block, while the other one is discarded. That is why it is important for the chain to primarily have everyone on the same page.
When there are separate clients that have their own rules, like SV and ABC, they basically just mine their own chain and keep out of others. This prevents orphaning, because blocks that do not follow the same rules are deemed invalid.
“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.”
Both Wright and Coingeek are working on supporting a 128MB block size limit, even though the stress test revealed that the BCH network is grossly unprepared for that kind of work. If anything, it makes the proposal a ploy for publicity, since SV seems to be fairly against the notion.
Still, both parties now are in charge of about 50% of the hashrate, which should expose how the public blockchain can thrive or crumble, depending on how it is handled.