• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

51% Attack costs on cryptocurrencies : looking for feedback on article

qwizzie

Well-known member
https://ambcrypto.com/high-risk-of-51-attack-for-bytecoin-bcn-and-bitcoin-private-btcp/

Are the costs to perform an 51% attack on Dash as stated in this article correct ? Or do masternodes
introduce additional costs that this article does not take into account ?

AmM6YvC.jpg
 
Yes I would like to hear more feedback about this also. If Dash succumbs to a 51% attack that would be a very big deal and will be a blow to Dash's future and market cap.

Does Dash's POS help in regards to this? If not Ethereum's Casper POS is supposed to make 51% attacks almost impossible. Maybe to be considered for Dash?

According to this site it only costs $15K to do a 1 hour attack on Dash using outsourced hashing power.
https://www.crypto51.app

And because of leveraging trading a hacker can make 100x their gains pretty quickly during an attack.

Also Dash scores low on the R-Index making it 51% attack vulnerable.
https://medium.com/@HusamABBOUD/rindex-the-robustness-index-87cdcf284faf

Attacking using leverage.
https://medium.com/@HusamABBOUD/the...um-classic-attack-with-1mm-today-8fa0430a7c25
 
Looks like Dash Force News did an article about this yesterday :

https://www.dashforcenews.com/overp...misallocating-bitcoin-and-dash-vs-51-attacks/

Dash operates on a proof-of-work model similar to Bitcoin, however the masternode network offers collateralized extra proof-of-service layer. Spork 3, InstantSend Block Filtering, causes masternodes to reject blocks that operate in conflict
with InstantSend transactions locked by the masternode network. This means that, when InstantSend is being actively used, Dash is effectively impossible to attack with mining alone. An attacker would have to both control 51% or more of
the mining hashrate, as well as 51% of the masternode network, in order to be able to attempt to reverse transactions. At present prices, for the masternode network alone this would necessitate buying around $1 billion worth of Dash,
which itself would trigger prices to skyrocket, significantly increasing the cost past that figure. Even more challenging, around 60% of Dash’s supply is already tied to masternodes, meaning that an attacker could buy every single other Dash
in circulation and still fall short, and would need to convince existing actors to sell in order to make up a majority.

If i read above statement correct, then Dash needs InstantSend to be actively used on its network in order to not be vulnerable to any 51% attack through mining alone.
Since InstantSend is optional for users, it does make me wonder how much InstandSend is currently actively used, compared to normal transactions.

A simple solution would of course be to make InstantSend mandatory instead of optional, that would close the security gap completely.
Question then remains if users would accept mandatory InstantSend transactions (with some small fees), knowing this would completely block any 51% attack on Dash network through mining...
 
Last edited:
@qwizzie
I thought somewhere on the roadmap the goal is to have instant send on by default.

It would be nice to have extra clarification on the instantsend part. Since instantsend can be disabled, if it is on at all we are protected. It means that not that every transaction needs to be a instantsend one. I think it works like this because of the masternodes provide a 2nd layer of protection if they are in full operation and all transactions benefit.


Overall I think the entire concept around renting hash power for this purpose is flawed especially for dash, because first off you can only double spend your money. We know dash is thinly traded so the attacker would have to buy a bit of dash before executing the attack. Then you have to find a exchange that will let you move millions in and millions out in a hour.

Also, If you rented 27% of the x11 hash power where are you going to get another 24%? It's also a bidding system so the price will go up if you try to buy it all. Also on nicehash how can you insure that you get every bit of hash power for 1 hour? As previous mining contracts expire it may take hours or days to acquire all of it via bidding.

It only worked on bitcoin gold because these hackers already had some bitcoin and a ton of hashing power for cheap. They probably exceeded 51%. The real question is how did the exchange let this pass.

A total side note, couldn't nicehash also monitor the node that they are sending hash power to? And basically watch for a chain split between that node and others on the network? They are able to act as a proxy between the miners and the person buying hash power.
 
Last edited:
There needs to be some things clarified on this, as this was being discussed yesterday in the Discord channel and @UdjinM6 helped shed light on it. As I understand it, InstantSend does not prevent a 51% mining attack, and someone would not need to control 51% of masternodes in order to execute a 51% attack on transactions including InstantSend txs. What InstantSend does is it makes it just as safe to accept a zero-confirmation transaction as it would be to accept a normal 6-confirmation or 20-confirmation transaction (but not infinite, because the locks do expire eventually at some point *after* the tx has been included in a block). With the understanding that 20-confirmation transactions are still susceptible to a sustained 51% attack just like they would be in any other PoW chain. If a 51% mining attacker were to mine on a forked chain and get more proof of work and get something like 100 blocks ahead, then the original chain would still be abandoned in favor of the new chain.
 
Last edited:
This is such a good topic. I don't understand the technical details fully but @UdjinM6 mentioned some changes in Evolution / POS that will help reduce the 51% attack.

And yes would agree that instant send should be on by default. Would love to see exchanges accept this and also allow you to withdrawal with instant send, maybe with a few normal confirmations to be safe also.
 
This is such a good topic. I don't understand the technical details fully but @UdjinM6 mentioned some changes in Evolution / POS that will help reduce the 51% attack.

And yes would agree that instant send should be on by default. Would love to see exchanges accept this and also allow you to withdrawal with instant send, maybe with a few normal confirmations to be safe also.

I think I would like to see chained IX locks (or some other solution that enables using IX without the inputs needing to have a bunch of confirmations), and also a change to the fee structure (a fixed IS fee doesn't make sense to me), before turning it on by default.
 
Back
Top