forked from amjuarez/bytecoin
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Difficulty algorithm needs re-doing #215
Comments
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>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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).
The text was updated successfully, but these errors were encountered: