UTXO Commitments, BCH Scalability: ‘Locking Down the Protocol’ is an Idiotic Idea

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic Idea

Chris Pacia, Bitcoin Cash (BCH) developer, as guest editorialist, examines why the constant refrain to “lock down” the BCH protocol is a bad idea at this point. 

There is a talking point that is repeated ad nausem by followers of Craig Wright. The Bitcoin protocol is more or less perfect and can already scale to handle billions of users (with terabyte blocks to boot!), and no protocol changes are needed to scale and in fact what is needed is “lock down the protocol”. Those with even a modest understanding of the technology know that this is not true. In this post I’m going to talk about one of the more obvious scalability bottlenecks that will require a protocol (consensus) change to overcome — initial blockchain sync.

More Spice: Bitcoin White Paper Webcomic by Comics Legend Scott McCloud

The Bitcoin Cash Protocol Problem

I recently created a Go implementation of ECMH (elliptic curve multiset hash) that we plan on using for UTXO commitments in Bitcoin Cash. More about EMCH in a little bit. Right now I want to help you understand the problem that we are trying to solve.

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic Idea

In order to validate transactions full nodes must posses a database of the currently spendable bitcoins. We call this database the UTXO set. It’s currently around 3 gigabytes in size and we expect it to grow as Bitcoin Cash acquires more users.

At present the only way to securely acquire a copy of the UTXO set is to download the entire historical blockchain from genesis, parse and validate each block, and construct the UTXO set as you go. Today this will take you about half a day as the blockchain is something like 130 gigabytes in size.

553 Years 

When we talk about scaling to large block sizes like gigabyte blocks or terabyte blocks we’re talking about dramatically increasing the size of the blockchain and the time it takes to sync a full node from genesis. At some point it ceases to be possible. For example, on today’s consumer grade hardware it would take about 553 years to download and validate just one year’s worth of terabyte blocks.

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic IdeaEven on extremely expensive enterprise level hardware we can expect syncing from genesis to take an unacceptably long time. The predictable result of this is enormous amounts of centralization. Most likely everyone will resort to trusting one or two large scale data providers to tell them if their transactions are valid making Bitcoin no longer a decentralized digital currency.

The engineering challenge that we face is not to just scale at any cost, but to scale while retaining the properties of the system that we value. Decentralization being first and foremost. It’s actually extremely easy to scale a digital currency to global adoption levels if you give up on decentralization. This has been possible for decades and you don’t need Bitcoin to do it.

A Medium Term Solution

An optimization that we will be implementing in bchd in the coming months is to (optionally) have the full node download the UTXO set at a checkpoint semi-close to the tip of the chain and sync full blocks to the tip.

This is where ECMH comes in. ECMH is a new hashing algorithm for hashing an unordered set (like the UTXO set) with more or less in constant time additions and removals. When downloading the UTXO set the bchd full node will calculate the ECMH hash of the UTXO set and compare it to the hash hardcoded with the checkpoint. This allows the node validate that it downloaded the correct UTXO for the given block. And any other node running on the network can verify that the ECMH hash in the checkpoint is correct.

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic Idea

Let me pause here to remind the reader that BSV supporters roundly criticized the practice of checkpointing (which was introduced by Satoshi) as Not True Bitcoin™.  Yet checkpointing the UTXO set is really the only feasible way to sync a new node at even medium scale.

The only issue with this approach is it becomes less and less feasible as the size of the blocks increases. If, for example, the checkpoint is three months from the tip of the chain, a new node will still need to download and validate three months worth of gigabyte blocks or terabytes blocks, which will still be unacceptably slow. It will only take 138 years for consumer grade hardware to sync from the checkpoint, for example.

A Long Term Solution

The long term solution is going to be to modify the Bitcoin protocol to require that blocks commit to the hash of the UTXO set. Again, ECMH is a great cryptographic primitive for this as additions and removals from the multiset only require a couple sha256 hashes and a single elliptic curve add operation.

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic Idea

By putting the hash in the block headers (or a new merkle tree structure, or the coinbase, etc) we can allow nodes to sync the longest chain of headers, get the hash of the UTXO set and download the UTXO set, not from a deep checkpoint, but at the tip of the chain. So no need to sync months of blocks to the tip.

Likely we’ll want to shard the UTXO set into buckets so that peers can download different shards in parallel and detect if a malicious peer served them an invalid shard.


Thomas van der Wansem did a good amount of work creating the ECMH spec that we based our Go implementation on. He also mined the first block on testnet containing a UTXO commitment using a branch of Bitcoin-ABC.

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic Idea

To repeat what I said above, the goal is to scale while remaining decentralized. This is not trivial to do and certainly not possible without protocol changes to remove bottlenecks. Here we’ve discussed just one of the more obvious bottlenecks. There are others. And some of them do not yet have obvious technical solutions and more research will likely be required if we’re genuinely going to scale this thing.

It should be obvious that “locking down the protocol” is an idiotic idea at this point. It’s a sure fire way to guarantee that you will hit major bottlenecks as the network scales. We’ve seen exactly what this looks like with the BTC network.

The goal of BCH is to create a stable currency. A currency which experiences radical shifts in its underlying properties as it hits bottlenecks is not a stable currency. We must identify these bottlenecks today and fix them so that the currency will remain stable going forward.

UTXO Commitments, BCH Scalability: 'Locking Down the Protocol' is an Idiotic IdeaCONTINUE THE SPICE and check out our piping hot YouTube channel. Our podcast, Milk, might help sooth that crypto burn. Follow CoinSpice on Twitter. Join our Telegram feed to make sure you never miss a post. Drop some BCH at the merch shop — we’ve got some spicy shirts for men and women. Don’t forget to help spread the word about CoinSpice on social media.