ECIP 1076: Mining Algorithm Change Process Source

AuthorTalha Cross
Discussions-Tohttps://github.com/ethereumclassic/ECIPs/issues/174
StatusDraft
TypeStandards Track
CategoryECBP
Created2019-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 they have 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.
  • ECBP-1076-C: “Keccak256 (SHA3).” The mining algorithm will be changed to Keccak256 as specified in ECIP-1049.
  • ECBP-1076-D: “ProgPoW.” The mining algorithm will be changed to ProgPow as specified in 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.
    • 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 utilize 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.