ECIPs
ECIPs copied to clipboard
ethereumproject
ECIP-1017 ETC monetary policy and emission schedule
Some thoughts on ETC Monetary Policy, copied from https://ethereumclassic.github.io/assets/Ethereum_Classic_-_The_New_Original_Innovator.pdf
Platform token aligns economic incentives of users, miners and investors Current Ethereum monetary policy undefined (unlimited token inflation) ETH policy is supposed to change with a transition to PoS unpredictably Lack of token scarcity does not support long-term investor confidence ETC transition to a long-term PoW necessitates monetary policy decision ETC commitment to a specific monetary policy: provide certainty to the market boost investor confidence creates competitive differentiator to ETH with its undefined policies Fixing ETC Monetary Policy - Options:
Keep unlimited token inflation forever, like current ETH
Pros: keeps the status quo, encourages token spending Cons: long-term monetization uncertain, not a good store of value/investment Fixed final supply with Bitcoin-like reward cut-offs (halvings)
Pros: experimentally proven to work for BTC, sustainable token monetization due to scarcity Cons: changes existing inflationary parameters, disruptive “halving” events Fixed final supply with exponential reward adjustments (per epoch)
Pros: no disruptive “halvings”, sustainable token monetization due to scarcity Cons: changes existing inflationary parameters
Slack:@snaproll (sorry, can't find you on Github) started exploring ETC supply model here: https://docs.google.com/presentation/d/1jWTiJr7FmGjTyNj80-OapxDOiRGKVwmlkQ63LOnPO24/
Log of 2016-10-28 Monetary Policy discussion from Slack#development: https://docs.google.com/document/d/1jVM3iN1ClVrDjZ4AcJRAQyn24B1NN6Y5_X5IpLrT9Ss
Currently a Pull Request for ECIP-1017.
Reading through the details and will add my comments/concerns as necessary.
I am adding a reference to this issue on the published ecip, I plan to close the issue, if there is no objection, on block 3,277,945.
Thesis uploaded to GitHub for easier retrieval, if needed:
https://github.com/snaproII/Crypto/blob/master/ECIP-1017/Thesis.md
London Presentation slides uploaded to GitHub for easier retrieval, if needed:
https://github.com/snaproII/Crypto/blob/master/ECIP-1017/London_Presentation.md
The document should clarify how to calculate the rewards with regard to rounding down. Especially it should clearly define what constitutes a single rounded-down reward, and where rounding should be deferred.
In its current form, it may lead to different interpretations and implementations that may result in a network split in further eras. See these issues for details: https://github.com/ethereumproject/go-ethereum/issues/352 https://github.com/paritytech/parity/issues/6523
cc/ @snaproII
Here's my proposal for addressing these two possible discrepancies -- at least a place to start discussion from:
- Block winner reward calculation for a given era should use exponentiation, eg.
MaxBlockReward * 4^era / 5^era
Reasoning: rounding down happens once since a reward in this case is always singular and era number is an essentially arbitrary constant (for any given bock); only one block may be won at a time, and I see no reason for magnitude of era to "degrade" the singular block reward.
- Block winner reward bonus for including uncle(s) should use looping, eg.
UncleInclusionReward = 1/32
for (uncle in includedUncles) {
reward = reward + UncleInclusionReward
}
Reasoning: rounding down happens per uncle, since the reward in this case is variable; it may be for one or two uncles. Otherwise, far in the future when the time comes and rounding becomes an issue, a winning block with 2 uncles would get a proportionally higher per-uncle reward than a block with just one uncle. Since I don't see any reason to incentivize (however marginally) including 2 uncles over 1, I think calculation should be done per uncle.
Full disclosure: this is how it's currently implemented in geth classic. I'm not advocating these methods because I'm lazy and don't want to change, nor because I think I'm particularly right... they just seem to make the most sense to me, of course pending further counterarguments ;)
TODO:
- Include expected rewards tables
Block winner reward bonus for including uncle(s) should use looping
I think it's an implementation detail that should not be suggested in the document. Whether it's looping, addition, or multiplication it's all fine as long it's clear that the single uncle reward is already a rounded down integer.
a winning block with 2 uncles would get a proportionally higher per-uncle reward than a block with just one uncle.
This is certainly a good reason to formalise those rewards as such.
It should also be clarified that the dividend (block reward) in division by 32 should be rounded down prior to the division.