Blockchain technology is designed to make it possible to maintain a digital ledger in a decentralized and distributed fashion. An essential and challenging part of this is ensuring that there is only one official version of the ledger at any given time and protecting against double-spend attacks. While blockchain technology has solutions in place to accomplish this, it does not always work, and it can be difficult to differentiate between a simple error and a legitimate attack.
The Longest Chain Rule and Chain Reorgs
Blockchain consensus algorithms are designed to achieve a decentralized consensus regarding the state of the distributed ledger. This includes ensuring that there is only one accepted version of every block in the blockchain.
However, many blockchain consensus algorithms only provide a probabilistic proof of consensus. For example, Proof of Work is designed to make it unlikely that more than one version of a given block will be found within a specific interval. However, it is entirely possible that two versions of a block will be found. In fact, this happens quite frequently and is what makes double-spend attacks possible.
The longest chain rule is blockchain’s way of addressing these conflicts. It states that, if an honest node is presented with two valid versions of the blockchain, it should accept and build upon whichever one is “longer”. While definitions of “longer” can vary, the rule itself is pretty simple.
It is important to note that the longest chain rule doesn’t place any limitations on when conflicting chains can be produced. The theory is that the odds of a divergent chain catching up after a long period of time are essentially zero. However, these deep chain reorganizations are still possible.
Inside Two “Double Spends”
Within the first two months of 2021, two double-spend attacks were publicly reported. However, only one of these was an actual attack.
1. Bitcoin Double-Spend Attack in January 2021
In January 2021, news outlets reported a double-spend on the Bitcoin blockchain. This report was based on the fact that two different versions of the same transaction were included in two divergent versions of the Bitcoin blockchain.
However, this was not evidence of malice on behalf of the user. Instead, the user in question was taking advantage of a function called Replace By Fee (RBF). An RBF transaction is identical to the original transaction but has higher fees. It comes with a note requesting that miners include it in the blockchain rather than the original transaction.
At the time the user created the initial transaction, the Bitcoin network was busy, forcing up transaction fees. The user’s initial transaction fee was too low, causing it to sit for over a day without being added to a block. As a result, the user used an RBF transaction to raise the transaction fee, and, several hours later, a second RBF to raise the fee again.
A couple hours later, the blockchain experienced a natural split into two versions. At this point, the transaction fees had lowered as well, meaning that all three versions of the user’s transaction would have been acceptable to miners. One version of the blockchain followed the chain of RBFs and added the third version of the transaction, while the other included the original transaction.
As a result, the two versions of the blockchain included a “double spend” since different versions of the blockchain contained mutually compatible transactions. However, these two transactions were the same transaction (with different fees), and one version of the blockchain would lose to the other under the longest chain rule. In the end, only a single version of the transaction would be accepted and included in the digital ledger.
2. Verge Double-Spend Attack in February 2021
In February 2021, Verge underwent “likely the deepest reorg that has ever taken place in a ‘top 100’ cryptocurrency”. The attacker was able to replace over 560k blocks in the blockchain, creating a version of the ledger that last matched the official one in August 2021. As a result, many months of transactions and wallet balances were suddenly wiped out.
This attack leveraged the longest chain rule and GPU mining for malicious purposes. Since the hash functions that Verge uses can be mined using a GPU, an attacker can rent enough hash power to create a malicious version of the blockchain that is longer than the original one. If successful, the attacker can perform double-spend attacks and make money off of the rewards earned for mining blocks.
It is likely that this attack included attempted double-spend attacks, but it is difficult to say due to the scale of the reorg. In the end, the Verge community was able to reverse the attack by outspending the attacker, mining enough blocks so that the official version of the blockchain became and remained the longer version. However, accomplishing this required breaking the rules since legitimate nodes “should” have switched over to and stayed on the longer of the two chains when the malicious one became public.
Securing the Blockchain Ledger
Blockchain is built on decentralization, and it is impossible to have a fully decentralized cryptocurrency that is immune to 51% attacks like the one performed against Verge. If a blockchain has a way to overcome a 51% attack, then it has some level of centralization. This is made evident by Verge’s ability to “break the rules” as a community to overcome the attack that they faced.
Maintaining the security of a fully decentralized blockchain requires ensuring that the incentives and protections built into the blockchain protocol actually work. This involves building a large base of block creators (to make a 51% attack expensive) and ensuring that a blockchain protocol doesn’t contain vulnerabilities or features that make it possible to perform a double-spend attack with less than 51% of hash power, as occurred in an earlier attack against Verge.
Halborn can’t help you build up a base of block creators. But we can help you to identify and fix the issues that make a cryptocurrency more vulnerable to attack. Get in touch at firstname.lastname@example.org to find out how.