Hash Attack Examples about difficulty-algorithms HOT 13 OPEN

Iridium

This a great example of the danger of using an algorithm that is too slow. This is Iridium over a 10 day period using what I believe was the cryptonote default of N=720. They have target solvetime of T=175 so it's 500 blocks per day. So it takes it 1.5 days to reach the correct difficulty with N=720. The magenta before the peaks is a lot of hash power coming online and getting blocks too quickly (4x too quickly when the magenta reaches "1"). Similarly, the blue peak reaching 3 was when the average of 11 blocks too 4x3=12x the target solvetime. They've switched to my LWMA and are doing excellent. Basically zero delays and their avg solvetime should now be within 1 second of target.

from difficulty-algorithms.

Niobio

This is the worst example I've seen of a timestamp attack. Attacker got about 4250 blocks at extremely low difficulty in 3 hours. Normally 3 hours is supposed to be 45 blocks. The exploit was allowed because the algorithm used if solvetime <1 then solvetime =1.

This is also a good example of an N that was too small. Before the attack and for a little after it, N=36 for LWMA when it should have been N=60. The last 2/3 of the last plot is when N=60. You can see the oscillations and big difficulty spikes from miners jumping on and off to get the accidentally low difficulty when N=36, and how it was mostly resolved with N=60.

from difficulty-algorithms.

Qwerty

The following shows qwertycoin when they switched to LWMA. The attacker initially tried bad timestamps, which didn't help. He started a hash attack afterwards (first magenta spikes) and the difficulty quickly rose and stopped. It then looks like he thought about it for an hour or two and decided a slow increase in hashrate would work. And it did. He got blocks at 1/2 the average price in difficulty compared to if he had just jumped on with full power. The lack of magenta and blue indicates the difficulty kept up with his increase, and he caused no problem. Solvetimes stayed on tracHe paid a "fair price" for all the blocks he got. I'm posting this one as a really strange case because that he has some kind of mining setup where he can slowly increase hashrate. Did he just let that capital expense sit idle, was the rest of it mining other coins, or was he able to easily rent more and more mining this way?

Again, the magenta and blue lines are scaled down by 4. His peak mining power was 16x the average of this plot, so he might have been about 25x the baseline hash rate.

from difficulty-algorithms.

Karbowanec

This long-term trend of Karbowanec with Cryptonote default 24 hour simple moving average shows how small coins can seem OK for awhile with a slow difficulty, then kind of just blow up from miners coming on and off.

Here's karbo after it switched to SMA N=17. You can easily see miners constantly jumping on and off because N was too small.

Stellite

shows the same thing even better, and that the oscillations will reliably come back.

Sumokoin

Switching to an algorithm that's too fast like this N=17 SMA can also be bad as the following shows (I should expand the scale so you can really see the miners jumping on when it goes low and off when it goes high). But Sumokoin still uses this and are happy the delays never get bad like they used to. I guided them towards the N=17. I think they wanted an N=30 that would have been a lot better, but I talked them out of it. A little irony: they were the only coin to donate a very fair amount to me for my work (I never request donations..at least not as of now).

Bitcoin Gold

This is maybe the best example of all, and it's largely my fault. I chose a nice fast N=30 for BTG that would have worked OK (it was befoer I had LWMA), but there was leftover code in digishield that acted very differently that simply being the POW limit it was called. The limit was supposed to limit difficulty to 16% rises and 30% falls. But it actually would stop the difficulty from rising exactly when it needed to, limiting it to 0.5% to 1.5% for many blocks in a row. You can see this as almost horizontal lines. Since the limits were not symmetrically equal, it would fall faster when it finally went up and the miners leave. This results in too many blocks being mined.

from difficulty-algorithms.

UltraNote

is experiencing an attack from a 10x (or more) miner. He's not using bad timestamps, and the algorithm is like a simple moving average with N=35 which is a really good algorithm to stop attacks. I think their code must be using cryptonote's "cut" which is allowing the attacker to get 35 blocks before the difficulty rises....it's even dropping for most of his attack. He then leaves and the algo figures out it needs to be 10x higher. He gets 38 blocks in 6 minutes instead of over an hour. The resulting high difficulty makes dedicated miners want to leave....or to start coming back every hour with the attacker to get in on the low difficulty. Attacks are in the last two plots. Before then, the difficulty was always performing well.

from difficulty-algorithms.

Sumokoin

like all the coins who copied their N=17 DA was experiencing some huge attacks jumping on for only a few blocks. This was a straight attack with no timestamp manipulating. They jumped on for about 20 blocks when the diffiuclty was low, go 20 blocks, and then left. It appears sumo was using a lag, otherwise the N=17 pseudo-SMA difficulty algo would have responded faster and not look so bad. When it got better at the end was when they upgraded the POW.

IntenseCoin

and other coins used Sumo's algorithm, but several of them are seeing bad timestamps instead of just straight hash attacks. The biggest problem is that sumo uses a sort of the timestamps instead of letting good timestamps erase bad forwarded ones with an apparent negative solvetime. Sumo seems to still have the sort in their code, so they should soon experience the same problems, despite the recent fork. Here's what it looks like when the attacker sent +2400 timestamps followed by 2 honest timestamps, then another bad one... for 5000 blocks. Difficulty went to zero. He only sent 1 out of three because if he sent > 1/2 he might run into the future time limit that would pause his attack. 1/3 was enough because there was no limit stopping him fro sending +2400 which by default in cryptonote coinse is 7200. The difficulty goes to zero because it's N=17, so nextD=avgD * 120 / (2400/17) = avgD * 0.85 so dropped 15% per block until it was basically zero.

from difficulty-algorithms.

Graft

GraftNetwork wins the prize of "Cryptonote default difficulty algorithm looked good for the longest period of time but then blew up like all the rest." I predicted this blow up was potentially imminent 2 days before it happened, based on the previous blow ups of CN coins as seen on the LWMA examples page..

from difficulty-algorithms.

Graft

GraftNetwork implemented a good version of LWMA but did not reduce the FTL to 500. As a result, a 10x attacker has been able to use bad timestamps to periodically drive difficulty down. Graft will make the correction in a new fork. There are bigger problems that aer being investigated.

The attacks started out with large forwarded stamps that looked like this (beginning block 66720). Th is difficulty and apparent solvetimes based on timestamps.

Notice in the following that there were no honest timestamp for a long time ( the -1357 was the first one). It's not because the attacker had this much has power (to get all the blocks) but that he sent so many bad stamps, the "owned the MTP". The MTP is the median of the past 60 blocks (in CN, and 11 in BTC). If a timestamp is earlier than that it's rejected in cryptonote rather than set to the MTP and accepted due to an error in the code. All the honest timestamps were older than the MTP the attacker had "created" with forward stamps, and they were being rejected. This attack is discussed here. It's hard to tell what the real time is in this sequence. You have to run a node and record when blocks come in to get an idea of the bad timestamps in a case like this.

from difficulty-algorithms.

Bitcoin Candy

Bitcoin Candy had a very strange mining event. There might be something wrong with their network. A 30x attacker sent their difficulty up 3x. But then it took 8200 seconds for the next solve when he left. That means less than 5% of his "dedicated' miners remained when the attacker left. The LWMA saw the long solvetime and dropped to 1/5 the difficulty in the next block. Then it appears the attacker came back. It's like he had only 1 miner. This is probably what initially was happening to Niobio.

Here are the solvetimes and difficulty that led up to the peak the 8,200 second = 2.3 hr delay.

from difficulty-algorithms.

Masari

They had LWMA the longest, but they haven't been allowing negative solvetimes. That's not so bad, but they never dropped their FTL to 500. It was at 12xT = 24 minutes. Some > 50% miner finally realized they could get blocks at low difficulty by forwarding the stamps. This last plot shows a POW change did not solve the problem.

This is an excellent example of a miner sending forward times to lower difficulty. Notice his first one lowers it a lot, and since Masari was not allowing negative solvetimes, the honest timestamps that created an apparent negative solvetime (due to the previous lie) are not able to raise D back up as in the reference LWMA that allows negatives. Also notice that his 2nd > 1000 forwarded stamp was not able to lower the difficulty anymore. This is because he was "bumping into the FTL". He'll have to wait for the chain time (as his difficulty calculates it) to lag behind FTL as it is supposed to. The reference LWMA does not bump into the FTL because the negatives allow the damage to be undone....provided he's not > 50% then he can do more damage than can be undone, and he'll again bump into the FTL. If you understand all this you're a timestamp manipulation wizard.

from difficulty-algorithms.

In addition to the bitcoin Candy example above, there aer two other instances where LWMA did not perform well.

Iridium

Before IRD changed POW, it's previously perfect history of LWMA started showing some flaws. Here is a 1 day where things were not going well:

Here's 5 cycles at the beginning of this chart: (D and solvetimes)

Niobio also had a similar problem that I show on the LWMA examples in coins page.

from difficulty-algorithms.

Hi, Sugarchain got a 64x attack few days ago. Now its restoring. Could you check it? It may an interesting sample. We use Digishield N510.

Explorer
Iquidus: https://1explorer.sugarchain.org/
Addressindex: https://sugar.wtf/
Esplora: https://sugar.wtf/esplora

from difficulty-algorithms.

Send me the height, timestamp, & difficulty in a CSV file to [email protected]

from difficulty-algorithms.