ECBP-1076: Mining algorithm change process

_specs/ecip-1076.md

@@ -0,0 +1,97 @@
+---
+lang: en
+ecip: 1076
+title: Mining Algorithm Change Process
+author: Talha Cross (@soc1c)
+discussions-to: https://github.com/ethereumclassic/ECIPs/issues/174
+status: Draft
+type: ECBP
+created: 2019-11-16
+---
+
+### Abstract
+This meta document is agnostic to any mining algorithm. Its sole purpose is specifying a process how to openly determine and select a mining algorithm for Ethereum Classic.
+
+### Motivation
+The decision to change the Ethereum Classic mining algorithm - or to keep it as is - is not an easy one to make. It should be done by broad consensus with all stakeholders involved - miners, investors, application and core developers, and anyone else who feels having a stake in ETC. This meta document proposes a process of how to facilitate the potential change of the mining algorithm and parameters.
+
+### Available Options
+Currently, the following options are debatable.
+
+- **ECBP-1076-A**: _"Ethash Status Quo."_ The mining algorithm will be untouched as it is since genesis, as **Ethash** function with a statically **increasing DAG**.
+- **ECBP-1076-B**: _"Ethash Limited DAG."_ The mining algorithm will be untouched as it is since genesis, as **Ethash** function. However, the **DAG size will be limited** as specified in [ECIP-1043](https://ecips.ethereumclassic.org/ECIPs/ecip-1043).
+- **ECBP-1076-C**: _"Keccak256 (SHA3)."_ The mining algorithm will be **changed to Keccak256** as specified in [ECIP-1049](https://ecips.ethereumclassic.org/ECIPs/ecip-1049).
+- **ECBP-1076-D**: _"ProgPoW."_ The mining algorithm will be **changed to ProgPow** as specified in [ECIP-1070](https://ecips.ethereumclassic.org/ECIPs/ecip-1070).
+
+Eventually, the community has to decide on one.
+
+### Process
+The following process facilitates all stakeholders in various stages.
+
+1. _"Tech Stage."_ Core and application developers meet in regular calls to evaluate the feasibility of the Ethash status quo, the limited DAG size proposal (ECIP-1043), the Keccak256 proposal (ECIP-1049), and the ProgPoW proposal (ECIP-1070).
+
+    If there is no technical objection to each of the proposals, the proposals can be **moved to "Last Call"** state, regardless of whether they will be considered in future or not. As a result, none, one, or many competing proposals can be in "Last Call" state at the same time.
+
+    This stage is finished once all proposals are either in "Last Call," "Withdrawn," or "Rejected" state.
+
+2. _"Miner Stage."_ Solo miners, mining farms, and mining pools can signal support by adjusting their mining node to signal in favor of one of the proposals that was promoted to "Last Call" state in the previous stage. Details on the signaling can be found in the subsequent section.
+
+    This stage is finished once more than **70% of the last 100_000 blocks** were signed with a signal in favor of one proposal.
+3. _"Decision Stage."_ The proposal that passed the technical stage to "Last Call" state and received 70% approval by the miner community, **shall be considered as "Accepted,"** all other competing proposals shall be considered as "Rejected." The EIP Editors are responsible to facilitate this status update to the proposals according to this process definition.
+
+    The block number where the 70% threshold is breached the first time is called the `threshold_blocknumber`. It automatically defines the `activation_blocknumber` which is:
+
+    ```
+    activation_blocknumber = threshold_blocknumber + 1_000_000
+    ```
+
+    That gives clients a six months window of activating releases with the ECBP-1076 activation block number.
+
+    In case none of the proposals reaches the defined threshold, the status quo will remain indefinitely until either one of the proposals reaches the 70% majority or until this process is entirely rejected by the community.
+
+### Miner Signaling
+The miner stage is specified as follows.
+
+The miner prepend the miner's extra data with 5 bytes of signaling data which shall be recorded in the Ethereum Classic block headers. The 5 bytes contain the following:
+
+1. Two start bytes that indicate a signal in terms of ECBP-1076, namely `76` (`0x37 0x36`)
+2. One option byte that favors one of the proposals:
+    - `A` (`0x41`): ECBP-1076-A _(optional)_
+    - `B` (`0x42`): ECBP-1076-B
+    - `C` (`0x43`): ECBP-1076-C
+    - `D` (`0x44`): ECBP-1076-D
+3. Two numeric bytes that vote on the default gas limit as specified in [ECIP-1047](https://ecips.ethereumclassic.org/ECIPs/ecip-1047).
+    - `00` (`0x30 0x30`): abstain / don't care _(optional)_
+    - `01` (`0x30 0x31`): support ECIP-1047 client defaults with 1 million gas block gas limit
+    - `08` (`0x30 0x38`): reject ECIP-1047 client defaults, explicitly supporting the 8 million gas block gas limit defaults
+    - `99` (`0x39 0x39`): any other number between `00` and `99` suggests a competing default block gas limit
+
+In addition to the numeric vote on the gas limit with the extra data field, mining nodes are encouraged to utilized block gas target limit voting with the suitable configuration flags for their mining nodes.
+
+No signaling favors the status quo (ECBP-1076-A) and effectively rejects ECIPs 1041, 1043, 1047, 1049, and 1070.
+
+### Mining Node Configuration Examples
+The following configuration examples do not favor one option over another and only serve the purpose of demonstration.
+
+A Parity Ethereum node configured to vote for Keccak256 (ECBP-1076-C) not caring about the block gas limit:
+
+```
+parity --extra-data "76C00 Happy Trigger Farm" [OPTIONS]
+```
+
+A Multi-Geth node configured to vote for Ethash with DAG size limit (ECBP-1076-B) and a 1 million block gas limit (ECIP-1047):
+
+```
+geth --miner.extradata "76B01 Funny Classic Pool" --miner.gaslimit 1000000 [OPTIONS]
+```
+A Besu node configured to vote for ProgPoW (ECBP-1076-D) and an increase of the block gas limit:
+
+```
+besu --miner-extra-data="76D15 LOL-lonely Miner 1337" --target-gas-limit=15000000 [OPTIONS]
+```
+
+### Implementation
+All clients implement custom extra data and block gas limit target voting. No custom implementation is required.
+
+### Copyright/Licensing
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).