Skip to content
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

Open
zawy12 opened this Issue Mar 20, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@zawy12
Copy link
Owner

zawy12 commented Mar 20, 2018

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.
image

masari_new

image

Masari then began to have trouble from on-off mining, even after POW change as shown below.

image

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.

image

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).

karb_lwma

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.

image

IPBC

image

Iridium

monero-iridium

monero_iridium2_plus_lwma
image

Stellite

monero_stellite

image

image

image

@vitorgamer58

This comment has been minimized.

Copy link

vitorgamer58 commented Apr 23, 2018

Hey, how did you make these graphics?

@zawy12

This comment has been minimized.

Copy link
Owner Author

zawy12 commented Apr 29, 2018

Niobio Problem

Niobio was the first coin with a correct LWMA that had a hash attack problem. The 20x miner was not getting blocks at a lower difficulty than the constant miners, but when he left, their solvetimes were 2.5x higher than target, so they were losing. When he was present, D was low, but he was getting blocks too fast for the dedicated miners to get hardly any of them. There were frequently blocks with 1/2 hour delays when he left. But it appears he got tired of the activity and is no longer there. But Niobio still has problems, and it might be expected because in one instance, the attacker drove D 2.5x higher. The T=240 makes it harder to set D.

This is a close up view compared to the other charts.

image

Difficulty and solvetimes example from the problems at the beginning
:
image

Plura

Plura recently switched to LWMA and it seems to be helping a lot.
image

Haven

Haven started out with the initial Masari LWMA that had timestamp exploit. Someone finally found it and got a lot of blocks in a few hours, then Haven forked to get the newer version of LWMA.

image

image

@zawy12 zawy12 changed the title Monero/Cryptonote difficulty compared to LWMA in 5 coins. LWMA: 350,000 blocks of data on 9 coins Apr 29, 2018

@vitorgamer58

This comment has been minimized.

Copy link

vitorgamer58 commented Apr 29, 2018

Realmente, na Niobio cash todos os mineradores gostaram muito do resultado

@zawy12

This comment has been minimized.

Copy link
Owner Author

zawy12 commented May 2, 2018

Bitcoin Candy problem

This is by far the worst looking LWMA chart (out of those who did not make a mistake implementing it). It seems like they don't have dedicated mainers and some big miner always jumping on and off is causing problems.

image

@zawy12

This comment has been minimized.

Copy link
Owner Author

zawy12 commented May 5, 2018

Iridium Problem

Iridium 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.

image

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.

image

@zawy12 zawy12 referenced this issue May 6, 2018

Open

LWMA Failures #26

@zawy12

This comment has been minimized.

Copy link
Owner Author

zawy12 commented May 7, 2018

UltraNote

Ultranote 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.

image

Intense

This is 3175 blocks per plot instead of 7500 like many above. This is since a little after the 166166 fork.

image

@zawy12 zawy12 changed the title LWMA: 350,000 blocks of data on 9 coins LWMA: 500,000 blocks of data in 10 coins May 8, 2018

@zawy12

This comment has been minimized.

Copy link
Owner Author

zawy12 commented May 8, 2018

Wownero

image

BBScoin

BBScoin had the default FTL which is too far ahead in the future when they first switched to LWMA at block 60,000, but then fixed it at 72,500 as you can see in the chart.
image

Balkan

Balkan is unique in having T=30. Because of this, I advised them to use N=120 instead of 60. However, during the first few days, they had a big miner present who was willing to drive difficulty really high. It's settled down the last few days, but still a little higher than I would hope on the blocks stolen metric. It would have performed a lot better if they had used N=60. So now I'm more open to keeping all small coins in the range 45 to 60.

The first 3 plots are with default CN. The 4th plot you can see the switch to LWMA. soon after a big miner was causing their LWMA some big problems.

image

Graft

They made a substantial change to LWMA to make it drop quicker, so it's causing oscillations. You can read all about it in their issues.

This is on a timescale of 7500 blocks per plot same as the ones at the top of the page. This after the initial problems were solved. You can see it's changing more due to their "ATAN()" modification that makes it drop quicker. Notice solvetimes are below average despite the attacks. This because it's dropping too much.
image

A zoomed-in view:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
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.