In this article of Smilo Explained we are going to explain more about the infamous 51% attacks of the blockchain space. We decided to create a separate article on this matter since it is one of the most impactful attacks in the blockchain space and very topical over the last few weeks with several attacks happening.
Some blockchain projects are more prone to 51% attacks than others, this is especially true for blockchains using the popular Proof of Work (PoW) consensus mechanism. This PoW algorithm is an economic measure to deter various attacks on the network by requiring some work from the service requester, usually in the form of processing time by a computer. However, it is possible to attack PoW blockchains when you control more than 51% of the total hashing power.
Considering this, smaller blockchains with a relatively low total hashing power combined with the PoW consensus mechanism could easily fall victim to this attack. Take Bitcoin as an example, in the first few years when Bitcoin (and blockchain) was less popular, it was relatively easy to buy more than 51% of the total hashing power and attack the network. However, due to the fact that no individual really paid attention to this flaw, Bitcoin was able to slowly grow a considerable amount of relatively decentralised hashing power over time, thus securing the network.
Nowadays, this flaw is quite well-known and due to this there is a rising amount of attackers who try to better themselves by attacking other blockchains. There are even websites giving rough estimates of the costs involved in creating a 51% attack such as https://www.crypto51.app/.
Let’s take a closer look at some of the projects which have suffered from a 51% attack lately.
The first specific case of a 51% attack which we are going to discuss is the one that took place this week, the 2nd of december, on the cryptocurrency called Vertcoin. During the attack, the attackers tried to double spend the currency to better themselves.
“Vertcoin (VTC) experienced 22 deep chain reorganizations, 15 of which included double spends of VTC. We estimate that these attacks could have resulted in theft of over $100,000. The largest reorganization was over 300 blocks deep.”
According to the Crypto 51 webapp, the attack would only cost about 125 dollar per hour at the time of the attack. With an average block time of 2m and 40s this means the attack took approximately 14 hours and would only cost about 1750 dollars.
A few weeks ago, AurumCoin also fell victim to a 51% attack. During the attack, one of the few cryptocurrency exchanges who had listed AurumCoin, Cryptopia, was used to trade the stolen AurumCoin. AurumCoin claims not to be responsible for the attack and they shifted the blame to Cryptopia, insisting they were hacked. Cryptopia, on the other hand, has not yet responded to the accusation.
With a market cap of around 10 million USD, AurumCoin was definitely one of the easier targets. The attacker sent over AurumCoin to Cryptopia to exchange them for another cryptocurrency. Once this transaction went through, the attacker allegedly used more than 51% of the hashing power to reverse the transaction as though it never really happened.
Besides, the last commit on AurumCoin’s Github originates from 2015, which indicates that the developers might have abandoned their project. Moreover, having an average hashrate of just about 80PH/s didn’t help them either. For about 800 USD per hour, one can easily rent more than enough mining power on NiceHash to attack AurumCoin’s network.
According to various reports, it seems like AurumCoin needed twenty confirmations at the time of the attack to send or receive any funds. So, could Cryptopia be responsible for this hack? Well, Cryptopia stated that they do not have any control over the time in which these confirmations are completed. Meaning that, Cryptopia does not seem to have any influence on AurumCoin transactions.
According to the exchange, they are unable to reverse or alter these kind of confirmations, and thus the transactions. In their support section they make the following statement;
“Cryptopia does not perform these ‘Confirmations’ or have any control over the time in which these Confirmations are completed. The Confirmations are completed by miners on the Blockchain. Transactions with higher fees will are far more likely to be added to a block first.”
AurumCoin’s case is just one of the examples which shows the negative consequences for both the coin and the exchange hosting them.
Bitcoin Gold suffered from a similar attack, though on a larger scale. An amount of 12.239 BTG was deposited to an account on the crypto exchange Bittrex, which was according to the online publication Bitcoinist around 18 million USD at the time of the attack.
To go more in depth on how the attacker proceeded with his attack, the following information was posted by BitcoinGold as a statement on their website.
“The attackers address is known by this transaction: ee798dd31beda909c9ca7f843bc58b48dfb40b0f6db83ccd10e892e9c3154ce7 (Originally marked as Confirmed, now marked as Unconfirmed)
The deposit was made as part of this block #529022 (Originally marked as mainchain, now marked as Orphaned. It was mined by honest miners.) and was confirmed over the course of nearly six hours on mainchain with 21 additional blocks mined, up to and including this block #529043. (Originally marked as mainchain, now marked as Orphaned. It was mined by honest miners.)
Some time after the 20th block, which satisfied the 20-confirmation requirement for Bittrex, the attacker was able to trade their BTG on Bittrex and withdraw other crypto.
The attacker then released 23 (or more) secretly mined blocks to the mainchain, superseding the existing 22 blocks, and replacing their previous transfer of 12.239 BTG to Bittrex with a transfer of those same 12.239 BTG to themselves.
Below is the new transaction (double-spend) of the original 12239 BTG, sent to their own address instead of Bittrex: 8b8ad1deb88c9b9e36c62e96ff52833d4ca1632076b1092a5848de788181aaaf
It was included in this block #529022, which was first mined by the attackers in secret and not broadcast to the network until nearly 6 hours later. When it was finally broadcast along with 22 or more other secretly-mined blocks, for a total of over 23 blocks, it established the “longest chain” and took over as mainchain, causing the previously seen blocks to become “Orphaned.”
Bittrex delisted Bitcoin Gold shortly afterwards. As a result Bitcoin Gold was forced to upgrade their proof of work to make it, according to them, a less attractive and harder to attack network, even though the possibility to become victim of such an attack still lingers. Besides, they advised all exchanges to raise their confirmation requirements to give time to react on unusually large deposits of BTG — the double-spend attacks were clear outliers in size.
Expenses for the attack
“Bitcoin Gold, a much smaller network (1/20 the size of Bitcoin Cash network), since the fork, has switched to become ASIC resistant hashing with Equihash algorithm, — same as zCash — It is currently more secure against 51% attack from Bitcoin miners, but vulnerable to attacks from Zcash and other Equihash miners.”
As researched by Investopedia, if for example a zCash miner with +8% of Nethash would switch to mine BitcoinGold, he is already at +51% BTG nethash. This would brings the cost of 51% attack on BTG to 580 ZEC/day which equals around 200.000 USD
A common attack
Similar situations occurred this year with Monacoin and Verge among others, showing that these attacks are not uncommon. Counter measures are being taken by exchanges and networks alike such as increasing the number of confirmations required for making a transaction and ASIC resistant networks. Nevertheless, exchanges have very few defences to this attack, as no number of confirmations can make receiving deposits of the network under attack fully safe, when the attacker has over 51% of the hashing power. Some of the measures might reduce the risk of such an attack, though seem not as efficient as hoped, as even networks that have implemented them, are still being attacked.
‘As long as exchanges are willing to provide customers with assets in response to the deposit of a reversible currency, there’s no reason for attackers to stop this behavior. Expect to see more of these attacks.
Exchanges that support these assets will continue to suffer losses, with the ultimate result that exchanges will be forced to delist these assets. In such an environment, it’s hard to find a compelling argument for why these assets should have value.’
The Smilo network solves this problem with its Smilo BFT+ consensus mechanism. This consensus mechanism circumvents 51% attacks by having one valid blockchain and one valid block created by one chosen speaker. Next to 51% attacks, Smilo’s consensus is also far less vulnerable to a number of other attacks, making it a saver option for both users and exchanges.
Smilo will always require more than 66% consensus with the Smilo BFT+ algorithm, a node will never add a block to his chain when this block has been declined. Moreover, even when more than 66% of the nodes approve a block, but Node A declined the block, Node A will not add the block to his chain, nor will the follow up blocks add this block to the chain.
All Smilo Clients (like the API, full wallets, etcetera) are able to verify both blocks and transactions, providing a two-factor authentication for light clients. Clients can validate if it is connected to “Good actors” or “Bad actors”, depending on the blockchain hash, and therefore decide to send a transaction to a Good or Bad actor.
Since Smilo BFT+ Blacklists ‘Bad actors’, each Bad Actor will become an orphan/bad chain (fork). Besides, considering the fact you need 10.000 Smilo to act as a node, an attacking entity needs to own an immense amount of Smilo to start with, which makes it impractical as it will prove a great financial loss for the attacker. This makes Smilo 99.9% secure against sibling attacks.
250 nodes are securing the network:
- 84 nodes are ok!
- 166 nodes are bad!
166 * 10.000 = 1.66 million Smilo (>66% of the actors)
Even if the attacker pulls it off to create a bad block, the 84 good nodes will not add this block (because it is invalid). The next speaker in line (or the third, or the fourth, or the fifth) will create a correct block which will be added to the nodes. Since our full-clients validate nodes and blocks by themselves, they will not send any transactions to the wrong fork. This results in a fork which will only survive for as long as the bad actors are turned on.
Be part of the Smilo hybrid blockchain movement!
Our resource partners,