As blocks are on average 10 min apart, it’s important to take advantage of the whole duration in-between two consecutive blocks to process incoming transactions as evenly as possible, making the most of available computing resources. Click to expand...

Ok, @Tom Zander : I have now spend the better parts of the night here in Europe pondering hard about the whole transaction ordering thing once more as I feel the window is closing tobring forward criticism yet it feels very important to do the right thing here.I (as have others, like @Peter R , I believe) have flip-flopped on this issue, but that should only be taken as a sign that there's still uncertainty - at least in my mind - as to what this change would entail.I have also looked again for good arguments on why this change is needed or why it makes sense and I have to say that I have to confirm your POV that there is indeed quite a lack of good arguments.With all due respect, but for me, this now includes the whitepaper by Vermorel, @deadalnix and others IMO. I am referring to this one: https://blog.vermorel.com/pdf/canonical-tx-ordering-2018-06-12.pdf To state it bluntly, the convincing sounding arguments therein seem like a series of red herrings now. Not red herrings in the sense meant to fool others, mind you. But the kind of line of thought that emerges when one tries to bury a problem that simply is hard and bothers one's sense of cleanliness and neatness but one that will NOT go away as it is simply intrinsic to the system. You start to fool yourself, and in turn you start to inadvertently fool others.Basically, @Peter R . said once, paraphrasing from memory "it is the natural order of things, should we really change it?".And that is the essence, but it took me a while to grasp.Yes, the transactions are currently in partial order in blocks and that complicates some things.But basically, there is no way out of that. You can hide the problem behind a layer of 'sorting and unsorting' but that just adds complexity. The required partial order is the validation order. Not the TXID. And You. Can. Not. Avoid. That.On a single core, it is also quite obvious that this natural partial order is the fastest way to validate. And on multiple cores, if anything, with the partial order in place, I know that transactions I built upon can only come from the past and thus have gained a bit of entropy compared to the by-txid ordering case. I have yet to see any argument why losing this information and having to rebuild it is advantageous. I suspect one could even attempt to make a proof that if you split up a partially ordered block like it is now at arbitrary boundaries into chunks, and distribute it among workers, that the interprocess communication needed and the amount of stalling you get can only get higher with orderings that are different from the required partial order.One argument from the whitepaper that stood out for me in the sense how it utterly falls apart under a change in perspective is this:Yes. Agreed. BUT: Right now, if you identify the transaction order with the partial order that you get if you'd take the (inaccessible) transaction creation time (which is necessarily causal!), you get the green line (crosses) in this picture:And if you do the canonical order, you get the red crosses, with a sporadic return to natural order on the block boundaries.How can this be an advantage for processing, especially processing that is smooth in intensity over time, like the above stated goal!? The red herring here looking at blocks instead of theThe good parts, like my weakblocks RPC code becoming simpler resp. faster are true. But they're basically just me reaping the benefits of a sort-and-unsort steps that happens around the very validation core of the system. I can more easily dig by TXIDs through blocks when they are guaranteed to be ordered.And the structure of the system itself should be seen independently of requirements for just querying it! It is as important to look at the requirements for updating it.And yes, it would be great to have all that kind of functionality in easily accessible APIs and be able to shape the amount of extra resource usage vs. convenience trade-off when using them.But that is independent of changing the order in the blocks!And it appears to me that changing the validation order of the system, with now folks starting to complain that it makes things slower (so evidence to the contrary of efficiency!) is a dangerous path to go down, just to reap some benefits on the borders of the system. ( @Tom Zander : Have you made plots regarding the slowdowns in your software expected with canonical ordering?)This goes for graphene as well as weak blocks. @Tom Zander 's argument (which I have a deja vu of having heard before, from him most likely) regarding the partial order basically permitting freedom to sort for Graphene makes a lot of sense here.And all one does when adding the sorting on top is to push the issue around and creating more complexity in the end. @deadalnix , please convince me of the opposite. What and where does validation efficiency increase due to canonical ordering?At the very least, let us please wait a bit longer with changing the transaction ordering. We can change it and it might be worse, or we can leave it for now and it might beI will try to put together a more detailed criticism of the linked whitepaper tomorrow.