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.
Personally I also find switching-pools annoying, but they are something we have to live with in some way. With quick difficulty retargeting, the effect of switching-pools are mitigated to some degree.
A simple idea previously proposed is to not allow more than X blocks in a row from the same algorithm. X could be something like 5.
This was proposed not as an anti switching-pool idea specifically, but to mitigate the effect of a variety of potential attacks against a single algorithm.
This is a more sudden cut-off than your proposed gradual difficulty adjustment, but has simplicity on its side.
I support implementing a change similar to this, but it will require a hard fork of the block-chain to implement.
A hard fork at this stage requires a lot of coordinated updating, including wallets, daemons, Electrum, Android, etc. and should be done with care, planning and a very good reason.
