Modify Proof of Work Incentive Structure and Remove Difficulty Bomb

[atlanticcrypto]

This EIP addresses ancillary ETH issuance under the current Proof of Work mechanism, proposing changes to the ancillary reward structures and proposes the removal of the Difficulty Bomb.

[Arachnid]

Please provide a valid URL here.

[vbuterin]

I'm scared of this. With current uncle rates continuing to be around 20%, and continuing to greatly differ by miner with lows of ~8% and highs of ~40%, there are significant potential centralization risks if the reward differences between these pools are further exacerbated. Currently, Ethermine and Nanopool differ ~20% in uncle rates (0.7 vs 0.9); with current reward levels this leads to a ~3-5% difference in revenue, but with the proposal this could easily go up to ~15-18%. This could further increase concentration.

Furthermore, I don't think that we can get many networking improvements in the short term by "incentivizing" them in this way. Networking improvements are very likely a public good best addressed by the client and network level, or possibly in part by creating relay networks or some similar solutions.

[atlanticcrypto]

@vbuterin I agree - this is a backhanded incentive to fix the propagation issues. I think the tools are there for some of these mining pool networks to quickly address these issues. I think we would see a number of pools with HORRIBLE Uncle rates trim their transaction queues at first to keep their Uncle rates down, but quickly find ways to propagate faster. The recipe for success in a low Uncle rate isn't hard - it's just carefully crafting your infrastructure to propagate with little latency.

On the other hand, the large mining pools are economically encouraged to maximize their Uncle rate currently. Not saying any/most/all do it, but it's there. I think everyone agrees this is screwed up.

Like you said, a lot of this comes from the client and network level. We have seen large steps forward in propagation efficiency in the clients recently (geth just released their major miner rewrite, Parity 1.11.x had huge performance improvements).

I believe this is less risky than cutting the Block Reward from 3 -> 2 ETH. Unlike at Metropolis, cutting the Block Reward now will have an impact on the dispatch of mining hardware and will directly impact the amount of hardware securing the network. Rough net margins are presented here by each proposal.

I look at cutting the Uncle Reward structure as "Hey, we're probably over-secured right now, but cutting the Block Reward here is a really iffy call, let's at least get the incentives aligned."

[vbuterin]

I forgot to mention above, another thing that really worries me is that reducing uncle rewards would simply encourage miners to adopt a much simpler technique to cut down their uncle rate: stop accepting transactions. Given that there are already complaints about tx fees being too high due to congestion, this strikes me as a very unacceptable result.

On the other hand, the large mining pools are economically encouraged to maximize their Uncle rate currently.

I don't think that's true. If they make an uncle, they still get a lower reward, and miss out on transaction fees and nephew rewards. Also, Byzantium already introduced EIP 100, which makes difficulty retargeting target a constant rate of blocks including uncles, so large pools no longer have a perverse incentive to increase uncle rates to increase total mining rewards; total mining rewards are now very flat and do not increase in response to uncle rate changes (as they did before, eg. see the spike in Sep-Oct 2016).

Also, on top of all this, we should keep in mind that an uncle reward decrease would also have all the same risks as a regular proportional block reward decrease that achieves the same average daily total reward reduction.

IMO a much more unintrusive thing to try would be for us to talk to mining pools, make sure they're up to date, help the ones experiencing higher uncle rates to figure out what's going on and how to fix it, and possibly find a dedicated person to analyze where the p2p network inefficiencies are coming from and how they could be alleviated.

[atlanticcrypto]

I screwed up on the EIP100 piece. I missed that. I was aware it existed and blacked it out from my memory. My apologies.

I think a lot of these mining pools look at the transaction fees on the network and move their minimum gas price accordingly. If the network is congested, Pool X may begin to process transactions, otherwise they will minimize their Uncle rate. It's a pure P/L tradeoff for them, my idea was to skew it in favor of processing as many transactions as possible.

[vbuterin]

It's a pure P/L tradeoff for them, my idea was to skew it in favor of processing as many transactions as possible.

Right. And the way to do that is by minimizing the penalty they suffer from accidentally becoming an uncle, ie. keep the uncle reward at a fairly high fraction of the block reward.

[atlanticcrypto]

It feels really expensive to reward sub-par infrastructure like that.

I would hope the market response to an Uncle Reward reduction would be a tx fee increase to the point that they began including transactions again. My instinct would be to cut the Reward and let the tx fees be the equilibrium seeker. My instinct may be naive - or the transaction fee pool may be too low to provide a large enough incentive to do so. The other issue is that there has not been a study of transaction throughput and block propagation/Uncle rates - it's hard to optimize in the dark. We run our nodes at settings we believe are good, and they appear better than our relative peers, but we have no idea if they are optimal.

I also don't like carrots. I'm a stick kind of guy.

[atlanticcrypto]

I guess under either scenario someone is going to pay for the incentive to include transactions in blocks. It becomes a question of, who pays? Does the ecosystem pay with a larger Uncle Reward and higher total issuance, or does the user sending the transaction pay with a higher total fee? Never thought of it that way before...it's an interesting one.

Over the long term, it's probably better for the ecosystem to have the reduced issuance - but during adoption it's probably better to have lower fees per transaction.

[atlanticcrypto]

@vbuterin I thought about this a lot overnight and spent the morning talking with my crew. Over the past few days, the voices (many loud, many uninformed, but many thoughtful also) have weighed in. Based upon the current thinking over here, we're wondering if leaving everything unchanged might be a more prudent solution for the time being. We agree that the ETH denominated issuance may be too high, but we also believe that adjusting it under the current market conditions will put undue risk on the security scale of the network.

Understanding the economic implications of cutting the top line Block Reward, we thought a reasonable approach to adjusting the ETH denominated issuance would have been to cut the Uncle Rewards, but now after speaking with you, I believe it would just transfer the cost from the network to the user sending transactions itself. With the feeling that fees are too high on the network already, that doesn't seem like the best medium term outcome. What do you think?

At the end of the day, financing security for a technology with this much potential may be the most important thing over time.

Not married to these ideas, just some thoughts.

[salanki]

Based on reading the discussion here I've submitted an EIP that provides the same reward reduction without a change to the structure. It is intended as a measured reduction approach to provide data to support further decreases in latter hard forks. I would appreciate your feedback in the PR.