Hash Attack Examples - Githubissues

zawy12 commented 6 years ago

These show typical hashrate jumps when difficulty accidentally falls about 20% low. The magenta spikes are when the avg of 11 solvetimes were > 2.1x faster than the target, indicating a large increase in hashrate that is not a statistical accident. They are scaled down to 1/4 the 1/(avg 11 solvetime) for plotting. A peak reaching 1 is 4x the baseline hashrate. The blue or orange spikes are when avg of 11 solvetimes are >2x target solvetimes, represented unusual delays, also scaled down by 1/4th.

Alloy

The first one is a Monero clone, Alloy, that suffered a 3-day delay between blocks as a result of the default Cryptonote difficulty algorithm being too slow with N=720 in a simple moving average. Below shows attack that had 4x4=16x their baseline hashrate, resulting in the average of 11 solvetimes going up to 17x4=68x longer than their target solvetime. The attackers got 250 blocks before the difficulty started rising.

Alloy switched to LWMA with N=60 and 25x attacks resulted in 2x4=8x delays. The attackers got only 30 blocks before the difficulty doubled. This occured right after the fork to the new algorithm, so the attackers were trying their old tricks, which won't work anymore. They have not come back.

[update: I later found out some of these swings in alloy were due to it having a lag in its calculations, so a normal LWMA would have reacted about 15 blocks faster. ]

Masari

The same thing occurred when Masari switched to LWMA: right after the fork, they tried to attack but didn't get many blocks, so they haven't returned in 6 months.

masari_lwma_begin

Here's a zoom-in view of the initial Masari attack.

Sumokoin

This is an example of Sumokoin's problems as a result of "fixing" their Cryptonote N=720 problem with my N=17 SMA. Their coin isn't "breaking" anymore (delays are tolerable), but otherwise it's not performing very well because it accidentally varies too much from the low N averaging window. So miners are constantly jumping on and off to get cheap coins.

Karbowanec

Karbowanec did the same thing as Sumokoin (switched from N=720 to N=17 SMA). This shows similar "constant" attacks with N=17. In both cases, it's not constantly like this. These are just good examples of when the attacks were strong.

Zcash

The following shows Zcash's version of Digishield doing good. By "good" I mean you can still see the attacks, but they don't last long due to the difficulty rising. It still attracts hash attacks every time it drops a little low from accidental variation. I'm including this one just to show even on good days with a large coin the big miners are still looking for opportunities to jump on. It's N=17 algo is like an SMA with N=4x17=68 because of they way Digishield "tempers" the N=17 SMA. It also has an unfortunate delay of 6 blocks in responding due to using the MTP as most recent bock timestamp, which is just a gift to the attackers at the expense of dedicated miners. (delays are not shown)

Hush

Hush is a clone of Zcash with the same algo. It's 100x smaller in hashrate than Zcash, so it sees more problems from big Zcash miners coming by for a "friendly visit".

Bitcoin Cash (new DAA)

Bitcoin cash had some problems for the first two or three days after forking to their new DAA which is an SMA with N=144. The slow N=144 let the price get out of sync with the difficulty. The (Price+Fees)/Difficulty ratio got larger which attracted more hash power. On the left half of this chart you can see that every time the red normalized price fell below the magenta normalized difficulty (the P/D ratio got lower), they would stop mining which can be seen as solvetimes going up. And vice versa when the price went above the difficulty line: solvetimes went down which shows increased hash rate. When difficulty goes up, solvetimes will be slower even if hashrate does not change, but that is a smallish effect. Notice these solvetimes go from 0.5x to 3x the target solvetime. This means hashrate went up 3x from the avg, and 6x from the low. This is an excellent chart because it shows hashrate went 3x up and down on this big coin by mere 25% changes in the P/D ratio. N=144 on a T=600 second coin (the averaging window is 1 day) like this is too slow at times for even a big coin. Small coins with Cryptonote's N=720 and T=120 solvetime is also a 1-day window and they can't usually survive. 1-day averaging allows price to change faster than difficulty.

bch3

zawy12 commented 6 years ago

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.

zawy12 commented 6 years ago

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.

niobio1

zawy12 commented 6 years ago

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.

qwerty

zawy12 commented 6 years ago

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.

zawy12 commented 6 years ago

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.

zawy12 commented 6 years ago

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.

zawy12 commented 6 years ago

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

zawy12 commented 6 years ago

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.

zawy12 commented 6 years ago

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.

zawy12 commented 6 years ago

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.