Term

Canonical Transaction Ordering

A rule in Bitcoin Cash that orders transactions within a block by their transaction ID, enabling faster lookup and mining optimizations.

Type:
bch
scaling
Also known as:
CTOR
1
definition

Canonical Transaction Ordering (CTOR) is a rule implemented in the Bitcoin Cash (BCH) network that mandates transactions within each block to be ordered by their transaction IDs in lexicographical order. This specific ordering allows for more efficient block propagation, faster transaction lookup, and potential future scalability enhancements. Unlike topological ordering which requires transactions to be ordered based on their dependencies, CTOR uses a simple, deterministic rule based on the transaction IDs themselves, regardless of their relationships to each other.

Example 1.1

For instance, if a block contains three transactions with IDs 'a123', 'b456', and 'a789', under CTOR, these transactions must be ordered as 'a123', 'a789', 'b456' within the block (lexicographically). This order allows nodes to quickly verify the correctness of the transaction order in a block, and it simplifies the process of checking whether a specific transaction is included in a block through binary search algorithms, which are much more efficient than linear searches.

2
implementation

CTOR was activated on the Bitcoin Cash network during the scheduled November 2018 hard fork. The implementation of CTOR was part of a broader effort to improve the scalability and efficiency of the BCH network, with the goal of enabling BCH to function as a global currency capable of processing thousands of transactions per second. The change was somewhat controversial at the time, with debates around its necessity and immediate benefits versus potential future advantages.

Example 2.1

Prior to the implementation of CTOR, transactions in a block could be in any order, as long as the dependencies between transactions were respected. This old ordering system was known as Topological Transaction Ordering (TTOR). Under TTOR, if transaction B spends an output created by transaction A, then A must come before B in the block. The switch to CTOR was a significant change in the block structure of BCH, removing this constraint and allowing for more optimized block construction and validation processes.

3
benefits

The benefits of CTOR are not just limited to faster transaction lookup. It also allows for enhanced compression techniques, which can reduce the amount of data that needs to be transmitted when propagating blocks across the network. This can lead to faster block propagation times, reducing the risk of stale blocks and improving the overall efficiency of the network. Additionally, CTOR enables advanced validation techniques and more efficient parallel processing of transactions.

Example 3.1

With CTOR, it's possible to use techniques like Graphene for block propagation, which can significantly reduce the amount of data that needs to be transmitted. This is because with CTOR, the order of transactions in a block is known in advance, so only the presence or absence of transactions needs to be communicated, not their order. In testing, Graphene with CTOR has demonstrated the ability to compress a 1MB block to just a few kilobytes, representing a 99.9% reduction in data transmission requirements, which is crucial for enabling larger blocks and higher transaction throughput.

4
technical implications

From a technical perspective, CTOR simplifies many operations in Bitcoin Cash nodes. By ordering transactions lexicographically, operations like Merkle tree construction become more straightforward and efficient. Additionally, CTOR enables more efficient parallel validation of transactions since the ordering rule is simple and does not depend on transaction contents or relationships between transactions.

Example 4.1

When building a Merkle tree (a data structure used to efficiently verify the contents of large data structures like blockchain blocks), with CTOR, the process becomes more straightforward as transactions can be processed in their lexicographical order without needing to consider their dependencies. This allows for optimizations in how nodes validate blocks and can lead to performance improvements, especially as block sizes increase to accommodate more transactions.

5
controversy and adoption

The adoption of CTOR was not without controversy in the Bitcoin Cash community. Some developers argued that the benefits were theoretical and not immediately necessary, while others saw it as a foundational change needed for future scaling improvements. The debate around CTOR contributed to tensions that eventually led to the BCH/BSV split in November 2018, with Bitcoin SV (BSV) rejecting CTOR in favor of maintaining the original transaction ordering system.

Example 5.1

During the lead-up to the November 2018 hard fork, different development teams had contrasting visions for Bitcoin Cash's scaling approach. The Bitcoin ABC team advocated for CTOR as part of a roadmap focused on optimizing protocol efficiency, while Bitcoin SV developers argued for maintaining the original transaction ordering and focusing solely on increasing the block size. This disagreement, among others, led to the chain split, with Bitcoin Cash implementing CTOR and continuing to develop optimizations for efficient large block processing.

6
future implications

The implementation of CTOR opens the door to future scaling enhancements for Bitcoin Cash. By establishing a predictable transaction order, developers can create more efficient algorithms for block propagation, validation, and storage. These optimizations are particularly important for a cryptocurrency like Bitcoin Cash, which aims to scale on-chain to global levels of adoption rather than relying primarily on layer-2 solutions.

Example 6.1

One potential future enhancement enabled by CTOR is Avalanche pre-consensus, a protocol that allows nodes to quickly agree on the set of transactions that will be included in the next block before it is actually mined. With CTOR, nodes can communicate about transaction sets more efficiently because they don't need to transmit information about the transaction order. This could potentially reduce block propagation times even further and decrease the likelihood of chain reorganizations, making 0-confirmation transactions safer for merchants to accept.

All terms and definitions may update as the Cryptionary improves.