Background

2020 has been an interesting and crazy year, to say the least. Bitcoin Cash has been no exception. Members of the Bitcoin community have been faced with several crises throughout its short history. These include the vacuum left by Satoshi’s withdrawal from the project and subsequent struggle to find and maintain leadership, development capture by Blockstream, the Great Blocksize Debate which resulted in both the Bitcoin and Bitcoin Cash forks of Bitcoin, DAA weaknesses and exploitation, and now in 2020 the crisis caused by ABC’s unwillingness to collaborate with other development teams and Amaury’s unilateral decision to soft fork a change to the way block rewards are distributed and redirect 8% of them to an address controlled by ABC. A lot can be said on both sides of the debate over the IFP, but this article is not meant to rehash that debate. It’s enough to say that what is currently happening now represents both a challenge and an opportunity to improve Bitcoin Cash’s governance. We must move away from the previous “benevolent dictator” governance and find a model for managing change to a protocol that lacks a single owner/sponsor, development team, or infrastructure provider. This is not easy work.

The Problem

The Bitcoin whitepaper spends little time on the subject of governance. Regarding governance, Satoshi says the following regarding Bitcoin governance in the whitepaper (emphasis mine):

[miners] vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

The governance as described in the whitepaper is only about the technical mechanism through which decisions are enforced. While this is certainly where the rubber meets the road from a governance perspective, it does not address the question of how miners should decide what rules they wish to enforce.

In the (very) early days of Bitcoin, all users were also miners and Satoshi had ultimate decision-making power over the protocol due to his status as its creator and the respect that entailed from others. This made governance easy. Satoshi would update Bitcoin-qt, users would download and run the new version, and everything went smoothly. Unfortunately, Satoshi has long since disappeared, there are many more users than before, most users no longer mine, and there are business interests which didn’t exist in the early days.

For years now, governance in Bitcoin has been led by developers. First, it was developers of Bitcoin-qt/Bitcoin Core. Later, after BCH forked, governance of the BCH protocol was led by Amaury Sechet of Bitcoin ABC. This has more-or-less worked since 2017, and Amaury has steadily gained decision-making power over the BCH protocol. An unfortunate consequence of the historic governance by a single person or development team is that miners have become disconnected from the wishes of the user community. Users have attempted to provide feedback primarily through social media, but as the Bitcoin Cash community knows, social media is vulnerable to trolling, sybil attacks, and manipulation through censorship. A few coin voting ideas have been attempted in the past, but with low adoption due to censorship and lack of recognition. Without organized, reliable user feedback miners have been left to rely primarily on discussions with developers and, to a lesser degree, businesses.

It has become clear to the majority of users, developers, miners, and businesses that the status quo is no longer tenable and BCH will likely split into two chains in November 2020, with Amaury Sechet and Bitcoin ABC forming their own coin for a second time. This leaves Bitcoin Cash with a pressing need to develop a new system of governance, and hopefully one that is both more robust and inclusive than what we’ve had before.

Stakeholders

An article written by R. Edward Freeman in 1983 titled Stockholders and Stakeholders: A New Perspective on Corporate Governance notes that the origin of the term stakeholder can be traced back to the Stanford Research Institute where an internal memo defined the term as, “those groups without whose support the organization would cease to exist.” While this definition was invented to apply to corporations, I believe it applies equally well to Bitcoin Cash. So, who are the groups without whose support Bitcoin Cash would cease to exist?

1.      Users – This group includes everyone who buys, sells, or holds Bitcoin Cash. For simplicity’s sake, I include businesses in this category since businesses are simply a collection of individuals with a common interest or goal for purposes of governance. Developers and miners are also users.

2.      Developers – This group includes everyone who contributes the code which makes the network function.

3.      Miners – This group includes everyone who mines Bitcoin Cash by providing SHA256 hash power to add new blocks to the blockchain. This group also includes mining pools to which individual miners largely delegate their decision-making power.

I should reiterate that these three groups are not distinct. As a permissionless system, there is nothing to prevent a user from also being a miner and/or developer, and all developers and miners are also users. It is important to remember that any given individual or organization may wear many hats and participate in governance at different levels or in different roles.

Each of the three stakeholder groups provides unique value and has unique needs. These groups also have unique characteristics that make certain methods of communication and coordination more or less effective or open to them.

Users

What do they provide?

Users provide value to Bitcoin Cash. Without users, there would be nobody to care how Bitcoin Cash worked or how it was governed. It would not be used for commerce, nobody would purchase it for speculation, and it would exist only in theory or on paper. Business users may also provide infrastructure and services to the rest of the community, though these are not directly tied to the functioning of Bitcoin Cash itself.

What do they need?

Users cannot exist in a vacuum. While they drive the value of Bitcoin Cash, they do not contribute in any direct way to creating the software or infrastructure that runs it. They need someone else to provide them with software and infrastructure. Many—but not all—users have only a surface level understanding of how Bitcoin Cash functions and many are not interested in aspects of Bitcoin Cash that have no visible impact to their experience transacting with Bitcoin Cash. The level of sophistication and interest in participation in governance among users varies. Some may wish to delegate most decision-making power to a more well-informed entity they trust.  Others may wish to express their opinions as individuals or businesses on most matters, including highly technical ones. Finally, some users may have zero interest in voicing an opinion and only care that Bitcoin Cash works for them.

Developers

What do they provide?

Developers are crucial to the functioning of Bitcoin Cash. Due do the hard work that developers have already put in, we have functional software already. However, Bitcoin Cash is still maturing and requires constant maintenance and improvements to the code to fix bugs and vulnerabilities as well as to add new features. Developers are the people who can take ideas and turn them into functioning software.

What do they need?

Developers need the support of users and miners. Support in this context has many meanings. The first and perhaps most obvious meaning is compensation. While there are many developers who happily do some work for free, there is a limit to the amount of time they can spend working on passion projects and they also require funds to pay for development tools, environments, and distribution. There are also many developers who would love to work on Bitcoin Cash, but simply cannot afford to do so for free. Therefore, it is up to users and miners to provide developers with an incentive to develop Bitcoin Cash. Another form of support that developers need is direction. While developers frequently have great ideas on their own, they may not always see things from the perspective of other types of users. If developers are not receiving feedback from their user community, the lack of perspective may cause them to work on features that are of little interest or even undesirable to other users.

Miners

What do they provide?

Miners secure the Bitcoin Cash network. They accept transactions, put them into new blocks, and build the blockchain. Without miners, Bitcoin Cash would become frozen in time. In return for securing the network and adding new blocks, miners receive both the block reward and transaction fees as compensation.

What do they need?

Miners wish to maximize their revenue from mining, and they need to decide what rules to enforce on the Bitcoin Cash network. Because their decisions of what rules to enforce has a direct impact on users and their demand for Bitcoin Cash, miners need to know what users want in order to maximize demand for Bitcoin Cash. They also need developers to write the code that allows them to enforce those rules.

A Governance Proposal

What follows is an outline for how governance might function in Bitcoin Cash in order to serve the needs of all stakeholders while preserving the fundamental characteristics that make it Bitcoin. The guiding principal for this proposal is to create the minimal amount of overhead sufficient to achieve the necessary outcome of stable and effective governance. First, some caveats:

·        This proposal focuses on consensus-level changes to the protocol. While non-consensus changes could go through this governance process, it is not necessary for them to do so as their impact on the ecosystem is much more limited in scope.

·        There is no way to force anyone to participate in any governance process beyond that which is defined in the whitepaper. If a rogue miner or developer wants to make a change to the protocol without going through the process described below, they are free to do so and face whatever outcome results.

·        My knowledge is imperfect and this proposal will require tweaks before or after any attempt to implement it is made. This draft represents the thoughts of one person. I welcome feedback and am happy to collaborate on other proposals.

Governance Levels

Because the three stakeholder groups in Bitcoin Cash have different capabilities and needs, governance must meet them where they are. For example, we cannot ask users or developers to use BIP-91 style signaling because they simply can’t do it.

First Level – Ideation

Ideas for protocol changes can come from any user (developers and miners are also users). It’s up to the person or group submitting an idea to begin communicating it to their peers to solicit feedback. This may start as a conversation on Telegram, a blog post on read.cash, or any number of media. It is up to the person or group with the idea to gather feedback, make adjustments, and build a coalition that drives the change forward. There is no gatekeeper at this point beyond the ability for an idea to gain traction within the community.

Second Level – Development Proposal and Evaluation

Once an idea appears to have enough support that it may be a candidate for a consensus-level protocol change, it should be vetted and sponsored by at least one node developer or development team to ensure that it is technically feasible. The person or business with the idea, the sponsoring developer or development team, and any other supporters of the idea should proceed to create a more formal proposal that includes a draft specification for the change to be made.

The proposal and specification for change should be posted where the general public can view and consume it. Every effort should be made to communicate the proposal at this point. This could include blog posts, social media, industry news publications, and/or conferences. Comments and feedback should be encouraged. A specific platform for comments and feedback can be established as we move forward.

When the proposal has received initial feedback and its sponsoring coalition feel that any necessary updates have been made to address feedback, they should open a simple coin-based poll. The poll would allow any user (entity holding coins) to cast a vote, weighted by the coins in the voting address, either in favor of or against the proposal. The poll should remain open long enough for considerable discussion to occur among the community. This polling mechanism is compatible with Liquid Democracy if such a system is implemented with support for Bitcoin Cash.

Third Level – Node Developer Acceptance

A consortium of full node development teams should be formed with representation from all teams that wish to participate. Anyone who believes they belong to the developer group should be able to opt-into participating and it is up to the community to decide the relative weighting of developer or development team’s opinions.

This consortium should meet regularly (perhaps bi-monthly or quarterly) in order to review and approve proposals which have concluded polling. The developer consortium will review the proposals and polling results and decide among themselves whether they accept the protocol change and will commit to implementing it in coordination with the other teams. Consensus is not required, but results of the node developer consortium should be made public along with an optional explanation for why a development team voted one way or another.

At this point, a proposal that has been rejected by all node development teams should be considered dead or in need of significant revision. However, if one or more development teams agrees to add the change to its backlog, the proposal should be considered alive and move forward in the process.

Fourth Level – Funding

Node development teams which have agreed to implement a proposal should collaborate with each other to ensure that they are able to deliver the code for that proposal in parallel. This will require prioritization, which may in turn require funding. Each team implementing the change should estimate the costs to implement it and decide whether they need external funding in order to implement the change. If funding is required, the teams will create a multi-sig address to receive funds and solicit donations for the work. The funding hurdle serves as a second check on the desirability of a change from users and miners. If funding goals are not met, the proposal may be shelved until a later date when the developers believe there is sufficient demand to create a successful funding drive.

Fifth Level – Miner Voting

After a proposal has been accepted, funded, and developed, miners will have a final chance to signal acceptance or rejection of a change before it is scheduled for activation. The precise mechanism of miner signaling is not addressed in this proposal, but it could be done using something like Javier Gonzalez’s Bitcoin Mining Parliament idea, traditional threshold-based activation, or even coinbase text signaling. This signaling should give others advance notice of the acceptance or rejection of a change. Depending on the specific mechanism used for miner voting, a change could be canceled if it fails to achieve miner consensus, or it could move forward and cause a chain split.

A Note on Chain Splits

Readers may notice that this governance proposal does not claim to prevent all future chain splits. It is certainly the hope of the author that splits in the future will be minimized as much as possible, but this governance proposal should be considered a success as long as such splits are rare and well-communicated in advance to all stakeholders. The signs of a potential chain split should appear early in this process if the developer consortium from level 3 do not reach consensus. Lack of consensus at that stage signals to the community that more attention should be paid to the change and that they may need to start preparing for a chain split. This is a fact of life in a permissionless system and it must be acknowledged and accepted by all participants.