i just wanted to say that from everything i've read, i don't have a problem with CTOR; esp if it helps Graphene in regards to propagation. it's just that my priority has always been removal of the block limit.
I like the idea too, But given what has just happened with the
CVE-2018-17144 bug the following to principals seem more valid now than just a day or two ago.
1) If it is not broken, don't fix it.
The above-mentioned vulnerability was made for an inconsequential benefit it introduced unnecessary risk. Unlike the 1MB transaction limit, resisting change to drew a lot of attention, the result is lots of attention was focus on the ramifications of changing it. By the time it came to change it the externalities were fairly well understood. Even in the face of a hostile takeover, the contingency plan of a minority fork had been aired and discussed and understood for well over a year before it became necessary.
It is my view that consensus rule changes should get this type of attention. Only efforts should be undertaken to avoid censorship and the banning of discussing competing ideas.
2) Regular Hard forks introduce unnecessary risk.
Forcing regular Hard Forks almost guarantees a homogenous monoculture, leaving the entire network vulnrable to an unintended bug.
The negative consequences of the above-mentioned bug were minimized by having older versions of the software running that had not adopted the change. The bitcoin Core network would probably have detected the bug had it been exploited as many older versions of the software were supporting the existing social contract.
Should a change be made to the network while everyone is forced to adopt it, redundancies are lost. ABC, in my view, is proceeding recklessly, 1 by introducing new hard consensus rules and 2, forcing universal adoption via scheduled hard forks.
Had BU reindexed off ABC or Core to stay current this bug would have affected BCH in that
it could have been exploited with impunity, because of the nature of hard forking. Core would have detected it because there are some faithful BU nodes running on the BTC network who don't follow core. Not to mention it was found because of the differences.
I had a brief chat with
@Mengerian who gave me a quick history lesson on the OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY, the OP code development process being rather political and inefficient, and the cause of some frustration. Origination with
@theZerg reevaluated and rebuilt by ABC, and then coming back to BU to implement by
@awemany.
I'm forced to acknowledge the most efficient path is not the efficient part given what was uncovered doing it the inefficient way, it made for the most efficient resolution to the
CVE-2018-17144 bug.
