Complaints about difficulty algo? (and a fix for all difficulty osciallations?)

[zawy12]

Strong suggestion: N=50. This needs a slight adjustment to sum(solvetimes) to be multiplied by 1.01 to keep solvetime more correctly on track. If two bad forward stamps in 3 occur as on accident or 50% miner, D can be sent down by 1-(50/62) = 20% (verses 8% for N=144). This will be immediately erased with the next honest timestamp. This is an argument for not going below 50.

There is concern about miner profit motivation and N=144 potentially having oscillations due to this. Those oscillations will not get out of hand. It happens in all diff algos. You can't put a filter on it to fix it. I've explained the theoretical reasons why filters don't work.

You'll get the same delays per block with N=50 and maybe even a little worse, but instead of 30 or 40 blocks with long delays, you'll have only 10 to 15 (with N=50). Low N is just to make these cycles happen faster and more frequently so any given post-attack delays are not long. Lower N allows price and difficulty to stay closer in sync. That's the key to my email yesterday when I showed N=144 is 12 hours behind, while Degnr8's WT with N=50 is only about 3 hours behind. You still might have 90 minute delays at times, but they will be for only 10 blocks instead of 40. And really, on the mainnet it won't be that bad.

I have a fix for this. I didn't mention it because I've been busy trying to convince everyone to get off the large N.

CoinReward = BaseReward * avg ( past N solvetimes) avg (past 2N solvetimes)

Ta-da. This solves all other difficulty problems. I call this Zawy v5, but now I've got to call it something else to use Degnr8's WT. I need to mention Tim Olsen suggested the general idea of modifying coin reward based on difficulty, and karbowanek coin reminded me. The interesting thing is that coin reward release stays perfectly on time. I sort of guessed at the 2N part. I like the results so well I have not tried anything else. An interesting aspect is that if solvetimes start getting out of the 100-block average, the rewards or punishes miners to get it back on track.

The chart below shows the results with WT=50. The magenta line is coin reward per difficulty. Notice that the attackers begin when the reward/difficulty is the highest, the best time to get profit. But notice how it collapses as soon as they begin an attack.

Getting back to possible complaints about the current simple algo under proposal:

The total time limits 2x and 1/2 are merely not needed, so they're not bad.

WT would be better, but I'll acquiesce on that.

Argument for what median of 3 is not needed, but I'm OK with it: The median of 3 prevents all damage from bad timestamps as long as it's not a > 50% attack and as long as they do not do anything else to block negative solvetimes or reverse timestamps. This comes at a cost of being 1 block slow all the rest of the times where there is not a timestamp error. So with or without the median of 3, it's good, as long as nothing else is changed. For example (max-min) on N timestamps like many coins do is not optimal like sticking with (last-first).

[schancel]

Manipulating the coin reward is an interesting idea, but definitely controversial. Why are you suggesting sum( past N solvetimes) / sum (past 2N solvetimes) vs 2 * sum( past N solvetimes) / sum (past 2N solvetimes) ?

[zawy12]

I should not have recommended it without qualification. It can be brutal in discouraging hash attacks, but it is equally brutal the first few blocks after an attack to the constant miners. It certainly requires a lot of testing and thought about what the result could mean.

You're right about the sums. That's an error. Those are supposed to be averages. I'll correct it in the post above.

[angelexevior]

Hey guys. Guess this issue can be closed now after the fork complete. Just had a wild thought for future consideration if we fall into diff issues again. Since the backbone are miners, I'm thinking along the lines of establishing balance and predictable outcome based on current total hashrate. Current diff aligned dynamically with current total hashrate by a price factor to establish a fixed stable outcome that will fluctuate along with it's price. Our biggest ever problem is caused by network instability (hash attacks, migrations etc) and so is the problem of miners. If we achieve a stable predictable income for miners they will surely come onboard and stick to it.

[zawy12]

Miners are paid to be selfish (not cooperate), to get the correct solvetime, and to be paid coin at a known emission rate. Any effort to give them a stable difficulty or income will act against these objectives.