Why ABC’s CTOR Will Not Scale – Andrew Stone – Medium
medium.com/@g.andrew.stone/why-abcs-ctor-will...
medium.comPosted Dec 5, 2018, 12:24 AM UTC
2521
medium.comTotally crazy that they divided the community over this. Developer overreaching and social attacks is our biggest threats to Bitcoin.
6
Wormhole needs CTOR. And ABC is mostly paid for by Bitmain.
It makes sense when you realize that.
5
Such a shit show. That was exactly like ‘segwit is needed for sidechains’.
2
It was clearly something that Jihan demanded..
3
um so there isn't any coherent rebuttal to this is there??
5
All the people smart enough to rebutt him left to Bitcoin.(SV)
13
This
4
BUABC thought it wasn't worth it to split the chain over this. Same story with XTABC and the other follow clients
3
See also nChain's analysis of CTOR.
http://nchain.com/app/uploads/2018/09/Canonical-Transaction-Ordering-A-Critical-Evaluation-Final.pdf [PDF]
2
There was never any rebuttal by anyone to the 'light client' problem in the article.
Socialism is helluva drug. It makes you ignore reason and mathematics.
Excerpt:
Chancellor’s sharding proposal ignores light wallet (SPV wallets, mobile wallets, etc) access to transactions. But the Bitcoin Cash architecture is focused on access via light wallets and Bitcoin Cash’s scalability is plan is founded on the idea that the end-user won’t run a full node. The ratio of light wallets to full nodes will be analogous to the ratio of email users to email servers today. Let us conservatively propose that each full node serves 1000 light wallets. Given the volumes, this message is clearly the most important in terms of scalability. Every block received will result in 1000 messages to light wallets per node, or 1000 times the activity. Yet this activity is not addressed in the proposal.
Light wallets need to be notified of transactions that match addresses they are interested in. This is done via the MERKLE_BLOCK message which provides the light wallet a block without all of the transactions it is not interested in.
In Chancellor’s proposal the UTXO set is sharded by transaction id, which has no relationship to addresses. So how to create a MERKLE_BLOCK message?
The light client request must be sent to every shard by the “API Request Processor & Transaction Router” node specified in his proposal. Every shard must then search its portion of the block for matching transaction addresses and respond. The “API Request Processor & Transaction Router” nodes then pull this information together into a MERKLE_BLOCK. There is no scalability when a common message requires the involvement of every shard.
Note that even if we moved away from the MERKLE_BLOCK message, we still need to search every shard for transactions that involve addresses of interest. For the vast majority of wallets that have made no transactions in the last 10 minutes, we still need to search every shard to create a “there’s nothing of interest to you” response.
The only way to solve this problem is to put the data that a light wallet needs into a single shard. Could wallets generate “vanity” transactions (transactions with a common prefix) that all land in one shard? Unfortunately, it’s the sending wallet that generates the transaction while the receiving wallet does the search and so needs to specify the transaction prefix. And what about transactions sending to multiple destinations?
To solve the light wallet access problem, which is the biggest problem, a completely different sharding mechanism must be used. If we deploy CTOR, it will be hard to reverse it in order to deploy a technique that actually helps shard the blockchain.
1
seriously, they're like, it'll help blocks propagate faster if we mandate a particular ordering.. wtf? are people opposed to having their blocks propagate quickly? they need to have this mandated?? and they're mandating this particular order before actually making any systems where this order actually helps??? what??? nChain could provide more public data but they at least *say* that they've run their shit on a testnet for a long time making sure it *actually fucking works* before putting it in... just putting in a consensus change like that just on the theoretical idea that maybe that could be a nice way to order things, fuck me
3
It all makes sense when one realizes that Omni/Wormhol protocol is broken without CTOR.
8
Indeed
3
He also thinks that scripts is useless...
But BU starts to disagree? Interesting...
3
[deleted]
1
The only negative that this author brings up is that CTOR is a hard fork, and therefore has consensus risks.
But the hardfork has already happened. Therefore the negative impacts already exist.
Also, seriously, this is just an ordering scheme for a block. This is not a big deal. It is just a way for how transactions are ordered within a block.
1
..... of course how the transactions are ordered in the block is a big deal
3
Ok, why?
Has any miner at all, any single miner, given an alternative, better ordering?
If there are alternative, better ways to order transactions within a block, how come no miners have given better suggestions?
1
what? what do you mean? we don't need better suggestions for what ordering to suddenly start requiring, we don't need to fucking do that at all??????????
4
If we don't "need" to do anything at all, then why are you so upset about CTOR?
If you have zero objections, then why is this a big deal?
Either this is a big deal or it isn't. If it is a big deal, then people should have better suggestions for a proper ordering. But they don't.
-2
Yeah crickets.....