The Bitcoin Cash Roadmap

It has been exactly once month since Bitcoin Cash split away from Bitcoin Core and by any reasonable standard it should be considered a success. At the time there was a huge amount of uncertainty. Would anyone support the new fork? Would it trade on any exchanges? Would it survive the initial difficulty adjustment? Would anyone mine it? The answer to all these questions turns out to be yes. And while some of the loud voices in the Bitcoin community went on the record predicting that Bitcoin Cash would be worth “not even a dollar each”, it’s currently trading around $622 and has a $10 billion market cap making it the third most popular cryptocurrency.

So where does Bitcoin Cash go from here? While I’m personally not affiliated with Bitcoin Cash per se, though I did write a Bitcoin Cash wallet, I’ve been following it closely enough to report on what seems to be a growing consensus around it’s long term roadmap. And I have to say, while the roadmap is probably more risky than Bitcoin Core’s, it’s certainly much more ambitious and much more capable of delivering meaningful scaling if successful.

Before we dive in let’s review Bitcoin Core’s roadmap so we have something to compare it to. Now that segwit is active on the network, what’s left? For the most part it’s just Schnorr signatures and MAST. While both technologies would represent and improvement over the status quo, neither delivers any meaningful additional capacity. How much capacity they deliver depends on usage patterns but you’re probably looking in the 15-25% range ― which is maybe only enough reduce fees by a few pennies, if at all. Besides that Core has basically bet the house on the lightning network in hopes that it will live up to the hype. Only time will tell.

Even if it is successful it still needs dramatically more on-chain capacity if it’s going to become widely used.

The following are a list of items that appear to me to be more or less on the Bitcoin Cash roadmap. I say appear to me because there isn’t any formal roadmap (as of yet), just a bunch of ideas thrown around on the mailing list and in slack that seems to have a rough high level consensus (implementation details spur much more debate).

New difficulty adjustment algorithm
The altcoin community very familiar with what happens when more than one coin competes for mining hardware ― wild swings in difficulty as miners switch to the most profitable-to-mine coins and unreliable block times. Bitcoin hasn’t had to deal with this during its lifetime since it’s the only cryptocurrency using double SHA256 as its mining algorithm. That has now changed with the Bitcoin Cash fork. The difficulty adjustment algorithm designed by Satoshi is pretty naive and not well suited for multiple coins competing for the same hash power and both Bitcoin Cash and Bitcoin are suffering because of it; Bitcoin Cash more so.

So it makes sense to change the algorithm. Fortunately a good deal of research has been done on this topic over the years so it’s really just a matter of implementing the best solution. The result is that Bitcoin Cash will have a modern adjustment algorithm that prevents wild swings in block times. Bitcoin, on the other hand, will have to continue to muddle through the relative changes in mining profitability.

Fix transaction malleability the right way
The primary complaint people had with segregated witness was not related to what it was trying to achieve ― fixing malleability, but rather how it was implemented. We were told the reason the Bitcoin community needed to accept such a cumbersome and ugly hack on a multi-billion dollar protocol was that to do it any other way was to risk a chain split. Ironically, that hack ended up being a primary driver of the Bitcoin Cash chain split. Bitcoin Cash is probably better off for forking off when it did because now it can fix malleability the correct way. Whether that is through a minimal malleability fix, with the transaction format remaining largely unchanged, or by changing the format to be more extensible is TBD.

In either case this change isn’t likely a high priority in the short term. It should be obvious to everyone that the primary use case for a malleability fix, the lightning network, is not ready right now. Even when it finally becomes ready it will take time for the technology to mature. And even more time to gain consumer acceptance, if it ever does. This could easily take several years to happen. If Bitcoin Cash takes 12 or 18 months to get a malleability fix out the door I doubt it will miss anything.

Parallel transaction validation / New merkle tree format
Today each transaction in a block must be validated in sequential order since later transactions might depend on prior ones. This prevents the validation from being done in parallel, increasing the time it takes to validate a block and creating a scalability bottleneck. By validating in parallel the work can be split across multiple cores or even multiple machines speeding up validation time. Since the ordering is no longer important, the merkle tree can be redefined to allow for things like proof-of-absence which would been needed for fraud proofs or sharding down the road.

UTXO comittments
Committing the root of the UTXO set to each block would improve light client security, support a fast sync mode, and help with sharding down the road. At this point in time it’s not clear if there is an efficient enough way to do this that wont itself become a scalability bottleneck. Ethereum does this with its Patricia tree, so there is at least some precedent but more research into how best to do so is probably still needed.

Short of the Patricia Tree, Bitcoin Cash could benefit from something like ECMH (Elliptic Curve Multiset Hash) proposed by Core developer Pieter Wuille. It doesn’t allow for the proofs we would like to create, but it’s very efficient and would probably be sufficient for checkpointing the UTXO set for fast sync. This could even be done without committing anything to the blocks and could be replaced by something better later. This would allow a new node to get fully bootstrapped in like five minutes rather than a couple days and allow all but archival nodes to prune transaction data older than six months or a year.

Bitcoin-ng / Weak blocks
Bitcoin-ng and Weak blocks are two different approaches to solving some scaling issues. The first has to do with larger blocks artificially benefiting larger miners at the expense of smaller miners potentially creating mining centralization pressures. The second is the need to validate blocks all at once rather than over time. Bitcoin-ng goes quite a bit further to fixing these issues than does weak blocks but it’s a pretty dramatic change to the consensus rules and one that has never run in a production environment. Weak blocks is just an addition to the wire protocol and doesn’t touch the consensus rules and is therefore more conservative.

If I had a vote I would probably do weak blocks now, see how it works, and then consider ng later on down the road.

Both bitcoin-ng and weak blocks would have the side benefit of improving zero confirmation security (though it still wouldn’t be perfect). Bitcoin-ng more so because it changes how transactions are mined and confirmed. Weak blocks, not being a consensus rule, would still permit miners to mine double spends, but it would give us a historical record of every double spend on the network. Merchants could use the blockchain data to calculate the percentage of transactions that received a weak confirmation but did not make it into the blockchain due to a double spend (likely to be very low) and use that to manage risk appropriately.

Sharding
The holy grail of blockchain scalability is not pushing all transactions off onto centralized or quasi-centralized layer 2 platforms, but rather removing the need for all nodes to download and validate all transactions for the system to work. Two of the changes mentioned above, restructuring the merkle tree and UTXO commitments, can possibly introduce a new partially-validating operating mode. Users could still run a fully validating node if they want to (a node that validates all shards), but they would have the option tell it to only download and validate some lesser number of shards and still have the same security as a full node. In theory, the network should still be able to function if all nodes, including miners, are running partially validating nodes. If it works you basically get unlimited on-chain scaling without introducing any centralization.

Sharding is still very researchy and so this is rightfully last on the roadmap, but it’s still an ideal to work towards. Ethereum has sharding on its roadmap, so hopefully we’ll get to see how it works for them and learn from what they do.

So that’s it. Like I said, it’s pretty ambitious. It will definitely require several hardforks to realize this roadmap, but one the benefits of doing changes by hardfork is that you can be somewhat bold when not constrained by backwards compatibility requirements. Some of this stuff might not work out but at least Bitcoin Cash is rejecting the notion that cryptocurrency aught to be nothing more than a corporate settlement system and pushing forward as spendable electronic cash.