Rework the Uncle Rewards to Decentralize Miner Emission

[stevanlohja]

ref: #461 (comment) topic by @gitr0n1n

[gitr0n1n]

This has been noted in the discord numerous times. We likely need to look at how our uncle rewards are currently processing and adjust this to help decentralize the mining emission. Please add to the discussion if you're informed on this. I'd like to get an ECIP in motion on this one when the miners have had a chance to give their input on what they think is the best incentive for network security for the long-term while we work our way through the 5M20 monetary policy.

it's my understanding these rewards dropped off in Era 3 or 4 of the 5M20 and feedback from miners is that it has a negative effect on the incentive system.

Pulling Discord discussion over:

If the miners in here can add value to this discussion. I believe @crazypool2019 had some opinions on this topic. I'd love to see the miner opinions of the uncle rewards moving forward materialize into this GitHub document to have an accurte/informed record for reference to a future ECIP addressing this concern/suggestion/improvement to the mining incentive system.

[gitr0n1n]

From @crazypool2019:

well, in ETC the 1x Block = 32x Uncles, this generates a problem for small pools since we must consider that the mining will have a tendency to 100%, so a pool can send 100 valid nonce and 2 of them could be uncle for a reorg, then this pool needs another 64 valid nonce to compensate for those 2 uncles, this does not help decentralization since miners in theory will obtain better rewards in a larger pool where the uncles are diluted among the hundreds of daily blocks, however there are other variables that the pool manager can use to improve miner rewards using the EthereumStratum-1.0.0 protocol decreases the number of duplicate shares generated by miners, duplicate shares have no value and if the pool pays them the same way, it will do so with the profits of all miners who sent valid shares

shares_duplicated_rate = worker_pools / (256^3)
a pool like ethermine (ETC) with 80578 works will have an estimated 0.48% (80578/256^3) of duplicate shares

shares_stales_rate = latency / block_time
if
latency = 60ms
block_time = 13000ms
stales_rate = 0.46%

In this way, if the pool has nodes in "strategic" places, it could reduce the amount of shares stales received.

In conclusion, increasing the value of the uncle blocks should improve the profitability of small pools and invite miners to decentralize mining, maintaining an uncle_reward of 0.1ETC will be a problem when the nethash of ETC increases because as the nethash increases, so does the expected rate of reorganization will increase

In ETH it is possible to see hundreds of daily reorganizations, and each reorganization generates an uncle block

[gitr0n1n]

From @wpwrak:

wpwrak — 01/28/2022
hmm, are duplicates even an issue if you do things properly ? i.e., with extranonce, you keep miners out of each other's hair. so all you need to do is reject duplicates from the same miner, and then you shouldn't have any at all, no ?
regarding uncles vs. small pools: but don't big and small pools have the same uncle-to-uncle ratio ? i can see why having a lot of uncles (which have a very low value on ETC) may make it more difficult to calculate correct shares, at least in some cases.

[gitr0n1n]

From @crazypool2019:

Mr. Crazy — 01/28/2022
It should be like this, but chain reorganizations are generated by larger pools when for example they mine block 1 and then rewrite everything when mining the next block

example

that was a valid nonce, a block, but few seconds after change to uncle

that was a "reorg"
bad example
in this case the next block was mined by other pool, that is normal, others case is different

The concrete example would be:
1. small pool mine block height x
2. large pool mine block height x
3. small pool gets the canonical chain
4. large pool mine block height x+1
5. large pool removes block height x from small pool
6. now large pool has block height x and x+1 
the large pool has a higher probability of mining 2 consecutive blocks compared to the small pool

I have seen this happen many times on ethereum network

[gitr0n1n]

From @wpwrak :

wpwrak — 01/28/2022
ah, i think i understand the mechanism: big pool mines block X, about which it knows immediately. then it has a better chance of block X + 1, where it may also be first, or nearly so, not being an uncle. and so on for X + 2, etc. while a small pool won't have large runs of consecutive blocks where it is first/early, and thus can't protect its blocks from becoming uncles as much as a big pool can. is this what you mean ?

[gitr0n1n]

From @crazypool2019:

Mr. Crazy — 01/28/2022
yes. a small pool can propagate its chain quickly and correctly, but a large pool can ignore the chain of the small pool and continue on its own by taking everyone in its chain, it is normal, but it would be good to consider increasing the value of the uncles blocks and thus mitigate the impact of uncles on the profitability of small pools

stats for 90 days:

stats for 24h

[gitr0n1n]

From @wpwrak:

wpwrak — 01/28/2022
ok, that makes sense. and a better uncle reward would not prevent this, but it would make this less painful. on the downside, we may get a bit more uncles, since it would make sense for a pool to keep looking for them even if it already knows that there's a new block. but that's probably negligible. (big can ignore) ah, that would even be an attack scenario, indeed

[gitr0n1n]

From @crazypool2019:

Mr. Crazy — 01/28/2022
I would say unintentionally ignoring because they mined the block in their chain less than 100ms apart, so they started work on the next block before they knew it was already mined by another pool.

[gitr0n1n]

From @wpwrak:

wpwrak — 01/28/2022
i guess the big pools are playing nice, else we'd already have an ethermine monopoly, but that doesn't mean such a vulnerability should be ignored. good point.

[gitr0n1n]

From @crazypool2019:

Mr. Crazy — 01/28/2022
everything is part of the mining and PoW system, everything described above is normal, I just see the need to encourage decentralization and such a low uncle_reward can be a bigger problem in proportion to the nethashrate of ETC

more nethashrate => more reorg daily

[gitr0n1n]

From @wpwrak:

wpwrak — 01/28/2022
yes, it's an unfairness implicit in the protocol in a non-ideal environment (i.e., real life). and that unfairness could even be exploited (without the exploiter getting into any real trouble).

i guess we should also consider scenarios where high uncle rewards could incentivise mining uncles over extending the chain. e.g., if an uncle paid more than a non-uncle block, then miners would have an incentive to stay on the same tip of the chain almost forever, and just add uncles. they could even vary their content, e.g., to incorporate new Tx. not sure if such a degenerate chain would actually be a problem, since you eventually have to add new non-uncles to generate uncle rewards, but it would certainly look funny.

the question would be then what a good uncle:block value ration would be, to make uncles profitable without creating perverse incentives. (perverse incentive = encourage people to do something you don't want to happen. e.g., a bounty on dead snakes, with the expectation that people would hunt snakes and thus reduce their population, leading to people instead breeding snakes. famous experiment in india :)

i wonder if there are any other downsides to uncles ?

[gitr0n1n]

From @crazypool2019:

Mr. Crazy — 01/28/2022
that's a very interesting point, at this moment any ratio greater than 1:32 is better than current, maybe 1:2 is more correct, uncle_reward = 1.6ETC should compensate for the problem explained and avoid the proposal of an UnclePool, like also encourage decentralization, the increase in uncle_reward also implies increasing the emission and with that inflation, it may be necessary to do the calculations to select a better time between ERAs because 5 million blocks does not seem to mitigate inflation correctly
"halving" 20% each 5000000 blocks

[gitr0n1n]

From @wpwrak

wpwrak — 01/28/2022
aah, the "fifthening"

for ETH, it's still 2 ETH per block and 1.75 ETH for (1st gen) uncle ? (so, very close)

[gitr0n1n]

From @crazypool2019

Mr. Crazy — 01/28/2022
Right 1.5 2gen

[gitr0n1n]

From @wpwrak :

wpwrak — 01/28/2022
Mr. Crazy "better time between [fifthenings ...] to mitigate inflation" what is your observation, that the fifthenings are not aggressive enough, that they are too aggressive, or that they simply have no clear effect ?

[gitr0n1n]

From @crazypool2019:

Mr. Crazy — 01/28/2022
the fifthenings are not aggressive enough
maybe 20% every 2500000
really i dont know what is better

[gitr0n1n]

From @wpwrak

wpwrak — 01/28/2022
regarding the effect of a nethash increase, i'd guess that this doesn't matter so much. i.e., if nethash simply increases, the small pools would get more blocks, and the overall distribution would stay the same. however, if a most of the new hashrate goes to big pools, then we may see increased unfairness.
there's also another problem with migrating miners preferring large pools: they may become dominant. things aren't pretty on the pool distribution side already: ethermine has 43% of the nethash, hiveon (#2) has 11%, 2miners (#3) has 8.6%.
so if someone were to take over ethermine plus one of the others, they would control > 50%.
also, if they wanted to do a 2020-style attack, maybe they could begin with a denial-of-service strike against ethermine. have that acts as a diversion as well, and save themselves 40% of the mining cost of the attack.
so i think encouraging a more even participation of pools would be good for the robustness of ETC in general.

do we know roughly the average block propagation time from pool to pool ? i.e., how much time passes between pool X finding a block to pool Y seeing it ?

any client developers here who may have measured this ?

if you're running clients in different geographic locations, you may actually be able to find this information in your logs. at least i would guess that block submission and block arrival might get logged, with a reasonably accurate timestamp. (but then, not sure - i don't run any clients.)

wpwrak — 01/29/2022
it's a rather interesting point indeed. for three reasons: 1) looking at pool performance stats, it seems that there is indeed a significant disadvantage for smaller pools. (look at the ratio between blocks found and hashrate). 2) there is a potentially very significant weakness, in terms of competition among pools, fortunately not exploited yet (and somewhat difficult to exploit, but possible). 3) pools are just as much of a centralization point as anything else. ETC is already in a very lopsided situation, regarding pool competition, and it could easily get worse. "lopsided" is bad, because a pool enjoying a monopoly is not only a risk if it decides to go rogue (i doubt there is any risk of that), but also if it gets successfully attacked. so we should try to avoid pools from getting centralized. making sure small pools can successfully compete would be a part of this.

oh yes, 4) pretty much off the radar so far :)

[gitr0n1n]

The Uncle Rewards Topic starts to enter the conversation on ETC Community Call 012:
https://youtu.be/GCBv1VCN2tE?t=6095