Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ecbp 1076: activate miner signaling process #194

Closed
wants to merge 2 commits into from
Closed

ecbp 1076: activate miner signaling process #194

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
745d44a
ecbp 1076: activate miner signaling process
soc1c Nov 21, 2019
91fd411
1076: clarify on signaling range
soc1c Nov 21, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 14 additions & 33 deletions _specs/ecip-1076.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,58 +1,39 @@
---
lang: en
ecip: 1076
title: Mining Algorithm Change Process
title: Mining Algorithm Signaling Process
author: Talha Cross (@soc1c)
discussions-to: https://github.com/ethereumclassic/ECIPs/issues/174
status: Draft
status: Active
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is invalid. Signaling is a hard fork process, and thus this should follow "Last Call" -> "Accepted" -> "Final" route, instead of "Active".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a hard fork process. It's non-binding signaling.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@soc1c Still, there's no justification to move this to "Active" status. I believe that's just wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quote ECIP-1000:

"Process ECIPs may also be moved to a status of “Active” instead"

This clearly is a process ECIP.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@soc1c I would put this in the same category as specifications like ERC-20. I don't believe they can be moved to "Active" status, thus the same for this ECBP.

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.
This meta document is agnostic to any mining algorithm. Its sole purpose is specifying a process for miners to signal their preferred 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.
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 miners could signal in favor of one 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).
- ~~**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.
_Note: ProgPoW was rejected by the community on Nov/20, 2019. However, miners can still signal for this option if they prefer this over the other options._

### Process
The following process facilitates all stakeholders in various stages.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The following process facilitates all stakeholders in various stages.
The following process facilitates all stakeholders in various stages, with "Tech Stage" and the "Miner Stage" to occur in parallel:

Eventually, the miners have to signal in favor of one option.

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).
### Signaling Process
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 subsections.

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.
The signaling process shall be considered finished once more than **70% of the last 1_000_000 blocks** were signed with a signal in favor of one proposal.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
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 specified here. 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:
##### Miner Extradata Prefix
The miner signaling 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:
Expand All @@ -68,9 +49,9 @@ The miner prepend the miner's extra data with 5 bytes of signaling data which sh

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.
No signaling abstains from voting and shall not be regarded as favoring the status quo.

### Mining Node Configuration Examples
##### 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:
Expand Down