ABC vs BSV Hash War (Part II) — Stability Theory vs Evolution Theory

Translation Weibo Article
Source: 《【天下大义，当混为一】（中）稳定论 vs 演化论》

“ABC vs BSV Hash War (Part I) — Why we need Hash Vote？”

Part 1:The Two Parties of BCH Fork

For BCH in this debate, one group is led by the “ABC Development Team” supported by Bitmain and some other people, the other by nChain’s CSW (Craig S Wright). There was a release of BSV client (Bitcoin Satoshi Vision). Both parties believe that BCH should become the global currency of 5 billion people, but the means used by them are different to achieve this goal.

Bitmain believes that BCH should do rapid iterative updates to meet market and adoption needs, attract more users, and ultimately reach the goal of being used by 5 billion people as a world currency. The CSW team believes that BCH as a currency should maintain its stability as an underlying protocol. Only a stable protocol can attract adoption and usage by enterprises. It even advocates that it should revert to the original version of Bitcoin (V0.1) and lock the protocol that Satoshi Nakamoto originally designed. They firm believe that the original underlying framework (including Turing’s complete script) is sufficient to take on the function of the world’s currency, as long as the development is being built above the existing protocol infrastructure.

Part 2:How is Bitcoin Whitepaper being designed?

To discuss “stability theory vs. evolution theory”, we should first understand how the Bitcoin whitepaper is being designed.

The scaling team often pointed out that Bitcoin Core’s route violated the original whitepaper design, while the Core team countered with that fact that the EDA/DDA difficulty adjustment algorithm in BCH fork violated the whitepaper. There is no DDA difficulty adjustment algorithm in the whitepaper.

In fact, in the whitepaper, there is no mention of the DDA difficulty adjustment algorithm. Even the “one block every 10 minutes” that everyone was familiar with was not mentioned. Just in Chapter 4: Proof-of-Work “One Block per n minutes on average”:

The proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated too fast, the difficulty increases.

Then in the 7th chapter: Reclaiming Disk Space, there was an example of 10 minutes per block:

…if we suppose blocks are generated every 10 minutes…

The whitepaper is actually very general, and only covers a purposeful description of the design, any description that satisfy the specification of the whitepaper shall be duly included within. BCH’s DDA difficulty adjustment algorithm can make the block time still fulfill the statement of “one block per n minutes on average”, even when difficulty level increases. This specification is more in line with the requirements of a whitepaper.

In the ‘computational war’ on November 15th, we will be able to see what how “BCH’s DDA difficulty adjustment algorithm is more in line with the whitepaper”. When Bitcoin Core uses an excessive level of computing power to compete with Bitcoin Cash, then Bitcoin Core’s block time will be significantly extended and cannot recover for a long time with severe congestion, but Bitcoin Cash can stabilize its “one block per 10 minutes on average” regardless of the change in the hash rate.

Part 3: How to Satisfy the Specifications of the Whitepaper?

We insist that the goal of Bitcoin has to be an “electronic cash system” and a “global currency” as laid out in the whitepaper. When the external environment changes, we must change the means to ensure that the objective remains unchanged. As exemplified above, when the fork occurs, Bitcoin Cash changes the difficulty adjustment algorithm where originally hashrate difficulty is adjusted once every 2016 blocks as opposed to the the DDA difficulty adjustment algorithm which entails that hashrate is adjusted whenever a new block is created.

So, does the modification of this protocol layer make the underlying bitcoin unstable? If you advocate a “stable underlying protocol”, what should you think of such a change?

At present, we can see that many people support the “stability agreement theory”, which has a lot to do with its simplicity, clarity and easy understanding. CSW even proposed a more extreme “lock agreement” at the outset: Restoring bitcoin to version 0.1 and locking it up, this claim is actually not practical, and Bitcoin has done a lot of functionality and security upgrades after version 0.1. Protocol layer modifications, such as multiple signatures (multi-sig) and it is impossible to delete.

Why does CSW propose such an unenforceable claim? This is related to the fact that such claims are simple and clear, easier to understand, publicized, and supported. But having such recognition does not mean that the claim is correct.

The most typical example is China’s 1958 steel production campaign: “We want to catch up with the United States.” “This year’s steel output has to double to 10.7 million tons.” The slogan is simple and powerful, and it has a huge publicity and mobilization. But in the end, it caused a huge economic disaster.

We know that a reasonable steel development plan is inevitably complicated and needs lots of adjustment. In most cases, it must be revised according to the economic and market conditions, and sometimes cannot even be put onto paper, let alone it being encompassed by a fancy propaganda slogan.

Part 4: An Example of Stability Theory vs Evolution Theory: DSV OpCode

The DSV opcode (OP_CHECKDATASIGVERIFY) is the focus of this hard fork, and it is also a typical point of the stability point vs. evolution theory debate.

The purpose of DSV is to introduce external information into the blockchain. The current BCH blockchain is an isolated system. It doesn’t know the results of Brazil vs Argentina’s game. I don’t know what the stock price is today or even BCH’s own price. However, if there is a DSV, the BCH user can agree on the way the information is published. A data publishing entity generates data that can be parsed by the DSV opcode on the BCH chain by means of a signature.

In this way, two or multiple users can establish a reliable smart contract on the BCH chain without using a third-party institution (stock exchange, sports lottery, etc.). For example, if two people want to bet on the results of Brazil vs Argentina, as long as the coin is entered into a multi-signature address and the result of the game is signed and released, the winnings will be automatically transferred to the winner’s address.

For further information read this article on Lightning: “Oracle Real World Data Link — Connecting the Real World and the Blockchain World Together”.

Evolution theory believes that DSV enhances the functionality of BCH, which is a very useful feature that can bring more applications and users to BCH. The stability theory believes that the underlying protocol of the opcode should not be modified for the application built on top of it or market demand. The underlying protocol should be as stable as possible.

Part 5: Key Logical Consistency

When we face two opposing views, we must first consider whether the views are logical.

1. The view of “evolution theory” is logical. If BCH should become the world currency of 5 billion people, BCH should consider how to acquire more users, and enhancing chain function is an effective means to attract more users and adoption. This is also in line with the logic of “cash”, “high frequency, “high liquidity”, and “high exposure”.

If it is useful, it will be implemented. If it is wrong, it will be challenged and altered. In the case that the number of BCH users (and the total market value) is significantly behind BCE (Bitcoin Core), increasing the number of BCH users is the most important task.

2. The logic of “stability theory” will first face a question: Is the priority of BCH to be stable or to get 5 billion users? The two goals are not necessarily consistent. Stability of the protocol could possibly attract more users, on the other hand it is also possible to adapt to market needs and add features to get more users. If the competitor has modified the underlying protocol, added functionality, and can indeed get a large number of users, then do we change it or not?

If you don’t change it, you will lose in the competition, user base falls to zero and the product becomes extinct. Does it make sense to discuss what is right or wrong? If it has to be changed, does it become then “evolution theory”?

3. In fact, Bitcoin Core’s view of refusing to scale is a typical “stability theory” based approach: Bitcoin should be decentralized as much as possible, nodes should be kept as small as possible, and transaction congestion can be solved through the second layer of the lightning network.

BCH’s scaling solution is based on the “evolution theory”: user experience is utmost important and they do not oppose the usage of second layer network. Given that current blockchain is almost running at full capacity, there is a need to expand block size, otherwise we will see users rushing to other blockchain protocol and Bitcoin will lose its competitiveness.

The user experience is very important. We do not oppose the second layer network, but now the block capacity is full and needs to be scaled immediately, otherwise the user will be lost to other currencies.

Part 6: How to Deal with Disputes in Development?

“Evolution” is a beautiful concept, but for blockchain, there is a fatal problem: rapid iterations require frequent modifications. In a decentralized system, who can make such decisions?

ETH can be quickly iterated and frequently modified. The founder Vitalik Buterin has the ultimate say on different revisions. Vitalik Buterin is the “One” in the ETH system. But Bitcoin’s “One” is the hashing power.

There is still a huge difference between hashing power and Vitalik Buterin. The hashing power cannot directly participate in the development, and it cannot even be involved in the development. I have imagined once that all development and revisions shall form a BIP proposal, and then the ones with significant hashing power shall vote to decide whether the BIP proposal will pass, but it is found to be impractical.

It is enough to prove that it is not feasible by using a counter-example: Bitmain once proposed that miners should donate a small part of their earnings to the development, but because of the possibilities of compulsory taxation, most people in the community objected, and the proposal was aborted. However, if the hashing power can directly determine the development proposal, then Bitmain can take advantage of its hashing power as one of the world’s largest mining pool to implement the miner donation proposal. This is not the result that most people in the community would like to see.

We know that “force” determines the rules, but this does not mean that “force” directly determines all the rules. Most of the rules are the result of a “game theory combat” between the competing parties. Hashing power is the “One” of the Bitcoin network, and it is the final ruling power, but this power does not mean a direct ruling of everything.

The specific development proposal of Bitcoin should be decided by the development team and the competing parties within the network. Only when the parties can’t agree on decisions and when Bitcoin faces a fork, it is time for the final hash ruling power to play a role.

Part 7: Summary

1. Hash vote should be used instead of unnecessary hard forks that could result in the weakening of bitcoin under the premise that the goals held by different parties are the same though the means are different.
2. The whitepaper is focused more on the purpose of bitcoin while in practice the focus should be on how to achieve the goals underlined in the whitepaper.
3. In order to satisfy the condition that the goals stated in the whitepaper should not be changed, the ‘evolution theory’ will undoubtedly be adopted in a ever-changing market condition.
4. The ‘stability theory’ advocates conditions that are simple and clear. It is easy to understand, promote and gain support but this does not necessarily mean that the conditions are correct. The ‘stability theory’ and the ‘targeted user base’ are logically incompatible.
5. It will inevitably lead to conflict and fork with ‘evolution theory’. Hash power, therefore, should be used to decide actions in order to avoid unnecessary forks.