As we approach the scheduled November protocol upgrade for Bitcoin Cash, my wish is for as many community members as possible to understand the proposed changes.

One of the main changes is the addition of OP_CHECKDATASIG, which I explained in a previous post.

The other significant upgrade is Canonical Transaction Ordering, commonly abbreviated as “CTOR”. I will defer to a future article for discussing the specific benefits or criticisms of CTOR. Here I will merely attempt to explain what it is so that anyone can understand the basics.

Blocks are The Basis of Bitcoin Security

As you may probably know, Bitcoin famously solved the “double spending” problem that befuddled everyone who had previously tried to create a decentralized digital currency. It accomplished this by creating a distributed timestamp server, “by taking a hash of a block of items to be timestamped and widely publishing the hash” , to quote the whitepaper.

Obviously there is also the proof-of-work component that prevents anyone from easily changing blocks that are published. It is important to realize that it is the blocks, NOT the individual transactions, that make up the units of this so-called ‘timestamp server’. As a miner, when you are successful in your proof-of-work task, you are solving for an entire block.

If you want to think about this from another angle, imagine you are a user who just sent a transaction and you’re waiting to see a confirmation in your wallet. When it appears, you know that a miner has secured it in a block along with countless other transactions, all together.

Why is this relevant to CTOR? Again: It’s because the order of the blocks are what’s important, not the transactions.

The order of transactions inside a block has nothing (or very little) to do with security model of Bitcoin. In fact, it's essentially just an implementation detail. This is important because some people have the wrong impression that CTOR is a radical experiment that fundamentally changes Bitcoin, which is a misunderstanding based on a lack of knowledge.

The Grocery Store List

Here’s a simple analogy: Say my wife sends me off to the grocery store with a list of items to purchase. Let’s say eggs, bread, and milk. If I’m successful, I enter the store with my list and exit with eggs, bread, and milk.

All my wife really cares about is that when I get back home, all the requested items are in the bag. It does not really matter too much which isle of the store I went down first or which item I put in the shopping cart first… although some methods are going to be more efficient than others.

In this analogy, the individual items (eggs, bread, milk) are the individual transactions, and the entire list of the items is the block. At the end of the shopping trip, I’ve solved the block, the items are there, and that’s that.

Canonical is a Scary Word

Developers like to use impressive and scholarly words like “canonical” because it helps them get their jollies. In reality, this is just plain, ordinary numerical ordering from lowest to highest… at least in this context. This means that the transaction id (or transaction hash) with the lowest number would appear first in the block, and the highest number hash would come last.

The Existing “Topological” Ordering Requirement

Here’s another fancy word: “topological”. Here it simply means that if you have an unconfirmed parent transaction (you are spending funds that came from another transaction in the same block), the parent has to come first.

The current consensus rules have a partial ordering requirement in that the transactions can be in any order as long the ‘topology’ of parent to child is respected.

Proposed Change

The CTOR proposal would put the transactions in numerical order from lowest to highest, which would simultaneously necessitate abandoning the requirement to keep the topological ordering, since you would be unable to do both all of the time.

The Reason for CTOR

What’s the reason? In a word, scaling. Everyone wants huge blocks and we CAN scale on chain, but this does not happen automatically without optimizing the software via intelligent throughput engineering.