I wrote this originally as a comment on Jonald's report, but then I noticed he's set a ridiculous $20 fee for comments (to avoid criticism?). So I thought I might as well make a new post instead.
Thanks for the report. Here are my opinions on some things (quoting Jonald):
When pushed, nChain was unable to give objections to OP_CHECKDATASIG,
I think the burden of proof when adding new stuff should be on the ones who want to add it, not on the ones who oppose it. BCH should be made stable by locking the protocol.
stating that they had not investigated it enough or that the people who could explain were not present.
This is exactly the reason for locking the protocol. Should devs always waste their precious time and energy investigating whenever someone is willing to inject something into the protocol?
The burden of proof should not be on the ones who oppose change.
There was little to no attempt to compromise from anyone. I posed the question to nChain if they would be willing to accept some of the ABC changes if their op codes could be given more priority; the answer was essentially "no".
Here's what Ayn Rand had to say about compromise:
"In any compromise between food and poison, it is only death that can win. In any compromise between good and evil, it is only evil that can profit."
Talking about "compromise" is trying to make this about persons and politics, when there's much more at stake, Bitcoin itself and its future. Just one harmful change might endanger it.
One does not "compromise" by adding only half dose of poison into his food. If I know food is poisoned, I don't eat it and I don't care if that displeases the chef.
"Some had said that there is a difference in philosophies (locking down the protocol vs improving it in order to scale), but based on the fact that everyone had similar goals, my main conclusion is that this battle is really about influence and control over the protocol."
This same misrepresentation keeps getting repeated.
Who is in control if the protocol is locked? No one.
And that's why it should be locked. If it's not, then there's always this question of control and politics. Which was something Bitcoin was supposed to avoid.
And I don't say this stuff because I support nChain. It's the other way around. (Does this really need to be stated? Some people try to make into some kind of "tribe"/"follower" thing.) If nChain ever starts pushing unnecessary changes to the protocol, I will oppose them too.


2 of 2 reviewers say it's worth paying for

0 of 2 reviewers say it's not worth paying for
  earned 10.0¢
One question I have is if the purpose for CTOR is improved scaling then does that improved scaling also activate when CTOR activates? If not then why push for CTOR hardfork before CTOR benefits are ready?
   2wk ago
15.0¢ 25.0¢
  spent 15.0¢
I appreciate your comments and I agree with a lot of them. I'll just make a few points: 1. The reason for the high comment price on my report is to improve the signal to noise ratio. I thought it an important event in our brief history and desired to keep low effort noise away.
2. The post was intended more as reporting with minimal op-ed elements. The observation that there wasn't compromise wasn't a value judgement. In many cases, compromise is not suitable; whether it is or not in this case is debatable.
3. I totally agree there should be a burden of proof for adding things to the protocol, both in terms of the necessity/benefit and also the safety. To be fair to the critics of ABC, I think that CTOR could have used more testing. At this point, I will aim to participate in heavy testing of CTOR to help ensure it is safe; I also believe Roger Ver is contributing a $100,000 bounty towards that effort.
If the argument is over how many months of testing, well that is a valid argument... but we have 2 solid months of testing ahead of now. I think changing the roadmap/dev cycle at this point would do more harm than good. A group should not be allowed to throw a monkey wrench in the multi group dev process at the last moment. A conference was even held to try to resolve the matter and the key people in that group didn't even participate. Beyond a certain point of reasonableness, you have to draw the line. 4. I do not think this philosophy of "locking down the protocol" even makes sense because EVERYONE agrees that technical changes are required to achieve bigger blocks; the two things are mutually exclusive in a broad sense. I understand the idea/philosophy of only making necessary changes to the protocol, but this is not consistent with blocking a scaling optimization. Moreover, the nChain camp was very insistent that we need bigger block capacity now so that businesses can feel confident to build on BCH. I agree with this, but it is just much at odds with "locking down the protocol" if we need to engineer it so that bigger blocks are possible sooner rather than later.
   2wk ago
  spent 15.0¢
Regarding the locking down of the protocol, it's a catch 22. Businesses aren't going to standardize on foundations that may keep shifting; they want stability. They definitely don't want to take on crypto knowing that every 6 months they'll have to do a system upgrade or deal with the kind of stuff going on currently. (My job is in software and we often find clients using releases that are years old; they just don't want to upgrade because it adds unnecessary risk to their business).
On the other side of the argument, if BCH becomes standard it needs to scale efficiently and *maybe* that can only come from protocol upgrades that get implemented now and over the next few years.
The thing with the latter option is that we may end up with a refined and elegant protocol that scales well, but it helps no one if no one uses it! In the business world, good enough really is good enough. (I'll come back to this in a moment).
Furthermore, I think the OP's point about locking things down is valid in that it stops the "my dick is bigger than yours" non-sense and people can focus on adoption/promotion and solutions that work with the protocol rather than continually messing with it.
Maybe there is some middle ground where upgrades only happen once every 2-3 years say, instead of every 6 months (which seems way too often to me). That would allow plenty of time for research, testing and allow not only miners, but businesses time to be ready. Ideally though, this would stop as soon as things were "good enough" (as I mentioned above). The question then becomes what is good enough?
If you think things are good enough now, then I think you have to lean towards the nChain view point. If, on the other hand, the problems with scaling are clear and easily improved if we invest time now, then leaning the other way (at least for the short term) seems to make sense. The reason I say short term is that the window of opportunity to go world scale is getting smaller and smaller as financial institutions rally to combat the crypto threat by offering services that will be (and are) perceived by non-crypto folk to be equivalent to what we can offer. (Rick Falkvinge put out a good video on this idea recently. Where I live I don't even need cash anymore. I can pay instantly by waving a piece of plastic in front of a PoS device literally everywhere I go, no PIN or ID or anything else required. In comparison the crypto UX is archaic. It's going to be a hard sell now, let alone if we have to wait several more years to improve the protocol. We are losing our chance and need to get moving!).
IMHO, at the end of the day, the risk of losing business adoption by messing around trying to get things perfect for a future that might not happen easily exceeds the risk of locking down now and finding that down the track we need to find a different way to optimize scaling. In the advent that BCH becomes so successful and runs into big scaling issues that can only be solved with software changes I am sure at that time, people would be receptive to a plan to sort the issue out and in that ideal future where everyone would benefit, that plan wouldn't be contentious at all.
   2wk ago