foodies i think youl be happy with this:
Proposal: Alternative solution to the multi-pool abuse and a check&balance to the fairness of coin distribution per Algorithm. Without changing difficulty re-targeting
This way we do not have to worry about the legitimate concern held fast by Foodies; in that changing the difficulty re-targeting structure currently in place.
(Each Algo = Difficulty re-targeting Per Block + 10 Block Lookback)
Simple:
Coins per block for AlgoX = 1000 if change in average difficulty previous 10 blocks (average difficulty used in the 10 block lookback) is not > than the X%.
IF previous 10 blocks (average difficulty used in the 10 block lookback) IS > than the X%.THEN Coins per block for AlgoX = 1000 - [absolute value of] X% change in change in average difficulty previous 10 blocks (average difficulty used in the 10 block lookback).
----
This will allow the market to handle the multi-pool problem because a multi-pool which targets MYR for profitability will have to also have to take into account that insta-mining 9+ blocks will not be profitable. Instead the multi-pool becomes our best friend in that if an algo is more profitable than bitcoin it will just mine 1 or 2 blocks because if it targets an algo with 1000+X the average difficulty of the last 10 blocks the % of coins will decrease proportional to the resulting massive increase in difficulty it will cause by doing so.
Also the 20% 20% 20% 20% 20% will be supported because instantly mining blocks will not occur as often.
This will also help but not entirely solve with the problem of a POSSIBLE (i dont know if that can happen) fork of the entire coin due to 9+ blocks of the same algo in a row rather than each algo solving blocks regularly.
...........................................
If you dont want to use average % of difficulty change over previous 10 blocks we c We can substitute it with the variable of TIME per block.
...........................................
Coins per block for AlgoX = 1000 if change in average TIME per block for the previous 10 blocks (average TIME used in the 10 block lookback) is not > or < X% change in average TIME per block for the previous 10 blocks - 2.5minutes. ... ... ... ..
..........................................
We all know there is a problem with a multi-pool mining 10 blocks of the same algo in a row near instantly. This way the difficulty retargets as usual so we dont run the risk of a frozen algo (as the 10block lookback intended).
Foodies it took me a while but i now see how important the 10block lookback is and the risk of changing it resulting in an impossibly high difficulty. thank you.
So what threshold would you recommend for the percentage change of difficulty that determines if a block gets less coin reward?
Feel free to ask for clarification or why this or that from the above.
I have some ideas but the threshhold is a very important variable.. other than the simple 0 to keep everything consistent for example:
If X =
X% then coins = 1000 - (X% of 1000)
(obviously The 1000 is the current # of coins block reward ..)
0% then coins = 1000 - (0% of 1000) = 1000
-X (X is less than 0) then coins = 1000
Any other threshhold idea than 0 may be complicated or contravercial so it may be best to let our Dev to decide unless otherwise stated by dev.