Blockchain 51% Attacks – Lessons Learned for Developers and Trading Platform Operators
Once purely theoretical, “majority” or “51%” attacks on public blockchains have dealt participants a reality check: The fundamental assumption of Satoshi Nakamoto’s 2008 Bitcoin whitepaper (that computing power will remain sufficiently decentralized in blockchain networks that rely on a “proof-of-work” consensus mechanism) can in practice actually be exploited to enable double spending.
“The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes…. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.” – Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System
These incidents have provided opportunities for developers of both public and private blockchains, as well as operators of blockchain-based digital asset trading platforms, to learn from the first generation of blockchain deployments.
Recently, two reorganizations of the Bitcoin Gold (BTG) blockchain (the hard fork of Bitcoin) resulted in 7,167 BTG (then approximately $87,500) being double spent. It has been suspected that the computing power necessary to maintain this grift was rented through NiceHash, a hash power marketplace.
While not nearly as large a haul as the over 388,000 BTG (then approximately $18 million) heist in May 2018 or the attack executed on the Ethereum Classic (ETC) blockchain in January 2019 in which 219,500 ETC (then approximately $1.1 million) was double spent, this latest 51% attack on a major public blockchain serves as a reminder of the practical implications of this known vulnerability.
What is a 51% Attack?
The Bitcoin Gold and Ethereum Classic blockchains, among other high-profile blockchains, determine “truth” using a proof-of-work consensus algorithm, whereby network participants compete for the right to add blocks to the blockchain by expending computing power to solve complex computational problems the fastest. Nodes on such a blockchain network always consider the longest version of the blockchain (i.e., the blockchain that took the most computing work to generate) to be the correct one.
A 51% attack is when a malicious actor controls a sufficient percentage of the network’s computing power such that it is able to build and verify blocks quicker than the rest of the network can, resulting in the network accepting the attacker’s version of the blockchain as the “truth.” By doing so, an attacker can decide which submitted transactions are approved and added to the blockchain. It can also erase old transactions if it is able to build a new “longest chain” starting from a block that came before those transactions were added to the blockchain, as that new longest chain would not include those transactions.
An attacker could, for example, use this influence to spend its cryptocurrency (e.g., exchange it for another cryptocurrency or USD on a trading platform) and then go back and erase that transaction, giving the attacker possession of the “spent” cryptocurrency again. This would enable the attacker to spend that same cryptocurrency twice – a “double spend.”
There are limits to what a 51% attacker can do, however. The farther back in the blockchain a transaction is, the more exponentially difficult it is to erase it. This is due to the immense computational work required to build an alternate “longest chain” (which would need to stem from a block before the transaction to be erased) faster than the rest of the blockchain network can continue building the incumbent chain. Also, while a 51% attacker can potentially erase old transactions, it cannot fabricate new transactions using other blockchain network participants’ addresses, as it is not possible to do so without having the private keys associated with those addresses (which are necessary to digitally “sign” transactions). In the words of Satoshi Nakamoto’s whitepaper, attackers cannot “[create] value out of thin air or [take] money that never belonged to the attacker.”
Although the largest blockchain networks, such as Bitcoin (BTC) and Ethereum (ETH), have a sufficiently high hash rate to make it unlikely for a would-be 51% attacker to amass the computing power necessary to take control, a number of developments since the Bitcoin blockchain launched in 2009 have increased the likelihood of blockchains with lower hash rates being compromised. In fact, websites exist that calculate the theoretical cost of a 51% attack on the largest blockchain networks, and those costs are relatively low outside of the top few blockchains. Application-specific integrated circuits (ASICs) purpose-built to mine cryptocurrencies and powerful graphics processing units (GPUs) have flooded the mining community, mining pools have consolidated resources and hash power marketplaces have made significant computing power available to rent. Looking ahead, quantum computing also could pose a threat if concentrated in the hands of malicious actors.
As with many technological innovations, running blockchain deployments through the gauntlet of real-world use has provided valuable insights that can inform the next generation of developments. As developers and digital asset trading platform operators continue to iterate, they may want to consider the following points:
Engineer 51% Attack Resistance: Proof-of-work consensus algorithms could potentially be strengthened with a mechanism that detects indicators of 51% attacks and, by design, hinders them. For example, Horizen (formerly ZenCash) has suggested in a whitepaper instituting a block acceptance time delay for any alternate “longest chain” that a 51% attacker keeps hidden until it is ready to broadcast to the network, which would penalize the attacker proportionately based on the number of blocks it secretly builds in constructing its “dishonest chain”. This would give the correct “honest chain” an additional window of time to catch up to and overtake the dishonest chain, making it more difficult for a 51% attack to be successful.
Alternate Consensus Mechanisms: Although each type of consensus mechanism has its own drawbacks, consider variations of “proof-of-work” or other consensus algorithms, such as “proof-of-stake” (in which the probability of a particular node being selected to create a new block is based on the percentage of the blockchain’s total tokens owned by that node).
Even Out the Hash Rate Playing Field: Consider guarding against concentrations of computing power by instituting measures to maximize the decentralization of hash rate, such as by designing the blockchain to be resistant to the advantages of ASICs, GPUs or quantum computing.
Resisting Quantum Dominance: It is important to consider the implications of quantum computing on systems that rely on cryptography for security and on blockchains that utilize proof-of-work consensus mechanisms, particularly if quantum computers are purpose-built to perform proof-of-work calculations in a manner that exceeds the speed of current specialized ASIC hardware. During the period before quantum computing achieves widespread adoption, there may be heightened risks associated with using systems that are not quantum-resistant, as a few bad actors with access to quantum computers could potentially use them to overpower a blockchain network more easily than they could with current technology.
Private and Hybrid Blockchain Governance: In the context of private and hybrid blockchains, where the number of nodes on the network are likely significantly fewer than their public counterparts and there may be some degree of centralization, it is important that the governance mechanisms coded into the blockchain appropriately anticipate scenarios in which control over certain nodes may be compromised. From a legal perspective, it is also critical that the governing legal agreements that the participants enter into appropriately address how risk will be allocated and how issues will be resolved.
Longer Exchange Hold Times: Trading platforms may benefit from requiring longer hold times before deposited tokens can be traded or withdrawn – waiting for more “new block” confirmations after a deposit is made can help reduce the risk of a 51% attack being sustained for long enough for the attacker to complete a double spend.
Avoid Weak Links Ancillary to Blockchains: Despite the occurrences of 51% attacks, many of the incidents that have resulted in the theft, loss or inaccessibility of blockchain-based digital assets were due to flaws in technology ancillary to blockchains (for example, flaws in digital wallets or smart contracts that interact with, or are deployed on, blockchains), rather than the underlying blockchain itself. Care should be taken to thoroughly test those potential weak links before deployment or use. Developers of products that build on top of, or interface with, blockchains should be sure to draft their governing license terms or terms of service to appropriately insulate them from liability for defects or errors.