-
Notifications
You must be signed in to change notification settings - Fork 8
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'upstream/master'
- Loading branch information
Showing
32 changed files
with
3,951 additions
and
16 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
### ETC Improvement Proposal Management | ||
|
||
ECIP: 1016 | ||
Title: ETC Improvement Proposal Management | ||
Status: Draft | ||
Type: Process | ||
Author: Cody W Burns <[email protected]> | ||
Created: 2016-10-25 | ||
|
||
### Abstract: | ||
The Current ECIP process is chaos. ECIPs are created in random number order without adequate means of tracking changes or monitoring status. During the forming phase of ETC this was somewhat acceptable. Moving forward the process needs to be made clearer to facilitate clearer communication to all participants | ||
|
||
### Implementation | ||
All ETC Improvement Proposal should be submitted as pull requests with the format ECIP-`n` with `n` being the number after the previous ECIP. This allows for change tracking and historical monitoring. | ||
|
||
Every ECIP Should be tagged with a milestone for its current status | ||
`Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded` | ||
|
||
Every ECIP Should be tagged with a label for its type and layer: | ||
`Standards Track | Informational | Process` | ||
`Consensus | Networking | API/RPC | Applications` | ||
|
||
Every ECIP should follow https://github.com/ethereumproject/ECIPs/blob/master/ECIP-0000.md.sample as closely as practical. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,84 @@ | ||
### Title | ||
|
||
ECIP: 1018 | ||
Title: (Epoch Decay) Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule | ||
Author: Mike Boremi <[email protected]> | ||
Status: Draft | ||
Type: Standard | ||
Created: 2017/01/19 | ||
|
||
### Abstract | ||
|
||
This ECIP proposes a solution to the Ethereum Classic Monetary Policy to adjust, with absolute finality, the current emission schedule implementation of 14.0625ETC per block in perpetuity. The solution proposed introduces a hard limit upper bound on the maximum absolute number of ETC and introduces a method of degraded emission over time. This occurs in such a way there is a constant decay in miner/uncle reward every epoch until reaching 0, where gas fees are the sole source of reward. This proposal does not include any solution to changes in protocol introducing PoS or other block forging scheme. | ||
|
||
### Motivation | ||
|
||
At its core, the purpose of adjusting the current monetary policy of the ETC network, to a policy which places a hard limit upper bound on the number of tokens issued and decreases the rate at which ETC is introduced into the system over time, is to "bootstrap" the network’s security. By increasing the security of the network, a proper monetary policy indirectly nurtures the network, providing a secure platform for which smart contract development will be more likely to occur. | ||
|
||
If we accept that speculation, a demand function, is the main economic driver of any new system, that the Ethereum Classic Network is a new system, and that speculation will drive the value of the Ethereum Classic token until the utility value of the Ethereum Classic token exceeds its speculative value, it is reasonable to assume that rewarding speculation will help to secure and nurture the network: | ||
|
||
Large scale, high risk, and/or high profile applications will be less likely to be developed on a blockchain with weak security ie. a low hashrate. Increasing demand for the Ethereum Classic token will, all else being equal, increase the price of the Ethereum Classic token. An increase in the price of the token incentivizes mining operations to direct their efforts on the Ethereum Classic Network or to begin operations on the Ethereum Classic Network. The additional mining power that is directed towards the network, because of this incentive, further secures the network. An increase in the security of the network assists in building trust between the network and both current and potential users and developers of the network. This increase of trust in the network provides an incentive for large scale, high risk, and/or high profile applications to be developed on the network. Thus, rewarding speculation helps to secure and nurture the Ethereum Classic network. | ||
|
||
Especially important to early stage cryptocurrencies, assuming all other variables are equal, a network with a decreasing rate of production and an upper bound on the number of tokens that will be issued will provide more incentive for high risk speculation to occur than one without a known rate of production or an upper bound. | ||
|
||
Above all, it is important to recognize that a monetary policy does not directly create value for the network. A stable platform with useful applications and a vibrant community are the variables that drive value. The purpose of a properly structured monetary policy is to create an incentive for people to take a risk on a system that has not yet reached its full potential, providing an additional reason for those who may not otherwise be interested, who cannot or have not developed anything on the platform (yet), or who remain skeptical, to involve themselves in an otherwise nascent platform. | ||
|
||
### Specification | ||
|
||
#### Current Ethereum Classic Monetary Policy | ||
|
||
[Source](http://ethdocs.org/en/latest/mining.html) | ||
|
||
![image alt text](https://cloud.githubusercontent.com/assets/36461/22116162/e3c0a2f2-de2c-11e6-8ab3-38452b3486bc.png) | ||
|
||
The current mining rewards on the Ethereum Classic Network are as follows: | ||
|
||
* A "static" block reward for the winning block of 5 ETC | ||
|
||
* An extra reward to the winning miner for including uncles as part of the block, in the form of an extra 1/32 (0.15625ETC) per uncle included, up to a maximum of two (2) uncles. | ||
|
||
* A reward of 7/8 (4.375ETC) of the winning block reward for a miner who has mined an uncled block and has that uncle included in the winning block by the winning miner, up to a maximum of two (2) uncles included in a winning block. | ||
|
||
* This reward structure is set to continue in perpetuity. | ||
|
||
#### Proposed Ethereum Classic Monetary Policy | ||
|
||
[Source](https://docs.google.com/spreadsheets/d/1itL2prCC6f5p__RmiU_svWlNkyL0vRdqu8FCz5ca7v0/edit#gid=1694393546) | ||
|
||
![image alt text](https://cloud.githubusercontent.com/assets/36461/22131547/65e6f544-de71-11e6-8ab7-2c7a361d19e7.png) | ||
|
||
##### Block Reward Adjustment Period: `1 Epoch (30,000 blocks)` | ||
|
||
##### Reward Decay Starting Block: `5,010,000 (Epoch 167)` | ||
|
||
##### Pre-calculated Decay Options | ||
|
||
|Decay Option #|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| | ||
|--------------|----------------|------------------|------------------|--------------|---------------------------------|-------------------------------------|------------------------| | ||
|1|0.5000%|0.025000|0.002500|5.236872146|130,071,034.98|130,073,443.73|11,010,000| | ||
|2|0.2500%|0.012500|0.001250|8.090753425|161,716,038.24|161,720,708.59|17,010,000| | ||
|3|0.1250%|0.006250|0.000625|13.79851598|225,006,044.76|225,018,362.75|29,010,000| | ||
|4|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. | ||
|
||
### Implementation | ||
|
||
* Timeline for the implementation and the code required to execute after approval. | ||
|
||
##### Shout out to @snaproll for the great ECIP template to use. Your time on this is greatly appreciated. | ||
|
Oops, something went wrong.