Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Defuse Difficulty Bomb and Reset Block Reward #1227
Pull request with up-to-date proposal: #1235
This thread is for discussion.
eip: title: Defuse Difficulty Bomb and Reset Block Reward author: SmeargleUsedFly (@SmeargleUsedFly) discussions-to: https://github.com/ethereum/EIPs/issues/1227 status: WIP type: Standards Track category: Core created: 2018-07-18 requires: #649
This EIP proposes to permanently disable the "difficulty bomb" and reset the block reward to pre-Byzantium levels.
Nick Johnson, the de facto lead EIP editor, has stated unambiguously that the Ethereum user community's opinion on changes to the protocol may only be announced by running/not running node client software. This is also reflected in EIP #1, which includes no mention of community input over the EIP process. However, due to the "difficulty bomb" (also known as the "ice age"), introduced in EIP #2, an artificial exponential increase in difficulty until chain freeze, users may find it much more challenging to exercise one of those choices than the other—namely, remaining on the unforked chain after a controversial hard-fork.
This situation has in fact already been observed: during the Byzantium hard-fork users were given the "choice" of following the upgraded side of the chain or remaining on the original chain, the latter already experiencing block times greater than 30 seconds. In reality one will find that organizing a disperse and decentralized set of individuals to keep the original, soon-to-be-dead chain alive under such conditions impossible. This is exacerbated when a controversial change, such as EIP #649, is merged in so close to the hard-fork date, as users cannot be organized to take an educated stance for or against the change on such short notice.
Ultimately, the difficulty bomb serves but a single purpose: make it more difficult to keep the original chain alive after a hard-fork. This is unacceptable if the only way the community can make their voice heard is running/not running client software, and not through the EIP process, since they effectively have no choice and therefore no power. This EIP proposes to completely eliminate the difficulty bomb, returning some measure of power over Ethereum's governance process to the users, to the community.
Given the controversy surrounding the directly relevant EIP #649, the issuance should also be reset to pre-Byzantium levels. It may be reduced again at a later time via a new hard-fork, only this time users would actually have a meaningful choice in accepting the change or not.
Remove Exponential Component of Difficulty Adjustment
For the purposes of
Reset Block, Uncle, and Nephew rewards
To ensure a constant Ether issuance, adjust the block reward to
(5E18 wei, or 5,000,000,000,000,000,000 wei, or 5 ETH).
Analogue, if an uncle is included in a block for
This is the existing pre-Byzantium formula for uncle rewards, simply adjusted with
The nephew reward for
This is the existing pre-Byzantium formula for nephew rewards, simply adjusted with
This will permanently, without further changes, disable the "ice age." It will also reset the block reward to pre-Byzantium levels. Both of these changes are specified similarly to EIP #649, so they should require only minimal changes from client developers.
This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. However, it may be controversial in nature among different sections of the userbase—the very problem this EIP is made to address. Therefore, it should not be included in a scheduled hardfork at a certain block number. It is suggested to implement this EIP in an isolated hard-fork before the second of the two Metropolis hard-forks.
Copyright and related rights waived via CC0.
Interesting! Would love to come back to ETH again if needed..Left supporting this network for months. However it will draw the whole GPU network here resulting in more higher difficulty. Still I support it as the hash will be within community not BITMAIN or someone similar's control.
I think this would actually make it worse since the companies making the ASICS would also enjoy the increase in block rewards, infact they'll benefit a lot more then the community due to economies of scale. (Example: with $1000 BITMAIN could build 3 asic miners. With $1000 the community can only afford 1 asic miner) Right now the only solution to give power back to the community is the move to Proof of Stake or change the code to be Asic resistance.
referenced this issue
Jul 19, 2018
Is there any study/article discussing if reducing block rewards is affecting decentralization aspects? E.g. when mining becomes not profitable in most western countries, who and with what incentives would want to participate in securing and keeping the chain alive ?
Tying the 2 separate issues, blockreward & bomb removal , together made a mess of the last EIP. Armchair economists made the thread woefully off topic. It was likely because no group would agreed to both on their own.
The bomb was a poor design decision in the first place, and randomly patching it to extend the delay is unsustainable. The intent of the bomb was to give leverage during the pos switch which never occurred. The community and developers have made it abundantly clear that this is the roadmap and miners are a short term third party that will be fired. If this social understanding is accepted, there is no reason to have needlessly inelegant code. Defuse the bomb.
Consider splitting this issnto two EIPs so the two issues can be discussed separately and/or implemented separately. The difficulty increase serves a different purpose from the reward decrease, and putting a change to both into a single EIP is likely to add confusion and struggle to the discussion.
Saying that something is optional but leaving it in the EIP doesn't really help address the confusion in discussion issue. People will discuss both intermixed and the EIP needs to pass all or nothing. To avoid this, just author two separate PRs, then people can freely discuss them in isolation.
@MicahZoltu I'm on the fence about that. I don't care enough about resetting issuance to champion a separate EIP for it. On the other hand, it is something that is directly relevant to the underlying motivation of the proposed change of defusing the difficulty bomb. I listed it as "optional" because I think the case can be made to not reset issuance ("let's not play around with the issuance any more than we already have, which is already too much"), and it can be removed entirely from this proposal if desired by the community, users, miners, and core devs.
Your EIP, so ultimately your call. I would advocate against this EIP getting included in a fork as written though, but I would probably be in support of an EIP that only removed the difficulty bomb. As it is, I don't have the energy to get stuck in a quagmire of an EIP discission that includes a rider.