Following the great article just released from Andrew Stone, one of the lead developers on Bitcoin Unlimited project, this is part 2 in the series of trying to encapsulate findings and opinions of the experts in the Bitcoin ecosystem in simple way.
Link to his full article contained within the summary below.
The lowdown:
  • CTOR (Canonical Transaction Ordering Rule), aka CTO (Canonical Transaction Ordering), aka Lexicographical Transaction Ordering, is a proposal by BitcoinABC development team to change the natural ordering of transactions in the blocks in Bitcoin.
  • BitcoinABC team proposes this will be beneficial to future scaling
  • Experienced and longtime Bitcoin developers like Andrew Stone and Tom Zander (ex-Bitcoin Classic developer, currently developing Flowee the Hub) argue that the approach proposed by ABC is unnecessary and potentially harmful/limiting to future development.
  • BitcoinABC team has included the "building blocks" of this in their latest release calling for a "network wide upgrade" in Nov, causing various criticism from respected developers like those named above, and some support from other developers like Chris Pacia (OpenBazaar and related wallet software) and Jonald Fyookball (Electrum Cash) alongside general confusion to some community members, miners, and businesses in the Bitcoin Cash community.
  • Two recent mining summits were held to gather individuals and businesses in the Bitcoin mining industry for discussions and workshops in Bangkok. One event was hosted by Coingeek, a large Bitcoin Cash (BCH) miner and media company, and one event was hosted by Bitmain, a large manufacturer of mining equipment who also runs some mining pools and has investments in exchange ViaBTC.
Technical arguments against CTOR (from Andrew Stone):
  • Graphene can accept multiple types of ordering. Not forcing a certain ordering now, keeps the possibility of continuing to exploring ordering that would help scaling, and Graphene can just be updated to use that when the time comes.
  • AKA optional ordering can provide that same purported benefit of CTOR, without concensus enforcement.
  • The sharding proposed by ABC (see doesn't work for light wallets (SPV and mobile wallets), which really defeats the whole purpose of Bitcoin Cash, when the focus is on the majority of users using lightwallets. Hence, a completely different sharding approach would need to be taken to solve this requirement.
  • ABC proposal ignores validation of transaction input. Andrew Stone concludes: "If this sharding scheme can handle the validation routing load, it can handle the top level routing of unsorted transactions. CTOR is therefore not necessary." (See his full explanation of how he came to this conclusion:
Criticisms against CTOR from others in development community:

What's happening right now? What's the panic? An opinion:
Nothing. Come November, miners in BCH will have to decide what implementation of Bitcoin Cash they support. Current outlook is: Coingeek pool will support Bitcoin SV implementation, along with BMG pool and SVpool (newly forming). Beyond that, much is unknown, as we will not know how much of the total SHA-256 hashpower really wants to be involved in Bitcoin Cash protocol decision making and will come online to do so. From the BTC side, there is a hefty price in the short term to enter into the minority chain due to the price difference between BTC and BCH, which means the scenario of "large BTC hashpower jumping over to BCH to decide on the protocol" is highly unlikely, unless there is an actor who has BOTH a large amount of hashpower, AND a reason to want to affect the result of the hashpower vote on the direction of Bitcoin Cash protocol development, AND is willing to possibly take a short term loss to try to affect this. So it narrows down the candidates for this.
Miners that do not want CTOR or ABC changes on BCH can sit back on BTC, or use any other implementation of BCH software if they mine BCH: Bitcoin Unlimited, BitcoinSV, BitcoinXT, etc. As ABC's changes are already unpopular, I would expect miners to act wisely and conservatively come November, and respect the various respected technical opinions that CTOR is unproven, unneeded, and that there are other ways to do what CTOR wants to do without consensus change.
There was a notable decrease in BitcoinABC nodes and an uptick in Bitcoin Unlimited nodes during the few days of user-driven stress testing which recently occured on the BCH network, where it was found that Bitcoin Unlimited nodes handled the largely increased transaction volume much better than ABC nodes (some new optimizations are currently only implemented on BU software, like Graphene block compression). Other software, such as Tom Z's multithreaded Flowee the Hub (in testing and not full release), was also reported to handle the transaction volumes from BCH stresstest well, alongside Neil Booth's ElectrumX servers. So currently, mostly software other than ABC is looking pretty fine. Also compatibility does not seem an issue, both XT and BU will remain compatible to the longest chain in the event of a split, in the event SV and ABC could be incompatible, whilst BU stance is basically against CTOR implementation, both in it's voting membership and several developers, like lead developer Andrew Stone, and Awemany, who provided one of the earliest indepth criticisms to CTOR, alongside chief scientist for BU, Peter Rizen.
Thanks for reading!
In the paid content, there is a ELI5 version of the last few paragraphs for just ground level "fork, no fork for Nov" explanation.


5 of 6 reviewers say it's worth paying for

1 of 6 reviewers say it's not worth paying for

  earned 10.0¢
Another nChain shill. Give it a rest.
   2wk ago