Chris Pacia, Lead developer for Open Bazaar, shares his thoughts with me about the upcoming Bitcoin Cash Fork, and explains why there is dissent between Craig Wright (nChain), Bitcoin Unlimited, and Bitcoin ABC.



3 of 3 reviewers say it's worth paying for

0 of 3 reviewers say it's not worth paying for
  earned 0.0¢
could you cover Nchains threats to steal from exchanges like coinex if they dont run SV nodes or if they run ABC. The evidence has been compiled here:

   7mo ago
  earned 0.0¢
I don't like the sound of the "...trusted 3rd party..." to be involved in using this OP_CheckDataSig code.
I don't think you can actually say that CSW is anti-Bitcoin, that's just bad accusation to put on him IMHO. That label can be put on Core devs and Blockstream. I don't know label of anti-Bitcoin can be used on person that wants to have the BCH code as per original code/design? That just doesn't make sense.
About this canonical Tx ordering, I don't think you actually need to create a different ordering in order to do multi threading, instead of looking up Tx IDs and sorting them in certain order, which actually takes even more CPU work, you can simply assign Tx to different core as they come naturally... no need to check anything... for example with 2 core CPU you can do:
Tx1 go to cpu0, Tx2 go to cpu1, TX3 go to cpu0, etc
You can do Tx1, Tx2 to cpu0 then Tx3, Tx4 to cpu1 and so on... why need to sort at all? Transactions should be done in natural way, as it is now, 1st come 1st served kind of thing, creating specific ordering to me sounds like someone wants/needs transactions sorted to do something for their agenda/purpose, and that can be bad for Bitcoin Cash.
If transactions are to be sorted in certain way, that actually creates discrimination of transactions, doesn't it? Is that potential for this to be misused, kind of what Core did with BTC and RBF... it created discrimination of transactions based on economic class (how much money user has to pay for the Tx)... and I don't like those kinds of things. Every transactions should be equal in the "eye" of the miner/system/code, the way it is now.
About the block size limit, it indeed needs to be removed entirely (or automated like DAA so that human factor is eliminated completely).
CSW wanting to remove this limit, would make him correct and I am for it also.
The thing that this guy says about what ABC guys found, that there is a bottleneck in the network, could very likely be in THEIR network, in ABC software, as this stress test showed that only ABC nodes failed during the test, other nodes didn't... that to me is a sign that ABC guys don't want this limit increased/removed because their side can't handle it, this does not mean Bitcoin as a system can't handle it, that would be my logical conclusion.
For me, this block size limit still being there and still needing human factor to increase/adjust/etc, is the most vulnerable point of Bitcoin system, as it was shown to be the case with Bitcoin Core BTC. This mistake should not be repeated... this limit needs to be gone, and network/miners should adjust their limit as needed as network grows organically.
ABC guys being against this, looks shady to me.
The point that this guy is trying to make, "why do we need to increase block size limit now when BCH is not even used that much" is lame argument because exact same excuse can be used for this canonical ordering, why change the protocol in such way when this is not even needed now? So... sorry but... I can't agree with ABC and this guy at all.
Protocol needs to be as simple as possible as that makes the code faster, putting some extra load for sorting transactions, just adds more complexity and more load onto CPU which then leaves less CPU power for everything else... and not only making it more complex makes it slower, it makes it more prone to mistakes, hacks, etc
   7mo ago