Introduction

A void from the Core era, no generally accepted process to hard fork exists on Bitcoin Cash. This lack of process will hinder Bitcoin Cash development as coins like Ethereum charges ahead with Buterin consensus and Dash with master nodes.

I propose here a simple way to hard fork, one that respects Nakamoto consensus, protects the right to be heard, and encourages unity without coercion. This proposal does not apply to emergency hard-forks. All temporal concepts refer to block height estimates.

Please comment to signal interest. I will post revised versions if there is sufficient community support and feedback.

The Proposal

1. One or more developers publicly announce a hard-fork plan in the form of functional code. The plan should specify an identifier (e.g., "P1") and a fork time. There should be at least 43 calendar days between a plan's announcement and fork time.

An announcement is public only if it is reasonably calculated to reach a majority of miners, developers and merchants.

An announcement has occurred only with functional code.

Any non-trivial revision to a plan, including to the plan's fork time, is considered a new plan and must be publicly announced again.

2. A miner signals its support for a hard-fork by including its identifier in coinbase parameter. A miner signals its disapproval of a hard-fork by excluding its identifier in coinbase parameter.

A miner is free to consider the totality of circumstances, including competing hard-fork plans, reactions of merchants and users, and opinions of other miners in making this decision.

3. At the fork time, signaling miners will fork, while non-signaling miners will not. There is no expectation for dissenting miners to conform above a consensus threshold.