You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Masari deployed my modification of Tom Harding's difficulty algorithm on December 3, 2017 and it's a resounding success (so far). I follow 7 coins' difficulty performance closely, and it's the best. For the best algorithms see here.
The charts below show Masari under the 3 difficulty algorithms it has experienced, and you can see how much it has improved. The 2nd and 3rd chart are only 3 days apart, so it's an "OMG" improvement. I should mention I am largely responsible for the middle algorithm that was so bad. Here is the full chart history of that algorithm.
Although the modified SMA (simple moving average) with N=17 looks worse than the Monero N=720 before it, the delay and "hash attack" metrics are equally bad. With Monero, blocks came 20% too fast (the 0.80 factor shown for solvetime), verses 36% too slow for the N=17. Less than target solvetime indicates the Monero algorithm has an asymmetry where the difficulty is able to drop faster than it can rise. This usually results from good intentions ("We don't want delays!") gone bad ("Let's modify the SMA.")
For a better chart with Masari's full history, see here
Sumokoin's modified SMA N=17 (with a 6-block delay) performed much worse for Masari than for Sumokoin, maybe because target solvetime for Masari was 1/2 that of Sumokoin (which means N should have been larger). Karbowanek has a simple N=17 SMA without a 6-block delay, and has 1/2 the "blocks stolen" of Sumokoin probably due not having the delay. Sumokoin's modified SMA is next_D=avg(D) * T / [0.80*avgST + 0.30 median(ST)
where ST=solvetime and T=target ST, and a 6-block delay in accepting D and ST values in order to prevent out-of-sequence timestamps (a bad idea). Masari says it appears miners were taking advantage of the median adjustment, and obviously a 6 block delay means 6 "free" blocks to big miners before the algo even starts responding.
I should mention the 3 coins here using N=17 is my fault. N=30 if not N=60 would have been a lot better for all of them. But from this past mistake, I have a better estimate on how to select N.
The text was updated successfully, but these errors were encountered:
Masari deployed my modification of Tom Harding's difficulty algorithm on December 3, 2017 and it's a resounding success (so far). I follow 7 coins' difficulty performance closely, and it's the best. For the best algorithms see here.
The charts below show Masari under the 3 difficulty algorithms it has experienced, and you can see how much it has improved. The 2nd and 3rd chart are only 3 days apart, so it's an "OMG" improvement. I should mention I am largely responsible for the middle algorithm that was so bad. Here is the full chart history of that algorithm.
Although the modified SMA (simple moving average) with N=17 looks worse than the Monero N=720 before it, the delay and "hash attack" metrics are equally bad. With Monero, blocks came 20% too fast (the 0.80 factor shown for solvetime), verses 36% too slow for the N=17. Less than target solvetime indicates the Monero algorithm has an asymmetry where the difficulty is able to drop faster than it can rise. This usually results from good intentions ("We don't want delays!") gone bad ("Let's modify the SMA.")
For a better chart with Masari's full history, see here
Sumokoin's modified SMA N=17 (with a 6-block delay) performed much worse for Masari than for Sumokoin, maybe because target solvetime for Masari was 1/2 that of Sumokoin (which means N should have been larger). Karbowanek has a simple N=17 SMA without a 6-block delay, and has 1/2 the "blocks stolen" of Sumokoin probably due not having the delay. Sumokoin's modified SMA is
next_D=avg(D) * T / [0.80*avgST + 0.30 median(ST)
where ST=solvetime and T=target ST, and a 6-block delay in accepting D and ST values in order to prevent out-of-sequence timestamps (a bad idea). Masari says it appears miners were taking advantage of the median adjustment, and obviously a 6 block delay means 6 "free" blocks to big miners before the algo even starts responding.
I should mention the 3 coins here using N=17 is my fault. N=30 if not N=60 would have been a lot better for all of them. But from this past mistake, I have a better estimate on how to select N.
The text was updated successfully, but these errors were encountered: