Among many discussions in Bitcoin Cash, which is to have a protocol upgrade this November, stands the question of whether canonical transaction ordering should be implemented, or indeed whether it should be called lexicographic rather than canonical.
Another nice word that you probably don’t understand is topological. That’s the current transaction ordering in both bitcoins.
And just to make class today a bit more exciting, we’ll have to explain child and parent transactions. That is A sends to B, then B sends to C, B being the child transaction while A is the parent.
Both bitcoins currently have a rule whereby “if a transaction B depends on a transaction A to be valid, then the transaction B must appear after the transaction A within the block.”
That’s called partial ordering, with a paper co-authored by the lead developer of BitcoinABC, Amaury Séchet, proposing a change to it “where transactions, within a block, are ordered by increasing transaction identifier.”
That’s basically a change “from ordering by validation order to ordering by TXID,” as Awemany, a pseudonymous BCH dev, says.
He has written a critique of the proposal, with Peter Rizun, who calls himself Chief Scientist at Bitcoin Unlimited, stating:
“I’m worried about unknown unknowns of hard-forking Bitcoin Cash to make lexical ordering a consensus rule (thereby making the current causal ordering invalid).”
Unknown Unknowns. He further says “about 30% of the technical folks I respect are in favour of lexical ordering, 20% are against, and 50% don’t know.”
One of those seemingly in favor is Emin Gün Sirer, Cornell Professor, who says: “Canonical transaction order removes spurious dependencies and can help speed up and scale blockchains.”
That’s the aim, to condense the amount of information needed to communicate between nodes so that the blocksize can be increased to potentially even a terabyte through Graphene or other optimizations.
Bitcoin Unlimited has recently merged Graphene, reducing the amount of block data that needs to be propagated to just 5.34 kb from 1MB.
With canonical or lexical ordering, Graphene can reduce it further to just 2.6kb. That’s because it wouldn’t need to transfer the ordering information as is currently required. Tom Zander, a BCH developer, says:
“A block typically has only a very small percentage of transactions that are required to be in-order. A small amount that spend outputs created in that same block.
The rest of the transactions are completely free to be reordered. For instance by sorting them by txid. No consensus rule violated.
And you suddenly can avoid sending the ordering info for the majority of the transactions. So only the transactions that need to be in-order will have some ordering info.”
The amount of transactions that need to be ordered might be small now, but at 30MB or 100MB, it might not be that small.
The question thus is whether it makes any difference if transactions are ordered by child comes after parent rather than through transaction ID which presumably does the same validation but by giving the child transaction a higher number.
That leads to the question of whether ordering by ID does in fact undertake the same validation as currently, meaning that the child of an invalid parent transaction can’t be spent.
If it does, then the question becomes what ancillary protocol aspects might be affected, or as Rizun put it, what might be the potential known unknowns.
Where it comes to unknown unknowns, that’s effectively saying nothing as it applies to any change with the argument thus being that if there is no good reason to change how it works, then it shouldn’t be changed.
That, in turn, makes the question as to what exactly is a good reason, who decides, and how. The proposal cites a number of reasons, including efficiency gains, improvements in proofs of transaction inclusion and mitigation of potential attack vectors, among others.
Are they sufficiently good reasons compared to what the unknowns might be, is what appears to be under debate, with the suggestion being that more time to study the potential implication is needed.
Time which BCH does have in many ways as its blockchain usually processes just 20,000 transactions a day, but obviously they want to have the capacity if adoption does pick up. Fixing the roof when the sun is shining sort of thing.
Yet whether it is or isn’t ordered in a canonical way seems to be only a tiny part of the capacity equation, with the question appearing to be purely technical, rather than having any political element up for debate, at least as far as we can see.
Copyrights Trustnodes.com
