Author

Topic: How many nodes required to make 51% attack unfeasible? (Read 202 times)

jr. member
Activity: 39
Merit: 10
Newb trying to act cool
Thank you for the replies, everyone. I have a general direction now for doing my own reading  Cheesy
legendary
Activity: 3024
Merit: 2148
With cloud mining marketplace nowadays, it is easy to make 51% attack successfully on new altcoins. My question is whether there is a guideline, or rule of thumb, that new blockchain developers follow to reduce the risk of such attacks?

You need to first understand what exactly is a 51% attack. It's not something like "get 51% of hashpower and instantly destroy a coin". Majority of hashpower allows attacker to guarantee that only the valid blocks that they mine are included in blockchain. So, to do something like double-spending or denial of service (empty blocks) or blacklisting, they still have to mine blocks. So, in order for attacks being unprofitable, the network has to have high hashpower, to make attacks really expensive. It doesn't have much to do with the amount of network nodes. And to get that hashpower, the price of a coin must be sufficiently high, otherwise it can be profitable to make double-spends, like it happened with some altcoins.

However, nodes also play some role in this balance. Nodes allow users to express their stance on network rules, change them and cooperate with other like-minded users. So, if miners attack the network, users can punish them by changing network rules, like the PoW algorithm. But so far it has never happened with any coin, I think.
legendary
Activity: 1624
Merit: 2481
Does this mean that even if an attacker wants to attack and has the money to do so, the attacker is unable to because he will never get his hands on a bigger percentage of the stake in the network compared to the developers? If that is the case, is there a reason for not making it the "best practice" for new coins?


If the developer (who hold >50% of the stake) do not sell their stake to the attacker, he won't be able to perform a 51% attack.
The 'reason' for it not to be the 'best practice' is 1) that there is no 'best practice'. Each coin is (at least should be) different and also serves a different purpose.
And 2) most people won't buy a new coin where some entity holds 50% of the stake. Even one single entity holding 10% can be a disaster in terms of price stability / decentralization / trust.



I still want to ask further though, do developers rely anything else other than algorithm? Have anyone seen maybe a solution from the cryptonomics, perhaps?
Also, how deadly is a 51% attack to a new coin? Would it be more grievous?

Regarding cryptonomics, if it is worth to attack a new coin with a 51% attack (liquidity has to be high, has to be listed on multiple exchanges, profitable enough), you won't be able to really avoid it.

The only thing which truly avoids such a situation is the correct decision regarding the consensus algorithm. If it is not worth to attack the coin, it won't be attacked.
If destroying a new shitcoin which isn't worth anything is part of a hidden agend.. well.. then you can't really prevent that. The only thing you can do is to make an attack as unprofitable as possible.

The only way to really prevent that is some technical barrier (e.g. someone holds 51% stake and always will be honest; theoretically safe, but practically not doable since there is no reason to have that much trust in someone).
newbie
Activity: 4
Merit: 1
Does this mean that even if an attacker wants to attack and has the money to do so, the attacker is unable to because he will never get his hands on a bigger percentage of the stake in the network compared to the developers? If that is the case, is there a reason for not making it the "best practice" for new coins?

Yes, that is exactly what it means. I can't speak for every PoS coin out there but I'd guess it is a de facto best practice for early stage development. Gaining 51% stake in the network is a very costly attack vector for any coin in the top 400 because it would cost millions of dollars. A more pressing issue is when the underlying assumptions made by the developers about incentive structures don't reflect reality. For example, when centralized exchanges hold a massive amount of stake belonging to depositors, the exchange doesn't need to spend 51% of the market cap of the coin to launch an attack. Hopefully this becomes less of an issue if decentralized exchanges take off.

Can you explain more briefly what sporks are, and this is connected to "checkpoints may be hard coded into the wallet binary itself"? I'll read up into it on the side too, but it often helps to get some idea of what it is beforehand.

Sporks are separate from checkpoints; sorry if that wasn't clear. There exists a master public/private key pair that's used to manage the spork system. The master private key is used by the developers to sign spork messages before broadcasting them to the network. The master public key is held by every wallet and used to verify a spork message that's received from connected peers. The spork message might tell the receiving node to deactivate a certain feature or put a restriction on a consensus rule. It's really up to the developers how extensive they want to make it.

Checkpoints are block hashes that validate a version of the blockchain. They're mainly used to protect against long range attacks, an unstable chain that's prone to forking for whatever reason, and an honest node connecting to a malicious node then downloading the wrong chain on start up. You can look into those issues individually but elaborating further would be beyond the scope of this comment.

Hard coded checkpoints are block hashes that are added directly to the wallet code by developers. Check pointing servers are used when the block hashes need to be distributed to the network at much shorter intervals. So instead of needing to update the wallet to get new checkpoints the wallet simply receives the check points over the network. Of course this is centralized, but it's a necessary evil for a lot of coins.

Thanks for your answers. I still want to ask further though, do developers rely anything else other than algorithm? Have anyone seen maybe a solution from the cryptonomics, perhaps?

Also, how deadly is a 51% attack to a new coin? Would it be more grievous?

I don't feel qualified to answer your question about crypto economics, so hopefully someone else can provide more information on that.

A 51% attack can range from devastating to slightly inconvenient depending on how public the attack is, the market cap of the coin, and how new the coin is. If the coin is completely new and there aren't a lot of investors then the devs can always nuke the chain and start from a new genesis block or fork the chain at a point before the attack. It depends a lot on context.
jr. member
Activity: 39
Merit: 10
Newb trying to act cool
In proof of stake coins the developers normally hold a majority (or close to majority) stake in the network for a while before they can take the training wheels off. Both PoS and PoW coins utilize centralizing check pointing to varying degrees.

Does this mean that even if an attacker wants to attack and has the money to do so, the attacker is unable to because he will never get his hands on a bigger percentage of the stake in the network compared to the developers? If that is the case, is there a reason for not making it the "best practice" for new coins?

These checkpoints may be hard coded into the wallet binary itself or distributed from a centralized check pointing server at regular intervals. Some coins, like dash, pivx, and their various forks, use sporks to control certain consensus and network parameters. The sporks are essentially messages broadcast to nodes on the network that are signed by a master key held by the developers.

Can you explain more briefly what sporks are, and this is connected to "checkpoints may be hard coded into the wallet binary itself"? I'll read up into it on the side too, but it often helps to get some idea of what it is beforehand.


You would basically require an possible attacker to build his/her own ASICS for your algorithm, which still can be done.. but this makes an attack way more costy.

Owners of these GPUs can (and often do) switch from coin to coin to increase their returns without investing much into newer and more specialized hardware. That's not to say that changing the hashing algorithm used in the PoW computation for your coin isn't a very simple and effective rule of thumb.

Thanks for your answers. I still want to ask further though, do developers rely anything else other than algorithm? Have anyone seen maybe a solution from the cryptonomics, perhaps?

Also, how deadly is a 51% attack to a new coin? Would it be more grievous?
newbie
Activity: 4
Merit: 1
You would basically require an possible attacker to build his/her own ASICS for your algorithm, which still can be done.. but this makes an attack way more costy.

Although I do agree with basically everything you said, I think you might be overstating how much protection this approach will provide. ASICs are essentially only used in very high market cap coins because the economic incentives for developing specialized hardware are there. Much of the mining on non top 50 coins is done with general purpose GPUs that are very flexible in terms of what hashing algorithms they can execute efficiently.

Owners of these GPUs can (and often do) switch from coin to coin to increase their returns without investing much into newer and more specialized hardware. That's not to say that changing the hashing algorithm used in the PoW computation for your coin isn't a very simple and effective rule of thumb.
legendary
Activity: 1624
Merit: 2481
My question is whether there is a guideline, or rule of thumb, that new blockchain developers follow to reduce the risk of such attacks?

It is simple. Don't use an algorithm which is already used in X other coins.
The reason for each BTC fork to be heavily vulnerable to a 51% attack is, that just a small portion of miner from the BTC chain had to change the coin they are mining, to gain 51%+ of this coin.

So, instead of forking and using sha256 as an algorithm (like in BTC + 30 forks) and making your whole network vulnerable to an attack by even one relatively small BTC miner, you should create your own mining algorithm.
Choosing the mining algorithm is an important decision. This shouldn't be done without proper consideration.

You probably won't be able to create an ASIC proof algorithm, or an algorithm which for 100% won't be traded on such a marketplace, but you can do your best to protect yourself from malicious miner looking for a weaker coin with the same algo to make money with. You would basically require an possible attacker to build his/her own ASICS for your algorithm, which still can be done.. but this makes an attack way more costy.
newbie
Activity: 4
Merit: 1
It's unrealistic to expect a new coin to not have strong centralization early in its development. There are a number of safeguards utilized to make the necessary centralization possible. In proof of stake coins the developers normally hold a majority (or close to majority) stake in the network for a while before they can take the training wheels off. Both PoS and PoW coins utilize centralizing check pointing to varying degrees. These checkpoints may be hard coded into the wallet binary itself or distributed from a centralized check pointing server at regular intervals. Some coins, like dash, pivx, and their various forks, use sporks to control certain consensus and network parameters. The sporks are essentially messages broadcast to nodes on the network that are signed by a master key held by the developers.

Of course, none of these approaches are perfect as demonstrated by the many attacks against coins in the past, but they do help mitigate the risk and increase the cost of such attacks.
jr. member
Activity: 39
Merit: 10
Newb trying to act cool
With cloud mining marketplace nowadays, it is easy to make 51% attack successfully on new altcoins. My question is whether there is a guideline, or rule of thumb, that new blockchain developers follow to reduce the risk of such attacks?
Jump to: