The BCH community over the past week has been a hot mess. A mass social media campaign continues to smear Craig Wright/nChain/Coingeek, spread misinformation and inject FUD about how the Bitcoin protocol truly works.
This all started when competing entities announced their new client to be released on November 15th - which are both incompatble with each other and will each require a hard fork.
Bitcoin ABC proposes two modifications, Canonical Transaction Ordering and the new op code OP_CHECKDATASIG.
Coingeek announced their new client to be released on November 15th as well - which also will require a hard fork. Bitcoin SV proposes to increase the DEFAULT (key qualifier here) max block size limit to 128 MB, re-implement original op codes that were standard in the Bitcoin Core client and expand the potential number of op codes that can be implemented in the future.
Currently in Bitcoin Unlimited and Bitcoin ABC the max block size limits are configurable - this means that the miners can set this value to be whatever they want to today. This renders all discussions and concerns about raising the block size as irrelevant as the miners are empowered to make this change without any central planning by developers or users (seem familiar?).
Of course, if a rogue miner sets their limit too high and others do not that miner will fork off of the network should they mine a larger block. The point is that the miners have the power to control how large the block will be that they will mine, no one else does.
Now let's the risk between the clients. Bitcoin ABC changes objectively are much more radical and invasive than the changes that nChain are proposing. I will not dive into technical details, only evaluate the risks and incentives.
Canonical Transaction Ordering - regardless of if this modification will scale BCH in the long run, implementing this today has a high-risk, a risk that is high enough to deter some more conservative miners from adopting the client. This modification could have negative implications on the network should bugs arise and potential issues could lead to miners losing money.
OP_CHECKDATASIG - I can see some cool functionality with this op code but am not informed enough to evaluate its risks. I will defer to User Jonald_fyookball, who wrote a nice, simple post explaining the op code here. Based on his post, this is low risk.
Bitcoin SV:
Restoration of original op codes - given that these were implemented in the original Bitcoin Core client, I believe the introduction of these to be fairly low risk. The intention allow more functionality to be coded in the Scripting language of Bitcoin. I can see incentive for miners to adopt this as the potential for more adoption of BCH is promising, and the low risk level is tolerable.
Increase default max block size to 128 MB - this change is almost irrelevant, given that I explained above in the article that this is already configurable. nChain developer Steve Shadders excellently explained this in detail and how defaults could be misinterpreted to be hard caps. Zero risk is involved by implementing this change.
Additionally - if we assume Steve is correct in stating that miners are unaware of the ability to raise the cap today, this client has incentive because potential for bigger blocks is an incentive for miners to make more money. Also, the post explains how nChain will make it easier to change this configuration in the client (a feature standard in Bitcoin Unlimited).
Now that we have evaluated the risks and incentives, let's summarize:
I believe the miners will have a greater incentive to mine using Bitcoin SV as the default cap is raised to 128 MB, potentially adds for more on-chain functionality via the restoration of original op codes. Comparatively to implementing ABC, the risk is much lower due to the unknowns of implementing Canonical Transaction Ordering.
Moving forward, let's evaluate the players:
ViaBTC has a decent amount of hash power on BCH and was recently called out by Craig Wright on Twitter:
Craig has been adamant that Bitcoin SV will not implement replay protection, meaning they fully intend to have majority hash power. If we assume nChain/SV pool/Coingeek will have majority, then any mining pool that decides to compete with Unlimited or ABC MUST implement replay protection.
We saw this scenario play out 1 year ago when BCH split - BCH was the minority chain therefore was forced to implement replay protection, otherwise would cause mass chaos.
I find it odd that ViaBTC would tell Craig to create an altcoin with only 8-10% of hash power, despite Craig stating that SV won't implement replay protection.
Bitcoin.com has been undecided, but given Roger Ver's skin in the game with BCH, he will be forced to join the majority chain.
Craig and Jihan have had spats on social media recently and Jihan holding 1 million BCH gives plenty of economic incentive for Jihan to follow the main chain instead of trying to fork off the network. Jihan/Bitmain clearly have huge skin in the game if not so much for the idealogical reasons like Roger Ver, but for financial reasons. Bitmain and Jihan will fold like a chair here and be forced onto the main chain.
Given the potential risks of adopting ABC, combined with the arrogance of nChain and Coingeek towards other mining pools (ViaBTC, Bitmain) and refusal to implement replay protection leads me to truly believe that nChain and Coingeek will have majority hash power on November 15th. This implies that any competing chain will be forced to compete with their client, fork into another cryptocurrency or join the SV chain.
The other major players in this space have too much skin in the game to attempt to compete for the BCH ticker, and will fall in line like soldiers as Bitcoin SV is providing the most economic incentives for miners to push Bitcoin Cash forward.
They are faced with a choice - take a chance to become unprofitable or join the path towards Satoshi's Vision.
 

0.0¢
23.0¢

Reviews
1 of 1 reviewers say it's worth paying for

0 of 1 reviewers say it's not worth paying for
Comments
  spent 5.0¢
> the miners are empowered to make this change without any central planning by developers or users (seem familiar?). This was conclusively demonstrated to be false with BTC. Miners were always in favor of increase the BTC blocksize. The reason they didn't is because the rest of the industry (exchanges, payment processors, users) mostly refused to run clients which would expect coins mined using larger blocks. So they never increase the blocksize. Miners do what users want, not the other way around. The only way you'll get miners to increase the blocksize is if the user base supports it as well and is willing to increase the max blocksize in their clients.
0.0¢
   3mo ago
5.0¢
  earned 20.0¢
> Zero risk is involved by implementing this change. Except the risk of a fork if users reject that max blocksize. And also except the risk of the network crashing if the max blocksize is raised to 128mb and a flood of transactions comes in. We know from experiment that the network crashes above 100mb. So how could it be zero risk?
25.0¢
   3mo ago
5.0¢ 25.0¢
  earned 0.0¢
@Chris Pacia - I disagree that this is the case this time. The miners were tricked into thinking they had no power, that they are at the mercy of the developers. They have the power to change it if they want. Who cares what some holder of BCH says? They are not mining, therefore they have no say in what the max block size should be. If they want a say, they can pay for the mining equipment and compete. Furthermore, the only reason that was false with BTC is because the limit was hard-coded in the actual software, not configurable as it is now. Only way to change would be via hard fork before. Now the same applies with a hard fork, but the miners can agree to do this themselves without influence from non-miners.
If all the miners decided to do so, the users/exchanges have no choice but to fall in line, or support another coin. Most BCH supporters are BCH maximalists and do not want to see another split. We are about to witness this on November 15th.
Also, could you provide a source on the experiment crashing at 100 MB?
0.0¢
   3mo ago
  spent 5.0¢
Will the ramp-up test conclusions at the Satoshis Vision conference do as a source for why 100mb is stil broken?
0.0¢
   3mo ago
5.0¢