There has been a lot of confusion about the upcoming Bitcoin Cash hard fork. This could have been partly remedied by improved communication, but I think fundamentally it is an issue with the decentralised development model Bitcoin Cash has adopted (i.e. multiple development teams).

I would like to offer a proposal to improve the consensus finding mechanisms of Bitcoin Cash.

The Problem

Finding consensus is hard, especially when using a decentralised development structure, and after 3 years of civil war. Having multiple development teams, and therefore multiple streams of proposals, means that there is bound to be conflict and competition. This is a good thing though. Not only does decentralised development spread power and influence out so that there is no core . It also leads to a marketplace of competing ideas. More ideas means a higher probability of finding optimal solutions.

The downfall of this approach is the fact that it becomes difficult to decide what proposal gets implemented. Egos can flare up, and a split in the commmunity can occur if a debate gets too heated.

The Proposal

In the bitcoin white paper the following sentence refers to a decision making process:

"The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it."

I am not 100% certain, but I think Satoshi may have been suggesting that decisions could be made by miners simply following the majority after a vote. In this way the network is able to make upgrades and the network remains in consensus at all times (i.e. no network splits). My proposal is essentially just this. The procedure for upgrades would be as follows:

1. Developers find an issue in the software or think of an improvement that can be made.

2. Developers discuss how the issue can be fixed or how the improvement can be implemented.

3. Development teams offer up coded proposals that they think would best solve the problem.

4. A signalling period is used for miners to signal their support for a proposal.

5.a. If a fix/improvement needs to be chosen in a short amount of time. It can be chosen by which proposal receives relative majority support (proposal with most miner support).

5.b. If a fix/improvement is not under time pressure, the following terms can be use; If a proposal receives absolute majority support (>50%) by miner signalling over a period of time, then the proposal becomes locked in.

5.c. If a fix/improvement is significant and controversial, the following terms can be used; If a proposal receives a super majority of support (>75%) by miner signalling over a period of time, then the proposal becomes locked in.

6. The lock in period occurs and then 100% of the miners fork the network.

In this way, miners have a gentlemen's agreement with each other and the network that; if a proposal receives the required support over the signalling period, then all miners will switch to support that proposal. Most soft and hard forks are not going to be idealogical disagreements like the Bitcoin Cash genesis fork was. There may be some disagreement on the exact solution but in almost all cases it will be preferable for one proposal to be chosen and the network to remain in consensus.

I believe this proposal solves a number of issues.

1. Extreme consensus is no longer necessary.

2. Development teams can offer up different proposals and the market can decide.

3. The network remains in 100% consensus at all times other than in situations of extreme idealogical disagreement.