ECIP-1023: Combined CarbonVote and MinerVote for Consensus Soft and Hard Forks #64
Conversation
So bill gates can spawn off a million accounts and sway a vote. This proposal doesn't pay enough attention to bad actors. |
I think voting contract should not propose a specific implementation and voting process, only an interface is important there |
@sjmackenzie Each address, when voted, is weighted by its ETC balance. So even if someone creates a billion accounts but if those accounts have zero balance, it would still be weighted zero. |
There is a reason I said 'bill gates'. |
@splix Can you be more specific about what you mean? The contract is only used to log YES and NO vote, just like how the current Ethereum CarbonVote works. Parameterize the specification would make it less confusing for end users, and it also simplifies the implementation -- we only need one implementation for ECIP-1023 in |
We discussed it today (together with #62), just putting my thoughts here:
|
@splix I agree with 1-3. Some comments with 4 and 5:
|
|
Hmm okay @splix, I forgot that putting 0 for gas cost. But if the miner puts 0 for gas cost, wouldn't the transaction fails and no state of the voting contract will be mutated? |
will work :) have them on testnet. But the point that it can be small amount, not necessary 0. Miners don't really want to set it to 0, because it affects average price of gas, which is against their business. Also fees are paid to themselves, so they don't really care about their own transactions I've made some calculations, using existing gas price and other metrics. It could cost $3000-$4000 per month for transaction fees, if every block has a voting transaction. This is about 0.02% of miner earnings for that period. Can be easily dropped to $1000/mo with a contract optimization and lower transaction fees (not zero, just say 10Mwei) |
Thanks @splix. But if the fee is not zero, the problem is that it is calculated into the block-level gas limit. Recently Ethereum scale problem tells me that this is a serious problem. If you think this is not that severe, what would be the reason? Also, just created a draft of the contract-only version of the hard fork voting (https://github.com/ethereumproject/ECIPs/blob/ecip1024/init/ECIPs/ECIP-1024.md). I would be really interested to see how we can modify the |
You just put transaction in front of others, it's not a problem there |
also, block limits gas amount, not gas price. |
@splix but even if I just put a transaction to myself, I know it wouldn't cost anything for me, but it would use some amount of the block |
Yes, every transaction costs something. That's how ethereum is designed, that's normal behaviour. Are we trying to fix network scale or fork decision by this ECIP? |
My worry is that if it costs, miners would rather not take it. This would make it the case that even when a hard fork is considered okay by most of the community, some miners would still not emit
|
@sorpaas that's up to you, I just said in that discussion that I don't think |
I like the general idea i think. Carbon vote has some limitations. I do not think contracts or exchanges should be allowed to "vote". It could be possible to have a "voter registration" period every Any issues passed by the community vote could then be issued as a miner vote. |
Information will needed to be in the implementation nontheless.
Vote contract uses event to log voting, this allows voters to change their minds. So implementations will need to filter out the voting results from the logs either way.
(Rendered)
This is an upgrade of ECIP-1022, and tries to take the opinions of both miners and coin holders during a hard fork. For a hard fork to pass, in addition to miners voting to pass (as defined in ECIP-1022), it also requires that a sufficient portion of coin holders to vote YES using Carbon Vote.
Motivation
In addition to the motivation provided in ECIP-1022:
ETC coin holders are important. Holders of coins should also have sayings about whether a hard fork should occur. CarbonVote, if it can be enforced, is a good way to do this.
Minimal cost for miners to emit support. The cost for miners to emit support should be minimal.
Implementation
See ECIP-1022 for how miners vote for a hard fork, and see this ECIP rendered for how coin holders vote using Carbon Vote. Basically, it requires both miner vote and carbon vote to pass for a hard fork to take effect.
Also note that unlike miner vote, carbon vote does not have the block window period. The coin holder vote is valid for the whole start..(start + timeout) range and the voting result is checked each time a window period ends.