Juan Garavaglia
Sep 7, 2018 · 2 min read

Andrew, the document describe a possible attack based on Tom Zander argument, is a paradox for me because if that attack occurs will just reduce the efficiency of the parallelization technique what implicit recognize there is a benefit otherwise nothing will be lost with the attack, and leaves us in the worst case scenario in the same scenario we have without CTOR. So IMO is a pretty solid argument why CTOR helps parallelization.

Second you address the SPV impact, some applications require to do some small adjustments after CTOR will get activated in November and is one of the main reasons why we need to this now, in 2 years we will have more applications so more code to fix, sooner is better in this case, beyond that point CTOR has no other relation with SPV wallets or other applications affected.

In the Apendix A you analyzes the impact in Graphene you say is mandatory to have an ordering rule and I agree, and CTOR is the best candidate I know because helps the parallelization. To do a SoftFork to activate CTOR we first need to remove TTOR that require a HardFork anyway, one HF + one SW does not reduce the risks in facy it increase it exponentially more if you know beforehand the SW will be to implement an ordering you already had ready when you push the HF.

So you recognize CTOR is good for Graphene, and I can say Graphene is a very good idea from scaling perspective, scaling in blockchains you know is a hard topic because they don’t scale very well and to archive the mission of P2P E-Cash we need to scale not just a bit or a few in short term we need to scale 1000X in short term.

To finish the title of the document contradicts what the document says, will be fair to change it to “CTOR is grate for Graphene, and Graphene is grate for scaling On-Chain, and is is our main mission, Thanks ABC! for this gift!”