Difficulty algorithm needs re-doing

[zawy12]

About 10 Monero clones that I'm aware of have used my difficulty algorithms in order to stop a disaster created by Cryptonote's difficulty algorithm. The N=720 when T=120 seconds for the simple moving average is way too slow and causes enormous delays in small to medium size coins. They have to fork to a new algorithm or abandon the coin. Cryptonote's difficulty algorithm has probably caused a graveyard of coins. Here's 5 examples of Monero/Cryptonote clones that have switched to my LWMA difficulty algorithm and are now actually functioning. You can peruse links to their modifications of Cryptonote code at that link. One has submitted a pull request to Monero.

I don't know what all the "cut" and "lag" stuff is in the current algorithm, but it seems like maybe 500 lines of cryptonote code could be replaced with the following 2 line which is a complete difficulty algorithm, and the Cryptonote graveyard would stop filling up.

ST = min(T*6,max(ST, -5*T)
next_target = prev_target*(30+ST/T/0.984-1)/30

where T=target solvetime and ST=solvetime of the previous block. The 0.984 enables perfect avg solvetime. This is Tom Harding's simplified version of Jacob Eliosoff's EMA (exponential moving average) with my selection of 30 and determination of 0.984.

A third option to fix this disaster that is not near as good as LWMA and EMA is to just change the default N in your algorithm from N=720 to
N = int(0.5+40*(600/T)^0.3))
This is for micro to small coins. N can be larger for bigger coins. I give a background to this equation here. Similar to this is to change the line:
const size_t DIFFICULTY_WINDOW = EXPECTED_NUMBER_OF_BLOCKS_PER_DAY;
to
const size_t DIFFICULTY_WINDOW = int(EXPECTED_NUMBER_OF_BLOCKS_PER_DAY/10);

Except it's not going to work good if T is > 240 seconds. I'm not sure this divide by 10 has the effect I expect because it looked like N=720 was hard-coded in other places.

The goal in selecting N (and using an algorithm better than SMA) is to not be so slow that price changes a lot before difficulty. If the (price+fees)/difficulty ratio goes 30% too high, a medium size coin can expect 3x more hash rate to suddenly jump on. Then long delays result when they leave. N=720 window with T=120 in an SMA estimates the average hashrate over the past 24 hours, so the difficulty ends up being 12 hours behind price. It needs to be about 1 or 2 hours behind. You can't go faster with an even smaller N (like I used to recommend with N=17) because difficulty will randomly vary too much which again causes the P/D ratio to go high (because the D drops on accident) which again invites hash attacks that lead to delays when they leave. N=60 is good for coins with T<240, but my equation for N above is better. Expected random variation due to N can be estimated with 1/SQRT(N).

[SoraKohaku]

zawy fixed on evo xD

…

On 3/21/18, zawy12 ***@***.***> wrote: About 10 Monero clones that I'm aware of have used my difficulty algorithms in order to stop a disaster created by Cryptonote's difficulty algorithm. The N=720 when T=120 seconds for the simple moving average is way too slow and causes enormous delays in small to medium size coins. They have to fork to a new algorithm or abandon the coin. Cryptonote's difficulty algorithm has probably caused a graveyard of coins. [Here's 5 examples](zawy12/difficulty-algorithms#23) of Monero/Cryptonote clones that have switched to my[ LWMA difficulty algorithm](zawy12/difficulty-algorithms#3) and are now actually functioning. I don't know what all the "cut" and "lag" stuff is in the current algorithm, but it seems like maybe 500 lines of cryptonote code could be replaced with the following 2 line which is a complete difficulty algorithm, and the Cryptonote graveyard would stop filling up. ``` ST = min(T*6,max(ST, -5*T) next_target = prev_target*(30+ST/T/0.984-1)/30 ``` where T=target solvetime and ST=solvetime of the previous block. The 0.984 enables perfect avg solvetime. This is Tom Harding's [simplified version](zawy12/difficulty-algorithms#21) of [Jacob Eliosoff's EMA](zawy12/difficulty-algorithms#17) (exponential moving average) with my selection of 30 and determination of 0.984. A third option to fix this disaster that is not near as good as LWMA and EMA is to just change the default N in your algorithm from N=720 to ```N = int(0.5+40*(600/T)^0.3))``` This is for micro to small coins. N can be larger for bigger coins. I give a background to this equation [here](zawy12/difficulty-algorithms#14). Similar to this is to change the line: ```const size_t DIFFICULTY_WINDOW = EXPECTED_NUMBER_OF_BLOCKS_PER_DAY;``` to ```const size_t DIFFICULTY_WINDOW = int(EXPECTED_NUMBER_OF_BLOCKS_PER_DAY/10);``` Except it's not going to work good if T is > 240 seconds. The goal in selecting N (and using an algorithm better than SMA) is to not be so slow that price changes a lot before difficulty. If the (price+fees)/difficulty ratio goes 30% too high, a medium size coin can expect 3x more hash rate to suddenly jump on. Then long delays result when they leave. N=720 window with T=120 in an SMA estimates the average hashrate over the past 24 hours, so the difficulty ends up being 12 hours behind price. It needs to be about 1 or 2 hours behind. You can't go faster with an even smaller N (like I used to recommend with N=17) because difficulty will randomly vary too much which again causes the P/D ratio to go high (because the D drops on accident) which again invites hash attacks that lead to delays when they leave. N=60 is good for coins with T<240, but my equation for N above is better. Expected random variation due to N can be estimated with 1/SQRT(N). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #215

-- Nur1Labs©2013

______________________________ Site Info -> Here <http://nur1labs.com/> Easy Transaction MoneyBookers <https://www.moneybookers.com/app/?rid=17274145>