Raising the Bar on Bitcoin Cash Upgrades
General Protocols (GP) would like to congratulate and thank the entire Bitcoin Cash (BCH) ecosystem for the successful November 15th upgrade. It was the culmination of all of our collective efforts to make it happen. While the November upgrade is now a part of our rich history, we must look to the present and the future. Particularly, GP believes that the BCH ecosystem needs to raise the bar for upgrades in order to achieve the related goals of evolving to meet the demands of global adoption, and being stable to make BCH the best network for builders and other stakeholders.
BCH must both evolve and be stable
GP is a company built from the ground up on BCH because of BCH's utility today and even greater potential. We clearly see the need for both evolution and stability and have worked on them as a team as well as individuals. Regarding stability of the network, GP team members have been deeply involved in projects such as Flipstarter, BCHN and BCH Network Discussions that are helping us find a way toward real decentralized governance. Regarding evolution of BCH to meet the demands of global adoption, GP created open source infrastructure and tools such as the AnyHedge protocol, AnyHedge tooling, Electrum-Cash, and the first BCH price oracle.
What kind of evolution does GP want in the short term?
From GP's perspective, all of those improvements are only the beginning. For the last 10 years, the BCH scripting system has mostly been unused and a curiosity. However with BCH’s upgrade to allow smart contract covenants, the utility of scripting suddenly took a large step up. A small set of use cases became immediately possible and a large number of use cases became theoretically possible. The barrier between what is realistic and what is theoretically possible is the limitations of BCH scripting.
Here is a list of important limitations where the solution is relatively simple. The appendix has much more detail.
You can add, subtract, divide and ________.
The maximum size of a contract, measured in number of operations, is small.
The maximum size of a contract, measured in bytes, is small.
Smart contract covenants are 2nd class citizens, requiring expensive and risky workarounds.
32-bit numbers are very restricting.
Does GP support BCH scripting changes in the May 2021 upgrade?
GP has decided to take a painful position on this issue.
Although the above improvements to scripting are important to General Protocols, important to the BCH network, relatively simple, low risk, and have low initial and ongoing costs, GP does not support attempting to include these improvements in the May 2021 upgrade. If the improvements become well specified, well tested, and gain a critical mass of support from network stakeholders at least 6 months before any upgrade, then GP will support including the improvements in the upgrade.
Raising the bar
The BCH network has experienced two notable splits in three years, with dubious rationale yet significant destruction of network effect and value. It is easy to point the finger at various parties. It is easy to say that a miner with a single ASIC on their desk can technically split the network. It is easy to say that we should do nothing for five years to avoid splits. However, we have to put unproductive arguments aside. We as network stakeholders must take a hard look at the situation. We must find a way to move forward that lets us upgrade BCH appropriately for global adoption without making room for dubious and destructive splits.
As described above, GP commits to the following:
Leading or supporting the specification, testing, cost-benefit analysis and stakeholder investigation of upgrades that are important to us.
Participating in discussions regarding other upgrades that are not as directly relevant to GP.
Waiting for potential upgrades to reach critical mass before committing to activation on a schedule, with the understanding that some upgrades may never reach critical mass.
GP also challenges other network stakeholders
Protocol and Network Developers: You are first class BCH stakeholders and have been since Genesis Block. Currently you hold more power than is probably healthy. We challenge you to take that power seriously, ignore people who would throw blame at you without taking responsibility, see the big picture, bring other stakeholders to the table, share responsibility, and ultimately innovate with prudence that both preserves and grows the network.
Businesses and Other Organizations: These early days of permissionless cash are a powerful mix of great uncertainty and massive potential. With the right vision and choices, you can use the Network to serve your users and take a leading role in the changes that are coming to the world. We challenge you to apply the unique value proposition of permissionless cash, understand its limitations today, and make sure that your users' needs are represented as the network grows.
Miners and Pools: GP challenges you to be effective executives, with high expectations for stakeholders and little tolerance for disruptive actors who threaten the value of your investment.
Users: This is all about you. You hold the ultimate power.
Appendix: What kind of limits does BCH scripting have?
You can add, subtract, divide and ________
You can't multiply. There are some other basic operations missing from BCH scripting.
The maximum size of a contract, measured in number of operations, is small
BCH script uses low level operations (op codes) that do very simple things. You can only use 201 of those operations in a script. For example, in some cases you might spend 3 or more (1.5%) of your operation limit to do a simple addition of A+B. Concretely, this limitation blocks critical features from AnyHedge such as handling of multiple oracles and sellability of contracts. Most contract developers will necessarily use compilers such as CashScript or Spedn, and those compilers already do a lot of optimization to get as much performance as possible out of the limited space. However even with optimized compilers and geniuses who can do manual optimization, it is a very small box to operate within.
The maximum size of a contract, measured in bytes, is small
Similar to operations, BCH script requires data to make things meaningful. You can only fit 520 bytes of data in a script. Additionally, each operation mentioned above spends some of the data limit.
Smart contract covenants are 2nd class citizens, requiring expensive and risky workarounds
In order to work with covenants today, there are a number of critical steps involved that eat deeply into the operations and data budget that is described above. Not only that, but if done naively, the steps involved create a large security risk for the covenant. It is easy to do naively and hard to notice all the ways that data might be manipulated to hack a covenant.
32-bit numbers are very restricting
In actual BCH transactions, the numbers are always Satoshis (Sats). So:
1 BCH is
100,000,000 (0.1 billion) Sats
.10,000 USD is about 40 BCH today. That is
4,000,000,000 (4 billion) Sats
.BCH script uses 32-bit numbers that can only handle numbers up to about
2,000,000,000 (2 billion) Sats
.
In other words, in the absolute best case, with no additional calculations to make things more realistic, BCH script can only work with about 20 BCH. While it is a lot of money, it is clearly not enough to handle global commerce with both individuals and businesses needing to handle much larger amounts on a regular basis.
Another issue caused by this limitation is that division, although very important, becomes a risky operation. For script numbers (integers):
1,000,000 / 6 = 166,666
(not 166,666.666... or 16,6667). Not bad.1,000,000 / 600,000 = 1
(not 1.666... or 2). Not so good.
That can be handled with some smart manipulation of numbers, but the 32-bit limit makes it very difficult to use those smart techniques.
To make things specific, the majority of code in the AnyHedge contract is there to allow larger BCH amounts and ensure accuracy regardless of the numbers involved.
General Protocols Blog
This article forms part of the General Protocols Blog, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings.
I agree it's probably good to "take a breather" regarding consensus level upgrades.
But these changes seem so obviously beneficial and relatively straight-forward that really -- after extensive testing -- they're a no-brainer to bring into BCH. Of course anything can be used to divide us again, so it most likely will be tried on that issue, too. Maybe we try to do this in Summer '21 or even 2022?
One thing:
I don't understand the "covenants are 2nd class citizens" reasoning. Why exactly are they second class citizens? You seem to imply because they use a lot of resources in scripts, but that doesn't make them second class, just hungry consumers, right?