-
Notifications
You must be signed in to change notification settings - Fork 25
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
LWMA: 500,000 blocks of data in 10 coins #23
Comments
Hey, how did you make these graphics? |
Realmente, na Niobio cash todos os mineradores gostaram muito do resultado |
Iridium ProblemIridium was possibly the 2nd coin to start using LWMA and had a great history of using it. However, right before their POW fork to reduce hash attacks, hash attacks were causing significant problems. These were not timestamp manipulations. They had a stricter upper limit on solvetimes (+6xT instead of +7xT or 10xT) which made delays a little longer, but prevented difficulty from dropping anymore than it did. Each plot is about 1 day. The last plot where it drops is the POW change. In reviewing the difficulties and solvetimes, it is clear a faster LWMA is needed to rise more quickly, as long as it does no come at acost in stability. So I sped up completion of the D-LWMA. The delays are a problem and the D-LWMA can't reduce them in this case. Removing the +6xT will help, but it will also cause the D to drop lower which can bigger oscillations which end in even longer delays. This motivated me to come up with an additional feature in the D-LWMA. So I can make it rise faster to reduce the number of cheap blocks, reduce delays a little, and prevent oscillations. But the bulk of the delay can't be stopped. I can't envision any potential solution in this type of hash attack that is within the scope of normal difficulty algorithms. |
UltraNoteUltranote was the last coin of the initial coins interested in LWMA to change over. The reason they were slow to change over is because they already had a good algo: Sumokoin's SMA with N=35 instead of 17. Only the last plot is LWMA. It looks like it will have noticeably fewer oscillations and fewer delays. SMA with N=35 is faster than LWMA with N=60 by about 30%, but it has a good bit more variation which attracts hash attacks when it goes low, causing the oscillations. IntenseThis is 3175 blocks per plot instead of 7500 like many above. This is since a little after the 166166 fork. |
The charts below show the full difficulty history of 5 Monero clones that switched from the Cryptonote default difficulty algorithm (simple moving average with N=720) to LWMA difficulty algorithm.
Masari
The fourth plot below at the end is where they switch from Cryptonote default difficulty to Sumokoin's SMA N=17. They immediately had problems because they have a faster solvetime than Sumo and N=17 with Sumo was/is already close to breaking all the time (they haven't switched yet). So they rushed to get LWMA active and were the first to have it. They paved the way for a lot of coins to follow and uploaded a pull request to Monero.
Masari then began to have trouble from on-off mining, even after POW change as shown below.
Here is a close-up. The first plot is the old LWMA that had fewer "blocks stolen". It use average of difficulties instead of harmonic mean. The harmonic mean does not rise as fast in some circumstances and falls faster, so it could be the cause. But the other coins are not having this problem.
Karbowanec
These karbo plot are in a more zoomed-in view (fewer blocks per plot) to show SMA with N=17 a lot of oscillations (they started out with Cryptonote default difficulty but then switched to SMA N=17, and now LWMA N=60). The N=17 was really fast, but it caused way too many problems due to varying up and down too much, inviting miners to constantly engage in on-off mining which you can easily see as the oscillations. The new N with LWMA is chosen to be as fast as possible without inviting these on-off attacks with accideintally low difficulty. You can also see a recent timestamp attack due to not having the new timestamp protection (solvetime is 0.68 of the target for that plot which shows they got a lot of blocks much faster than normal (500 blocks in 35 minutes).
This is a repeat of the Karbo data since they began LWMA at 216000. At 3750 blocks per plot, this is on the same time scale of the T=120 coins I show with 7500 blocks per plot, about 10 days per plot.
IPBC
Iridium
Stellite
The text was updated successfully, but these errors were encountered: