Not so long ago, Litecoin creator Charlie Lee has made a provocative statement.
This is a thought-provoking observation. 🤔
By definition, a decentralized cryptocurrency must be susceptible to 51% attacks whether by hashrate, stake, and/or other permissionlessly-acquirable resources.
If a crypto can't be 51% attacked, it is permissioned and centralized. https://t.co/LRCVj5F0O1
— Charlie Lee [LTC⚡] (@SatoshiLite) January 8, 2019
Is Charlie right? Is it true that cryptocurrencies are doomed to fail and are created to be destroyed? Are there any ways of protection? Let’s get into it.
Contents
Dominant Coin of the Algorithm
The dominant coin is a coin with the highest hashrate within the same mining algorithm.
So what about Charlie? Whether he is right or wrong is up to you to decide, but he is definitely very canny. Here are two examples from his life that prove it.
- While creating Litecoin, Charlie Lee intentionally chose not to use Bitcoin algorithm SHA-256 and created his own Scrypt algorithm.
- He sold all the cryptocurrency he owned in the period of peak price in December 2017. What a great intuition!
Charlie had a good reason not to use the Bitcoin algorithm for Litecoin. He was perfectly aware of the fact that it would be extremely difficult to compete with Bitcoin. He also understood the importance of being the dominant coin of the algorithm. We’ll try to give you some insight into the matter.
Let’s say, there is Xcoin with network hashrate of 100 TH/s and Ycoin with 1TH/s – both on the same algorithm. Let’s assume that one out of ten miners on this algorithm uses Nicehash for mining, so the power available for purchase is around 10 TH/s. If we rent all 10 TH/s and try manipulating Xcoin, we will fail. But in case of Ycoin, we could do some damage, because the hashrate would be 10 times higher than the overall network hashrate.
Whether the power is yours or rented is not important – it’s very difficult to find hardware that will let you take control of 51% of hashrate of the dominant coin. Look at Bitcoin – the king of cryptocurrencies. Today’s network hashrate is 41,572 PH/s. Let’s imagine that the only existing miner in the Bitcoin network is Antminer S9 with hashrate of 14 TH/s. We would have to find around 3 million such devices with power of 1.4 kW each. In order to make it all work, we would need an entire power station of a big million city. And its location raises some issues too.
Also, in May 2018 Charlie Lee tweeted about the attack on Bitcoin Gold.
Bitcoin Gold got 51% attacked. Miners have no issue with attacking BTG because if it dies, they could easily switch to mine another coin that also uses Equihash POW. This is not the case for Bitcoin/Litecoin where they are the dominant coin for their respective mining algorithms. https://t.co/ThOzSFz5tQ
— Charlie Lee [LTC⚡] (@SatoshiLite) May 24, 2018
Which Cryptocurrencies Can Be Attacked?
Check out the Crypto51 project. It is clear that the attack on Bitcoin, Litecoin or Ethereum is expensive and dangerous. One hour of attack on these cryptocurrencies costs $275 thousand, $33 thousand and $73 thousand respectively.
As a rule, non-dominant coins on Ethash (Dagger Hashimoto) algorithm are the ones that fall under attacks. And this can be easily explained.
- There is a very large number of Ethash coins, so the choice is vast.
- Nicehash and Miningrigrentals have a lot of available power to rent for this algorithm.
- Relatively low hashrate of some coins means low cost of an attack.
Let’s assume that our cryptocurrency uses Ethash or Equihash – after all, not everyone can create their own algorithm, like Zcoin. So what to do now? Shut it down? No, wait – the developers of several cryptocurrencies created solutions that can help. First of all, it’s Horizen protection system, Komodo dPoW and PirlGuard. Let’s get to know them better.
Horizen Protection System
In 2018 Horizen (formerly Zencash) developers came up with their own way of protection against 51% attack. Zencash (ZEN) uses Equihash mining algorithm, just like its bigger brother Zcash (ZEC). ZEC has always been the dominant coin for the algorithm, while ZEN and ZCL (Zclassic) were the ones affected by the attacks.
Exchanges have always suffered the most from 51% attacks, as funds are withdrawn at their expense. So they came up with an idea to increase the number of blocks required for verification for all deposits to 200 or even 500. Still today it takes quite a lot of time for ZCL to be charged to account – it may take up to several days. Coinbase require 5676 blocks(about 24 hours) for confirmation of all ETC deposits.
ZEN developers approached the problem differently and came up with the new PoW approach called the delayed block submission penalty approach.
Remember how 51% attack works? Look at the image below.
It is a blockchain example where NB stands for Normal Block and MB is Malicious Block. Starting from block NB100, the attacker disconnected his node from the rest of the cryptocurrency network N and started mining his own branch M alone. When the rest of the world reached NB116, the attacker had already mined MB119, that is, he mined 3 blocks more than others. Without protection system, once the attacker reconnects to other nodes, he could make the work of the rest of the world invalid and cancel blocks NB100–NB116, replacing them with MB100–MB119.
The Horizen team came up with the protection mechanism that “penalizes” the attacker’s branch with the blockchain hidden from the rest of the network. As a punishment, the attacker is forced to mine some amount of blocks in his branch.
In the example above, after block MB122 the attacker has to mine another 133 blocks in his branch. The formula is simple. The current block in the network is NB116, the first block of the attacker is MB100.
116–100 = 16 penalty points. The second block of the attacker is MB101. 116–101 = 15 penalty points. And so on. After block 116 the attacker gets minus 1 point for each block. As a result, we get 16+15+14+13+...+1+0-1-1-1 = 133 blocks.
Still, don’t get it? Let’s try again.
Let’s say, we disconnected from the network and started mining our own branch. After we reconnect, we want to add 20 new blocks, but in response, the network says the following.
You are a nice guy, but go mine another 231 blocks in your own branch, and then we can talk.
Block find time in the ZEN network is 2.5 minutes, so the attack must last no less than 10 hours. Profitability of such attacks is obviously not very high. And most importantly, exchanges can monitor them and block malicious deposits.
Komodo Delayed Proof of Work (dPoW)
Komodo (KMD) developers suggested a universal solution that fits all cryptocurrencies with low hashrate on both PoW and PoS algorithms. The main idea is to regularly register the state of the coin’s blockchain in the Bitcoin blockchain. It is extremely difficult to attack the BTC blockchain, so KMD developers used this to their advantage.
Here is what’s needed to make Komodo dPoW system work:
- the network of 64 notary nodes;
- a separate Bitcoin node for every notary node;
- BTC reserve for transactions in the Bitcoin blockchain.
Komodo notary nodes are similar to masternodes in the way they work. The only difference is that in order to launch a masternode, a certain sum of your funds must be frozen – 1,000 DASH, 1,000 Zcoin, 500,000 $PAC (the sum is established by the developers of a cryptocurrency). On the contrary, it is not a requirement in Komodo notary nodes. Komodo notary nodes owners are chosen by the KMD community. Komodo notary nodes get around 75% of the block rewards in the KMD network.
Average block time in the Komodo network – 1 minute. Average block time in the Bitcoin network – 10 minutes.
Every ten minutes notary nodes register (validate) information about the state of the Komodo blockchain in the Bitcoin blockchain. Ideally, one needs to send a notary transaction to the Bitcoin network a few seconds before a new block is found. But the exact time when a block is found can’t be predicted. So if in the course of 20–30 min there are no blocks in the Bitcoin network, there is no way to validate the current state of the Komodo blockchain.
How Komodo dPoW Fights Against 51% Attack
Let’s take an ideal world as an example, where every 10 minutes we register the state of the Komodo blockchain in the Bitcoin blockchain. During this period of time, 10 new blocks are found in the Komodo network.
Once the Komodo block state is registered in the Bitcoin blockchain, it can’t be changed anymore. This is the main idea of dPOW protection mechanism. After registration mining can only start from this point. Validation, in this case, works the same way as a safety net in “Who Wants to Be a Millionaire?”.
Let’s say, you want to attack the Komodo network. You disconnect your node on block 100, mine 15 blocks until block 115, then you reconnect your node and wait for the blockchain reorganization gladly rubbing your hands. But then it turns out that on block 110 Komodo notary nodes registered the state of the blockchain in the Bitcoin blockchain. They created a “safety net”, so now your 15 blocks can’t be authorized.
And what if blocks in Bitcoin are found every hour instead of every 10 minutes due to some delay? Will the attacker win then? In this case an exchange comes into play and sets the required number of verifications for incoming deposits. For example, if the requirement for deposits verification is 50 blocks (= 50 minutes), there is no point in 51% attack on KMD. Keep in mind that exchange and subsequent withdrawal of illegal funds also take time.
Komodo created a truly safe, but rather difficult protection mechanism. You can find the detailed description of KMD dPoW on github and in the Komodo blog.
PirlGuard Protection System
Pirl has been 51% attacked many times. It was depressing, but in the end developers created their own PirlGuard protection system.
The only article that describes the operation of PirlGuard was published by the Pirl team on Medium. The title says that it is an innovative solution against 51% attacks. Let’s take a look at the description of the PirlGuard operating mechanism.
The method seems to be the same as that of ZEN, right? If the attacker disconnects his node from the network, mines blocks and then reconnects, he gets penalized by the network and is forced to mine X amount of blocks in his own branch. Sadly, the article says nothing about how parameter X is calculated. We’ve studied the PirlGuard code and it turned out that PirlGuard operates very differently from what they say in the official description.
if penalty > 0 {
context := []interface{}{
"penalty", penalty,
}
log.Error("Chain is a malicious and we should reject it", context... )
err = ErrDelayTooHigh
}
Here is how PirlGuard actually works: the developers set a certain parameter – the number of blocks. Let’s say, it’s 20. If the attacker reconnects his node to the network and adds his 15 blocks to it (15 is less than the established number, which is 20), the network will accept them and reorganize. If he adds 25 blocks, the branch will be rejected. That’s it. There is no sophisticated penalty system or parameter X.
We thought that maybe it’s just a misunderstanding, so we decided to ask one of the Pirl developers for help. After a two-day discussion in Discord, we got nowhere. He claims that PirlGuard works just like the ZEN protection system, and we are simply missing something.
Since we already found ourselves auditing the PirlGuard code, we decided to finish the job by creating issue in their git-repository. We pointed out the discrepancy between the description and the code itself. Cryptocurrencies that implemented PirlGuard can still be affected by 51% attacks, if the amount of blocks added to the network by the attacker is smaller than the established parameter that we mentioned earlier. Of course, you can always change settings of the required number of verifications on an exchange. For example, if you change the protection algorithm threshold to 50 blocks and the number of verifications on the exchange to more than 50 blocks, your cryptocurrency is unlikely to be successfully attacked.
Global Cryptocurrency Security Concern
We all use cryptocurrency products, but we don’t know enough about the bugs they have. And they surely exist. There is no crypto police, so if something goes wrong, nobody is going to refund your savings.
Just remember how Parity Multisig Wallets were destroyed with Ether worth 150 million dollars.
And what about Ethereum developers delaying forks the day before the release because they found a security flaw? It’s good they even noticed it.
Decentralization is a huge advantage of cryptocurrencies, but also a huge disadvantage at the same time. Not all coin’s users have enough knowledge and time to analyze the code of the products they use. So they just have to take it on trust. It is what it is.
