Last update 16/08/2020

中文

This article is a companion article to a more concise proposal. Check out also the accompanying evidence-based process proposal and writeup.

Premise

We are actors of the Bitcoin Cash ecosystem. We join (and leave) it voluntarily and permissionlessly. We are users, businesses and miners, and we agree on the idea that Bitcoin Cash is a peer to peer electronic cash system for the world. Supporting it as such creates a win-win-win scenario.

It's a win for users, who can transact freely with anyone in the world. The users give the network its value. Users are individuals, organizations, governments, and any entity that uses Bitcoin Cash as a means of exchange.

It's a win for businesses, who build upon a stable foundation. Businesses include merchants, services, wallets, exchanges, and anyone who profits from offering value to the users.

It's a win for miners, who validate everyone's transactions and profit from the value of the network.

Win-win scenarios are rare and have desirable properties. It's provable that honest cooperation is the winning strategy for the participants.
A strategy not based on cooperation reveals hidden incentives and if it persists, it must be concluded that it is not aligned with everyone's best interest.

Bitcoin Cash is, first and foremost, a protocol and at its core lie the consensus rules. Those define what Bitcoin Cash is, and it's what we voluntarily agree on.

Anything outside the scope of consensus-level rules is outside the scope of this document. Not even non-consensus protocol rules are covered.

In order to improve Bitcoin Cash as electronic peer to peer cash, it will sometimes be necessary to modify its consensus rules. As the actors of the ecosystem, we need a standard for doing so.

Bitcoin Cash disrupts a lot of interests. Opposition is to be expected. We need a standard for maintaining consensus that is robust not only to disruption from outside the ecosystem, but also contention within it. We might disagree on a solution to a problem, on a problem statement, or we can even disagree if a change needs to happen or not. We need a framework to tackle disagreements early and productively.

Bitcoin Cash is a repeat game, we intend to be here for a long time. It's likely that our best option is to have some benefit of doubt, some compassion and understanding for mistakes, but overall just collaborate with those willing to collaborate, and chose not to play with those who don't want to collaborate
- Jonathan Silverblood

A process for changing consensus rules

Basic rules of thumb

The basic "smell test"

If a change is a clear win-win-win for users, businesses and miners, then it's probably good at furthering Bitcoin Cash. Win-neutral-neutral outcomes can also work, because by the virtue of the win-win-win synergy, a win to one is a win to all.

If a change produces a lose outcome for any of the actors, then we need to ask if it really furthers Bitcoin Cash as peer to peer electronic cash for the world. Such changes are not strictly excluded a priori, but require a clear rationale.

No monetary policy changes

Any changes to monetary policy should be held to the highest degree of scrutiny, as such changes have a high likelihood of undermining expectations of all ecosystem actors, possibly leading to crumbling of the fundamental value of Bitcoin Cash.

Corollary: Prefer choiceless solutions.
If a solution has many parameters to fiddle with, there are choices to be made on what those parameters should be. Would a choice of these parameters affect monetary policy somehow? Would a solution with less parameters be preferable? Probably.

We require excellence

No formal process can be established for consensus changes, otherwise we'll be taken over by lawyers and career politicians in a matter of weeks.

We cannot appeal to a central authority either, as we refuse to nominate one. The ecosystem is decentralized and should stay that way.

By virtue of this decentralization we establish a loose process in which we, as ecosystem actors, agree to hold each other accountable to a high standard.

By making consensus changes subject to a hard process, it immediately changes the focus of all involved parties from human interaction into gaming the process itself. In the case of a consensus-connected process, it will be nearly impossible for it to evolve and resist inevitable gaming. Therefore it is better to establish high standards and expectations instead. As adoption increases, consensus rules will become nearly impossible to change and these standards will have served its purpose. A mechanism wired directly into the consensus layer however would be a permanent and unnecessary attack vector.

The basic rules are pretty simple:

• we hold ourselves to a high standard

• we hold each other to a high standard

• we hold everyone to the same standard

The third rule is important: it means that nobody gets a free pass (for whatever reason), but also that stonewalling is not admissible - anyone can permissionlessly take initiative by following these high standards.

We require excellence in technicals

An evidence-based process is the bare minimum we can ask for a consensus-level change. It provides a checklist of what to produce (and what to require) when a consensus-level change is proposed.

A person or group willing to spearhead a consensus change will nominate themselves as the leaders of that initiative. They will assure open communication of the following points.

These are not to be interpreted as a step-by-step process, rather as a checklist - for a proposal to be valid, all of them these need to be completed, not necessarily in-order and possibly with iterations.

• (Objective) Define what the change it aims to achieve or what problem it needs to solve

• (Solution) Provide a solution that's a clear improvement for the objective

• (Specification) Provide a clear spec, which might initially be a draft

• (Implementation) Provide a reference implementation for testing

• (Burden of proof) Provide a clear case in favor of the change and reproducible evidence (possibly a test suite)

• (Feedback) Gather feedback to improve all of the above

• (Evaluate) Allow reasonable time for people to evaluate and propose alternative solutions

We require excellence in collaboration

Outside of the scope of consensus-level changes, Bitcoin Cash sees a lot of competition. Businesses compete for users on prices and features; miners ruthlessly compete for blocks; users have each their own motives.

But within the scope of consensus, there is no space for competition. In a win-win-win scenario, the winning strategy is honest collaboration. Non-collaborating actors need to be called out and, eventually, left behind. It is important to not be naive about repeatedly misbehaving actors, we can't expect them to suddenly fall in line for some reason.

In a voluntary and permissionless ecosystem, the only way to implement changes without coercion is by building wide agreement around them. Make no mistake - this is hard work, maybe moreso than writing code, but if the change has merit, people will see the value in it. On the other hand we still need to defend the protocol against hostile changes and tackle disagreements.

This is common sense really. But some baseline rules are provided.

1. Communicate early and clearly

Stating your intentions publicly as soon as they are formed in a clear fashion. This helps with building reputation and credibility. Reach out to the ecosystem.

Changing your position is fine when presented with new evidence, but erratic behavior is hard to interpret as honest.

1a. Specifically: no surprises

Shock-and-awe strategies need to be recognized as hostile. Actors repeatedly engaging in such behavior signal different, hidden interests not aligned with win-win-win outcomes of furthering peer to peer electronic cash.

Businesses specifically require stability to plan their path. Surprises on the consensus-level kill prosperity.

2. Brainstorm in good faith

Be ready to ask and answer a lot of questions in detail. It's a good idea to make past conversation public to point to previously discussed topic.

We'll also need to deal with the occasional troll, but that's the easy part. When in doubt a couple of well placed questions will reveal if a newcomer's intention is to genuinely understand or drain energy. Be welcoming, but not naive.

Also, there are possibly other things being worked on that could be more urgent. While non-consensus changes can go in parallel, and don't require the same level of cooperation, the ecosystem can handle just so many consensus changes in a year. Asses priorities with other actors, and be prepared to postpone some of the changes.

3. Don't hold grudges

Grudges lead to poor communication and over a longer period of time, bad communication is indistinguishable from dishonest intentions.

Despite our best efforts, miscommunications can happen. Get over it. Be forgiving, but not naive!

4. Face disagreement gracefully

Disagreements are to be expected. We have a more technical framework for choosing the best technical solution to a given problem. But what if we don't agree on what the problem is? Or if we disagree that there even is a problem?

4a. Reach out directly

ASKING A DIRECT QUESTION?! UNTHINKABLE!!!

And yet, it's the most basic and productive way to diffuse misunderstandings and understand other people's thought process.

4b. Try a multiparty meeting

If disagreements can't be nipped at the bud, they can be brought to a more formal meeting. A neutral moderator can be invited or hired. It's a time-proven technique to (at least try to) get on the same page.

4c. Check with the ecosystem

Reaching out to the ecosystem is the absolute minimum for a consensus change, and should have been already done in point 1.
Any system of checking wide agreement - in a non binding way, but as a means of gauging sentiment. Specifically don't set up such a poll in a way that favors you, but in a way that lets you check if opposition is genuine.

Again, these polls need to be non binding, otherwise lawyers take over. That's what they do, they specialize in exploiting rules (no offense to actual lawyers).

4d. A split is always an option

Before going for the nuclear option, try all of the above. Specifically, if all of the above was not already tried, anyone scaremongering a split should be assumed to want a split, and recognized as a dishonest actor.

Splits are painful and subtract from the goal of electronic peer to peer cash, but they are sometimes inevitable. As a rule of thumb, have a clear record of attempting all of the above, and at least some credible support to assure livelihood of the new chain.

But let's make that the last option.

On developers

Up until now the word "developers" hasn't appeared once. Developers are not to be thought of as ecosystem actors in their own right - they act on behalf of the actors. They can be contracted by businesses to provide features, by miners to improve performance, or funded by users to improve scalability. In doing so they are accountable to those parties.

In the cryptoverse, we've come to accept a culture where the "dev team" is an essential part of a currency's ecosystem, an actor in its own right. I argue against this culture. The developers are functional to the other actors and their interests.

As developers, we can't help ourselves. We want to code cool things. We don't distinguish much between consensus and non-consensus changes - it's all code to us. We tend to make the mistake of neglecting actual, real-world importance of things at the face of the challenges we're willing to overcome (to prove ourselves).

The actual actors of the ecosystem (users, businesses and miners) should dictate the rules of the consensus. They can establish or contract developer teams to do relevant work. Miners could get developers improve mining and networking performance; users will certainly want scaling; businesses will profit from better and faster APIs.

This is already happening with Bitcoin Verde - it is maintained by Software Verde that has actual use-cases for it. For such teams, their interests are transparent: they are driven by business motive.

On the other hand there are development teams that are not directly miners nor businesses. They are most certainly users/holders, but their motives can not always be clear. You should question their interests - not because they're dishonest, but hold them accountable to the highest standard, as far as consensus-level changes go.

Implementations should compete on performance and features. This is a good thing. But as soon as we're talking consensus, any competition or (irrelevant) disagreement is to be left at the door.

On policy

Full nodes have default policies on protocol that are not necessarily consensus-level (for example the minimum transaction fee for relaying or unconfirmed transaction chain limit). While these policies are not strictly consensus rules, they become the de facto consensus if there is only one dominant mining implementation. This puts a lot of power in those teams' hands.

The "reference client" mindset is a legacy from the past that we need to get rid of. Fortunately, there is incentive for miners to run multiple implementations as fallback (and some already do), ie. mine with one implementation and switch to another in case of a malfunction, we've already seen it work. Multiple implementations provide robustness to the network, and miners should take advantage of that.

We're not there yet

The world where the "dev teams" are functional to the ecosystem actors is still far from here. But we do have a roadmap and we do have a great deal of passionate developers willing to selflessly take that burden. Many have done so in the past ten years, and we should celebrate them for their accomplishments and for taking the responsibility of doing so. Going forward we all, as ecosystem actors, need to share that responsibility.

For both the time being and for the future, I believe this framework can help us get there in a gradual stable prosperous way.