ECIP-1018 - Epoch Decay Monetary Policy Proposal

[mikeyb]

WIP - Numbers not accurate or verified yet

Google Sheet

Proposed Ethereum Classic Monetary Policy

Block Reward Adjustment Period: 1 Epoch (30,000 blocks)

Reward Decay Starting Block: 5,010,000 (Epoch 167)

Pre-calculated Decay Options

Decay Percentage	Miner Decay Amount	Uncle Decay Amount	Years to Decay	Estimated Supply (Current Reward)	Estimated Supply (1.5% Growth Reward)	Block Height Reward Ends
0.5000%	0.025000	0.002500	5.236872146	130,071,034.98	130,073,443.73	11,010,000
0.2500%	0.012500	0.001250	8.090753425	161,716,038.24	161,720,708.59	17,010,000
0.1250%	0.006250	0.000625	13.79851598	225,006,044.76	225,018,362.75	29,010,000
0.0625%	0.003125	0.0003125	25.2140411	351,586,057.80	351,991,724.60	53,010,000

Rationale

• Gradual decay of rewards to 0. Length of time depends on decay rate.
• Dead simple to understand. -- Starting at Epoch 167 (Block # 5,010,000) the decay activates -- Rewards for mining block start at: 5 ETC -- Rewards for mining uncled start at: 0.5 ETC -- Decay persists each Epoch until reaching 0, in which gas costs are the only collected fees
• Simple, nearly straight line supply growth on chart. Only fluctuation is gas rewards/uncle rates, as this is not predictable in all long term models.
• The Epoch Decay model provides a balance between providing an acceptable depreciating distribution rate for rewarding high risk investment into the system, and maintaining an active supply production over time, maintaining a future supply rate and keeping that potential price of the ethereum token suppressed enough to ensure transaction prices can remain lower than if the supply were to reduce to zero at an earlier date. This serves as a "blow off valve" for price increase in the case that a dynamic gas model cannot be implemented for the foreseeable future.
• Having the monetary policy reward decay begin at block 5,010,000 (Epoch 167) provides a balance between delaying the implementation to provide enough time for code development and testing, and accelerating the implementation to provide an incentive to potential early adopters and high risk investors. Based on community discussion, beginning before block 4,000,000 is too soon for development, testing, and implementation of the policy, and later than block 6,000,000 is too long to interest many potential early adopters/investors.
• Not changing the monetary policy of ETC provides no benefit to risk taking early on in the life of the system, speculation wise. It will be difficult for the network to bootstrap its security. While bitcoin has what is considered to be the generally accepted ideal monetary policy, with its 50% reduction every four years, this model is not likely to yield optimal investment for ETC. If ETC were to adopt the bitcoin halving model, it is arguable that too much of the supply would be produced too soon: 50% of the estimated total ETC supply would be mined 75% sooner than traditional bitcoin because of the pre-mine of 72,002,454.77 ETC that was initially created in the genesis block. While the Epoch Decay model does not completely eliminate the effects of the premine, since 50% of total estimated production occurs sooner than would the bitcoin model, it makes up for this, to an extent, depending on how much decay is decided upon.
• In the current ETC reward schedule, the total reward for uncles is higher than the reward received by the miner who also includes uncles. In this state, a miner is significantly diluting the value of his reward by including these uncled blocks. By equalizing the rewards to uncle block miners with the rewards to miners who include an uncle block, the reward structure is more fairly distributed. In addition, equalizing the uncle rewards reduces the incentive for miners to set up an ETC "uncle farm," and instead drives them to better secure the network by competing for the latest "real block."
• Because the rate at which uncled blocks can vary with extreme, reducing the reward for uncle blocks assists considerably with being able to forecast the true upper bound of the total ETC that will ultimately exist in the system.
• The model is the best attempt at balancing the needs to incentivize high risk investment into the system in order to bootstrap security and create a potential user base, be easy to understand, include a reduction to the rate of production of ETC over time, include an upper bound on supply, and also provide for a long term production of the ETC token.

[elaineo]

What happened to the discussions around ECIP1017?

[mikeyb]

They are still ongoing. But I really dont feel we should only have 1 option to discuss. Not trying to steal the show, just trying to open options to different angles for a solution.

[elaineo]

@mikeyb okay. The original intention was to have the discussion organized in a single ECIP1017 since we will only be implementing one. If there is still contention about ECIP-1017, then it should not be accepted as an ECIP yet. @snaproII

[mikeyb]

Well my proposal and @snaproII's proposal are completely different. So different proposals felt necessary. Though your statement makes it clear that you guys are not looking for other options, just comments on the single option the community has been given. If such is the case, feel free to close out my proposals as they are meaningless.

[arvicco]

@elaineo I would say that this is a competing proposal to ECIP-1017, not a modification or improvement of @snaproII's proposal - so IMHO a separate ECIP number is completely justified. Not all ECIPs will end up being implemented - same as not all BIPs ever make it into a code base.

@mikeyb Let's not jump to conclusions based on a single feedback, shall we? ;)

[mikeyb]

Not just the single feedback above. In general this is the feeling I get when proposing ideas to this community.

Hint: I am not the bears

It is what it is. Going to try and teach myself some Golang so I can attempt to implement this ECIP (and 1019) into code for further review and testing. I already know the core team is pushing forward with ECIP-1017 mentally, if not physically already. I am definitely not against 1017, I think it is quite solid and will happily use it. My problem comes with the lack of choice our community and users are getting. I just wanted us to at least be able to say "We considered other options and chose the best one" instead of "We went with the first and only option".

I support whatever choice we go with, but I really want everyone to have a real option to choose. I feel the choice has already been made for us. 1017 will get the man power needed to see its code come to life where my proposal is going to be left solely up to me to develop, which means there will be only one choice. Ideally I would have loved to see at least 2 choices developed and tested, then put on the network for the network to decide which one activates.

I think my conclusions are quite valid and almost certainly correct.

[arvicco]

@mikeyb I'm definitely going to look into your ECIP and comment on it. From a historic perspective, per-epoch decay is something we discussed with @snaproll at the very beginning. Part of the reason why we moved from it was "the uncle problem" - leaving uncle rewards as is created just too much of uncertainty regarding the final cap.

[mikeyb]

Agreed. In both of my proposals Uncles have been scaled down to 10% of miner reward with 2 uncles allowed per block and decay at the same rate as miner rewards. How feasible this is in code, I don't know yet. But I certainly don't want to spend much more time on this if the consensus is to go with 1017.

[realcodywburns]

What status would you like this discussion to be: Active, deferred, or withdrawn, miko? and do you mind if i chang the ecip number and move it to a pull request?