The following is a letter which was sent to the developers of Bitcoin ABC, Bitcoin Unlimited, Bitcoin XT, Bitprim on March 15th of 2018. At the time, I was handling official releases for Bitcoin ABC; although I am no longer a maintainer. This letter is being published for the edification of people outside the Bitcoin Cash development community. It was written in response to what I perceived as a general disagreement about how we were trying to work together, what we were trying to accomplish, and specifically over the May 15th protocol upgrade. It is worth noting that it was an ongoing challenge to facilitate cohesion between developer groups. There were many uncooperative factions and individuals at every Bitcoin Cash protocol upgrade –- August 2017, November 2017, May 2018, and November 2018. Even the addition of CashAddr to Bitcoin-ABC, which was a non-consensus change, has faced a significant backlash. Had Bitcoin Cash developers stopped working every time someone decided to dispute changes, for ideological reasons, none of the of the many things which have been accomplished over the last year and a half would have happened – including the birth of Bitcoin Cash.

The letter is as follows:

The Future of Bitcoin Cash

Bitcoin Cash exists due to a faulty development process existing for Bitcoin Core. We are currently a minority fork due to the way in which the development process was converted into a design committee and co-opted by individuals who were demonstrably not interested in ensuring the success of Bitcoin.

The expense of generating the Bitcoin Cash fork to the ecosystem has not been insignificant; and Bitcoin Cash remains a minority fork to this date. However, I believe that if we continue to do our job, BTC will eventually fail completely, and ​we will be ready​. This will lead to BCH becoming the majority fork and currency.

However, any open source project potentially has the same social vulnerabilities as Bitcoin Core. With the amount of money involved in this space, there are strong incentives to control the future of Bitcoin Cash. As such, it was my understanding that there was generally understood principles that were shared by the Bitcoin Cash developers at the time of launch. These ideals were shared to prevent a repeat of the events leading up to the Bitcoin Cash fork.

However, no document has clearly articulated what these were. Therefore, I am attempting to articulate those ideals insomuch as I understand them. It is my agenda within the Bitcoin Cash community to ensure that these ideals are realized.

It is my understanding that there were two shared ideals, both of which are necessary to support the other. These two ideals each have two critical ramifications.

The first ramification of having multiple implementations is that exchanges and miners will be able to have modular redundancy. As the value of the Bitcoin Cash ecosystem grows, exchanges will ultimately need ​triple modular redundancy​ via running three implementations at the same time. Double modular redundancy is already in place at some large exchanges. However, as the saying goes: ”Never go to sea with two chronometers; take one or three.” The second ramification is that no single team will have control over the specification of the Bitcoin Cash protocol; a majority of implementations must agree on the details of the protocol at all times.

Forced Routine Protocol Upgrades

Forced routine upgrades are also critically important to Bitcoin Cash. The first ramification of this is that that protocol upgrades can be done on routine intervals and that no team can stymie the further development of the protocol. This principle is a necessary protection to prevent a repeat of what happened with the 1MB block size limit. The second ramification is that exchanges will be aware well in advance when they need to prepare for software upgrades, and can make educated decisions about which software they will choose to run leading into each protocol upgrade along with which of their own patches they wish to apply.

How do we meet these ideals

In order to meet this ideals as a group we are ​forced​ to work together collaboratively rather than combatively. We must have clients released well in advance of protocol upgrade dates so that exchanges may install multiple node implementations, and test them well in advance.

This also means we ​must ​agree to collaborate and get review from our peers in a timely manner, and must work together to provide a specification for what we will be doing in the next upgrade ​well in advance. ​ Implementations which fail to do this will ultimately be left behind by the teams who do work together.

This ensures that there are other lead implementation engineers who ​can​ veto protocol decisions when they are poor. However, these leads must also work together to ensure that the above ideals are realized. Once they are truly established, they will be become entrenched and serve to protect the development process for the world currency.

Any team which wishes to build this future with me must commit to a reasonable release schedule, providing binaries to exchanges in a timely manner, and a QA process that is suitable for a currency. Our benchmark for this degree of rigour should exceed what is required of banks and security organizations. Together we must define what this process is and how they will be continuously improved over time (static analysis, fuzzing, and other QA processes we do not currently have).

I know many of the developers currently working on Bitcoin Cash wish to realize this goal with me; as I have spoken with you one on one. It has become clear that not everyone shares my vision for Bitcoin Cash, and attempting to work together without shared values is ultimately fruitless. Going forward, I will only be working with teams who want to realize this goal with me.

I hope that we can work together to agree on a schedule that we can stick to, and which meets the requirements of our customers. As such, I have proposed a workflow, and the timeline was established in London to be 6 months; with feature freezes 3 months in advance. Please propose adjustments to ​agenda for the first QA meeting.

Respectfully,

Shammah Chancellor Release Manager, Bitcoin ABC