Modify the PoW to prevent hash attacks

[imperdin]

The last couple of days demonstrated the risk being "exposed" to Nicehash where any attacker can gain access to absurd amount of hash power and 51% attack Graft at his own leisure.

Please consider adapting Cryptonight-heavy and slightly tweak them to hinder hash attacks and guard against network attackers.

[zawy12]

Zcash experiences 70% mining attacks for about 20 blocks about 3x times per day. It's pretty big and the Equihash POW seems to be good. Like Nicehash, the big miners may not be a single miner, so it's not necessarily a 51% attack despite having 70%. I'm not sure changing the POW will be beneficial. It might be more risky in have a unique POW than having 70% attacks all the time. Recent days showed a 70% attack did not hurt anything. It might be beneficial to switch POW, but I don't know what that would be unless it is to keep dedicated GPU miners for marketing reasons.

[zawy12]

Now I see someone has thrown a lot of hash power at the network since I looked at the data yesterday. The bad timestamps with the FTL=7200 loophole is the cause of the problems in the chart below. [edit: along with seemingly no one but the attacker being able to send blocks for some reason] It looks like someone with 90% of the network hash rate is doing it, but it's hard to know when so many timestamps are fake. It will not be like this after the next fork that will correct the loophole.

[imperdin]

The risk of exposure to 51% attack is tremendous, the potential of orphaned blocks and rolling back transactions at any hacker's leisure is daunting and should be avoided at all cost.

[zawy12]

My point is that > 95% of all coins already have >51% miner(s) jumping on many times per day. My point may not be a good one if the 3x increase in hashrate 95% of coins see every day is not a single miner or pool who could coordinate an attack. But it seems the bad actors are not interested in the really destructive activity. They just seem to limit their activity to hash attacks for low difficulty and timestamp manipulation. In recent timestamp attacks, they seemed to specifically limit the destruction so that the dev predictably decided it was better to accept the abuse and hard fork a fix rather going as far as a roll back. The bad actors may not want to worry about having to sell the ill-gotten gains quickly (before the roll back), or they can get more profit more easily and sustainably by hash attacks.

[imperdin]

Trusting your attackers to limit their destruction is preposterous at best.
You can tell that to Verge or Intense

[sebseb7]

"It will not be like this after the next fork that will correct the loophole."

the next fork may close one hole. But there will be a new puzzle for you also, you ready?

[sebseb7]

" > 95% of all coins already have >51% miner(s) jumping on many times per day"

bullshit

[trestylez]

"Please consider adapting Cryptonight-lightv1 or Cryptonight-heavy and slightly tweak them to hinder hash attacks and guard against network attackers."

Initially i thought this is a good idea but changing algo may only fix things in the short term. Once it becomes economically viable there still could be attacks if you haven't changed the underlying difficulty code to be resilient against these attacks. DERO seems to have solved their attack issues with code while still running cryptonight. We should wait and see how the latest graft release performs.

[imperdin]

@trestylez They major concern here is 51% attack Graft at his own leisure.
It doesn't matter how many times you tweak the DAA you could still be targeted by a 51% attack using Nicehash.

Ok so if not Nicehash there are other means....

The other means usually includes

• A) the largest bot-net of all time
• B) insane amount of Vega cards
• C) Bitmain

And all of these options are orders of magnitude more complex to achieve than to buy hash power at Nicehash

[trestylez]

"It doesn't matter how many times you tweak the DAA you could still be targeted by a 51% attack using Nicehash." If we assume these latest attacks are all economically driven then i believe DAA can reduce this type attack. As a simplified example; If the attacker can obtain 100 blocks in 10mins the cost will be low and reward high. If the DAA was non exploitable and reacted faster these 100 block should take 200min with cost being high and reward low. I do agree following the POW algorithm of a much larger coin make a 51% attack easier but assuming you are safe because you can't rent some Nicehash is a risky assumption. With ASIC's being killed off with POW changes expect a wave of adaptable FPGA's to lead the wave of next attacks where a algorithm change will be an extremely short term fix.

[imperdin]

@trestylez If we assume these latest attacks are all economically driven then i believe DAA can reduce this type attack. As a simplified example; If the attacker can obtain 100 blocks in 10mins the cost will be low and reward high

If we assume these latest attacks are all economically driven then i believe DAA can reduce this type attack. As a simplified example; If the attacker can obtain 100 blocks in 10mins the cost will be low and reward high. If the DAA was non exploitable and reacted faster these 100 block should take 200min with cost being high and reward low.

While I do believe that "perfect" DAA hinders economically driven attacks, there are still plenty of "motives" left to cover.

I never claimed that tweaking the PoW makes a coin automatically immune to 51% attacks, I only claimed that tweaking the PoW makes a coin orders of magnitude safer than allowing any attacker to 51% attack Graft at his own leisure

With ASIC's being killed off with POW changes expect a wave of adaptable FPGA's

With Cryptonight-heavy increased scratchpad FPGA's are less likely to be implemented specifically to target Cryptonight-heavy coins, however if they do mange to mine it efficiently than we could discuss further solutions

[sebseb7]

"If we assume these latest attacks are all economically driven then i believe DAA can reduce this type attack. "

Don't just assume you understand the economics behind it. There is many strategies, not all of them pay off initially. Some of them pay off in a way not obvious at all...

[sebseb7]

"While I do believe that "perfect" DAA hinders economically driven attacks,"

I do not believe that. I am deeply convinced that there is no compromize that would eliminate all attack vectors at once. There is just so many of them...

[sebseb7]

"With Cryptonight-heavy increased scratchpad FPGA's are less likely to be implemented specifically to target Cryptonight-heavy coins"

I advocate for total PoW diversity.

https://github.com/ipbc-dev/TuringsNightmare/blob/master/TN_Explanation.md

[zawy12]

Trusting your attackers to limit their destruction is preposterous at best. You can tell that to Verge or Intense

I did not say I trust them, but that the evidence is that so far small coins have had no choice, and that the attacks they actually do can be stopped LWMA. Even your links support my position: LWMA would have prevented those attacks.

[zawy12]

" > 95% of all coins already have >51% miner(s) jumping on many times per day"

bullshit

Assuming there are only 1000 coins, 95% would be the smaller 950 coins. Name a coin that is not in the top 50 and I'll check to see how many times in the past day their hashrate jumped more than 250% for at least 15 blocks.

[imperdin]

ETN

[sebseb7]

" I'll check to see how many times in the past day their hashrate jumped more than 250% for at least 15 blocks."

but that doesn't tell you how many miners are jumping

">51% miner(s) jumping on many times per day""

[sebseb7]

"their hashrate jumped more than 250% for at least 15 blocks"

only broken coins have this.

[zawy12]

but that doesn't tell you how many miners are jumping

Right. I previously mentioned I could not prove the miner(s) than come and go in unison for 15 blocks are of "one mind" that's capable of other types of 51% harm.

" I'll check to see how many times in the past day their hashrate jumped more than 250% for at least 15 blocks." only broken coins have this.

Well, name a coin like imperdin that's not in the top 50 that's not broken. The only three in the top 50 I've checked are broken by your definitiion: BCH, Zcash, and BTG

[zawy12]

I spoke badly of Graftnetwork's atan() adjustment to LWMA to reduce delays, but it looks like it might be functioning perfectly. I'll monitor it to see if it carries a risk of oscillations or lowers the avg solvetime (due to its asymmetrical nature). It looks like it might be lowering the average solvetime (it's at the low end, bordering on statistical significance), but if it's not much and reduces delays, it's a good thing. And if the graft guys can do something similar to make it rise faster, that would be a major improvement.

Where the difficulty smooths out at the end is where the new fork began. The magenta peaks are hash attacks (there have not been any bad timestamps since the fork). Notice before the new fork there are a lot of blue peak, after the magenta peak, about equal to them. These are delays. Notice there are no blue peaks in LWMA with the atan() adjustment at the end on the right side.

[zawy12]

On the other hand, in this expanded view since the fork, notice that the blocks stolen are 7.6%. This is pretty high for LWMA. I do not think I've ever seen it that high. In 9 months of masari and iridium, the highest was over a a few days was 5%. Only the worst series of 700 data points like this I found was 7% to 10% on Iridium, and iridum is T=175 which should not perform as well. Also, they did not change POW which is why their recent "blocks stolen" is not as good other LWMAs (4x more hashpower without a price increase = a consistently rising difficulty which scored higher "blocks stolen"). If it stays that high it will be because of the atan() adjustment. By dropping too low, it could be attracting hash power oscillations. It needs to be made symmetrical by rising by the exact inverse rule (and maybe the setting is a little too aggressive) but then it might not end up being any different than just lowering N which could still oscillate up and down too much.

[EDDragonWolf]

Based on your calculation, we got little different results: from the 68000 block (last network update And this result is more close to your expectation, @zawy12

[zawy12]

I don't understand, our charts look the same. You mean a different percentage? That would be from 2 things: one is that you have more blocks now. Did I send you my spreadsheet for this calculation? I had to modify it to use medians (but my modification did not make a difference in my tests) because your timestamp manipulations were throwing it off, the results were meaningless. For each block, I subtract the median of the next 9 blocks from the median of the past 11 blocks and divide by 11 to see if it is <0.5xT. There's also penalty of 11 blocks counted as "stolen" when at least 3 blocks meet the < 0.5xT criteria, since it's an average of 11. You can confirm by looking at solvetime this is about right. The main thing is that my comparison to other LWMA's is consistent. There's another problem: your osciallations with the atan() are so fast, this average of 11 blocks method is unable to see the problem.

You're going to have to fork. It's going to get worse than this, maybe a lot worse. 60% changes in 10 blocks all the time is pretty bad. Change MTP back to 60 and remove the atan.

[zawy12]

[zawy12]

Here's another LWMA on the same scale.

[edit: too many words thinking out loud and going no where definitive follow]

Now that I can see comparison better, the difference in your peaks and valleys do not seem worse. But their frequency makes me wonder if it's going to be a problem.

Your network hashrate seems to know what it wants to be. The average D is staying pretty even. The chart below looks worse due to longer trends of ups and downs due to real hash rate changes. I believe yours might have been worse if you were experiencing that kind of hash rate change.

I guess if the ups and downs don't get bigger and if attackers can't tweak their strategy, your DA might be good, even better due to the ATAN(). Rapid ups and downs are not a problem per se, unless some bigger miner is really getting extra blocks from it. It's not clear this is being caused by a big miner. I have not seen any bad timestamps. If this is just accidental oscillation from the atan() and normal miners, everyone is getting a fair deal as the difficulty averages out. A smooth difficulty in and of itself has no benefit, and it's a penalty if it does not keep up with hashrate or price changes. Fair oscillations, even this bad, are better than a smooth difficulty that can't keep up with price and hashrate.

Your blocks stolen metric could get worse as a miner improves his strategy, so the swings could get worse. On the other hand, in 3 cases of the 10 LWMA start ups I've seen, their charts looked worse than this (Oscillating, but not so rapidly). A big miner was doing what he's doing to yours now. But the difficulty was rising so fast, he stopped coming by after the first day. So there's a chance this will be as good as a normal LWMA, and even better due to atan(). But I think it will get a little worse due to the atan().

[zawy12]

The first 400 blocks had no delays > 7xT. That's normal and pretty good after a fork. But the next 300 blocks have seen 9 over 7xT. 7xT almost never occurs on accident. If an attacker develops a strategy, you could have 20 blocks per day with 10xT delays. There might be a 20xT delay everyday. This is ironically from trying to reduce delays. The average of 11 metric we're using is not going to register them as delays, because the blocks before and after it are fast.

[zawy12]

There are still zero blocks with timestamp manipulation. So all the oscillations might be just the algorithm itself, not an attacker. So the "delay" metric is not showing a problem when there is one, to an extent, and the "attack" metric is showing a big problem when there may not be any. It's a chart that looks frightening, but it might be OK.

[sebseb7]

"There are still zero blocks with timestamp manipulation. So all the oscillations might be just the algorithm itself, not an attacker."

This issues is about PoW. You might post timestamp related infomation in a differend issue.

[sebseb7]

Alloy next to change PoW, like so many. The less niche coins still mineable using nicehash, to more action they will see...

[zawy12]

Alloy didn't remove the 15 block CN lag when they employed LWMA, so they had problems

[sebseb7]

still they will change PoW, unrelated to that "problem".

[zawy12]

I'm not saying POW is not helpful to keeping dedicated your miners who advertise for you and are less likely to sell, or that it's not needed while the market for ASICs is a monopoly. Protection against non-hash-attack >50% problems would be good. It's just not necessary for protection against on-off mining even in small coins if the DA is good.

Concerning IPBC, they got back to me and said using variable declarations of the form double = size_t * int64_t caused an error like you said, although it did not need to be an overflow to be a catastrophic problem. The high bit for sign was interpreted as a very large number in the multiplication. size_t is unsigned. It's a mystery as to why between 2 or 3 other coins who have that particular code are not seeing an error when negatives go through the multiplication.

[zawy12]

Thanks for making me follow through on that. About 3 other coins were about to implement that version of the code and were not using out-of-sequence timestamps in their testnet, which is what causes negatives.

[sebseb7]

". It's just not necessary for protection against on-off mining"

but neccessary for protections agains malicious intent. Thats what you don't understand.

[zawy12]

imperdin said that since I agree POW has benefit, I should not argue so strongly for just LWMA as a cure all.

POW change helps keep your small miners which helps diversity which helps prevent >51% damage. They are a lot more likely to hold your coin, which helps price. Maybe any POW change will just delay Nicehash problems. But it's good to see how Sumo got a lot better by changing only POW. It looks like things got worse for them about 10 days before Monero changed POW.

If and when graft changes POW, they need to remove ATAN() and change MTP back from my recommended 11 to 60. But hopefully jagerman's fix for the recent attacks makes this last change a miner point.

[EDDragonWolf]

Since there is no any activity almost a year, I close this issue.