Over the past few weeks, Bitcoin Cash supporters have been debating the upcoming hard fork scheduled for November 15th of this year. Most of the community understands, that as of right now, there are two camps that have entirely different visions. It doesn't seem like a compromise is coming any time soon. Lately, as each day passes and as time draws closer to the upgrade, both disagreeing parties have been testing certain features and publishing various papers concerning the theoretical effects of specific upgrade additions.

The November 15th Upgrade Debate Continues

Right now is probably a pretty confusing time for a few people just learning about the disagreement taking place concerning the scheduled November 15, 2018, Bitcoin Cash network upgrade. Currently, there are two camps that disagree on which features will be added to the hard fork this November — The Bitcoin ABC development team and the clients' supporters, and the Nchain development team and the Bitcoin SV clients' crew of proponents.

The Bitcoin ABC development team wants to add an opcode called OP_CHECKDATASIGVERIFY (DSV) that aims to improve BCH scripting, canonical transaction ordering (CTOR), and some minor technical fixes and improvements.

The Nchain team and it's BCH full node client called Bitcoin SV wants an entirely different set of features. Bitcoin SV's upgrade list includes a 128MB block size increase, add the opcodes:  OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT, and remove the limit of 201 opcodes per script.

At first, the most vocal person against the Bitcoin ABC proposals was Nchain's chief scientist Craig Wright. However, there are many others who support the idea of Bitcoin SV and the blockchain, and mining firm Coingeek had decided to support Nchain's idea from the beginning. Since then Nchain has released its alpha version codebase, started a Bitcoin SV mining pool so people can direct hashrate to the client, and both the mining pools Coingeek and BMG Pool (Nchain's hashrate) have managed to capture 46.2 percent of the global BCH hashrate over the last seven days.

Bitcoin Cash Proponents Argue the Pros and Cons of Canonical Transaction Ordering

There have been so many arguments for and against some of the features the two camps are promoting. For instance, there have been lots of conversations in regard to adding CTOR and plenty of discussions against the idea. Andrew Stone wrote a critique about CTOR on September 7th called "Why ABC's CTOR Will Not Scale." Coingeek has published opinions against adding CTOR in a post two days ago. The Coingeek post also leads to another critical evaluation of CTOR by the Reddit user /u/awemany and the BCH developer Tom Zander.

On the other hand, Electron Cash developer Jonald Fyookball wrote a case for adding CTOR to the Bitcoin Cash protocol this week. Of course, early on Bitcoin ABC has published some opinions as to why the development team believes CTOR should be added to the BCH codebase. Another post on r/btc, written by Mark Blundeberg, gives a comprehensive technical dive into canonical transaction ordering, and the BCH mining pool Rawpool has also given an objective evaluation towards CTOR. The Bitcoin Miner Jonathan Toomim also added some information to the mix with his block propagation data that stemmed from Bitcoin Cash stress tests that took place a couple of weeks ago.

"During the stress test, blocks propagated through the non-China mainnet at around 300–1000 kB/s — This is pretty slow, and would cause problems with orphan rates if block sizes were frequently larger than 8 MB unless we improve our block propagation algorithms," Toomim explains in his recent post.

The Pros and Cons Concerning the OP_Code CHECKDATASIGVERIFY or DSV

Then there are many discussions concerning the OP_CHECKDATASIGVERIFY (DSV) feature Bitcoin ABC wants to add. Nchain's Craig Wright says that "DSV opens many issues" and others have disagreed with the idea of adding DSV as well. One Github repository details another option the community could use instead of DSV called recursive smelting. Then Nchain's senior researcher Owen Vaughan recently published a paper called "Rabin Signatures in Bitcoin Cash." The paper posits the belief that "arbitrary messages can be signed and verified directly in Bitcoin Cash script without introducing new opcodes."

Mark Blundeberg has written another extensive post that shows the benefits of DSV called "'Pay To Identity' — a proposed use of OP_CHECKDATASIG." Moreover, another post published on Yours.org by a writer named Perica argues that DSV is already in the codebase, and has been there since the creation of the Bitcoin version 0.1 release. Perica's paper claims the current DSV model, that's already baked into the original code, is a "more powerful form than the one proposed by various developer teams."

Bitcoin Cash Supporters Have so Much to Discuss Over the Next Few Weeks Before the Fork, and Anything Can Happen Between Now and Then

There's been so much to discuss its hard to believe the fork will happen this November but right now both camps seem pretty adamant an upgrade will take place. Further people can stay rather neutral and run either Bitcoin XT or the Bitcoin Unlimited clients, as those teams plan to allow the decision to be ultimately made by majority hashrate. There's also a lot of bickering between community members over the 128MB increase and whether or not the chain should upgrade the block size now. The stress test, although remarkable, offered insight to some of the problems (block propagation times & bottleneck) introduced by exceeding blocks larger than 8MB. However, a slew of big block advocates believe the network can handle super large blocks and some think the limit should be removed entirely.

In order to keep our readers informed over the course of the next few weeks leading up to the November 15 upgrade, news.Bitcoin.com is sure to be there every step of the way.