Blockchain Semantics Insights
Business Case | Deep Tech | Announcements | Blockchain Glossary |
What is 51% Attack?By Swati Keswani | April 6, 2018, 7:42 a.m. GMT
One of the key flaws in Blockchain that comes to mind is what is called the 51% attack. If a Blockchain is not well distributed across multiple independent nodes and miners, then the 51% attack can become a reality.
So, what is this 51% attack?
- 51% attack refers to an attack on a Blockchain by a group of miners controlling more than 50% of the network's computing power. The attackers would then be able to prevent new transactions from gaining confirmations, allowing them to halt payments to some or all users. They would also be able to reverse transactions that were completed while they were in control of the network, meaning they could double-spend coins. It is the basic cryptographic hurdle the Blockchain was built to overcome, so a network that allowed for double-spending would quickly suffer a loss of confidence. Changing historical blocks, transactions locked in prior to the start of the attack would be extremely difficult even in the event of a 51% attack.
As discussed, in the 51% attack, attackers have control on more than 50% of the network’s computing power. The success of such an attack has better chances for a fairly un-distributed Blockchain network. In the well-distributed Blockchain networks, it is very difficult, almost close to impossible to take charge of more than 50% of the network’s computing power. In less distributed Blockchain networks it would be comparatively easier to launch 51% attack because there will be fewer miners. For example, if there are only 3 miners in a network and if 2 go, rogue, then they already have the majority of computing power and they can launch a 51% attack.
- Consider another potential security flaw. What happens if all the miners come to a consensus to undo certain transactions? What do they have to do? Simply delete or edit specific lines in the distributed ledger which all of them maintain. They can do this and no one will be able to do much about it. In the case of the Ethereum DAO a Decentralized Autonomous Organization, its goal was to codify the rules and decision- making apparatus of the Ethereum organization, eliminating the need for documents and people in governing, creating a structure with decentralized control. After the hack on the DAO, the Ethereum community almost unanimously voted in favor of a hard fork in order to roll back transactions. Yes, these were vicious transactions that were done to illegally siphon off tens of millions of dollars worth of digital currency by an anonymous hacker. But, this sheer ability to do anything, whether it is a hard fork or something else, in order to roll back transactions that have happened can potentially be viewed as a security flaw. This hard fork also allowed DAO token holders, by the way, to get their ether funds returned to them.
- Here is a third potential security flaw. In Blockchain, the private key is almost everything. It is the most important entity that enables miners to accept genuine transactions and reject potentially fraudulent transactions. Thus it should be kept private by users. But one problem with a private key is that it is a long string of 32-bytes and it is impossible to remember because it is basically, random. Hence, users may end up storing their private keys in ways that are not secure- for example, on a piece of paper, on their mobile phones or a computer that they also use to browse the internet. Maybe, some users will simply commit their pin to memory and wake up after a night of partying to realize they cannot quite remember the 3 characters at the end of the key.
- Let’s discuss a fourth potential security flaw. Remember how any information once put on the Blockchain is practically impossible to edit? It is the same for smart contracts deployed on Ethereum. If you deploy a smart contract that has a potential security flaw and realizes it later, it is very difficult to do much about it. You may simply have to sit back and hope that a potential attacker will not realize or will not exploit the chink in your armor. For example, in the case of Parity wallet, the new update of wallet software was faulty. The issue was the result of a bug in a specific multi-signature contract known as the wallet. This bug cost them $ 30 million. As the contract was deployed on the network they couldn’t do anything but to announce that "any user with funds in a multi-sig wallet" move their funds to a secure address. This loss of value was purely because of the more-or-less permanence of changes once deployed on the Blockchain.
Can you think of any more? If you can, good for you. If you cannot, buy our Blockchain courses.