The first comprehensive exploration of blockchain reorganizations (reorgs), which can occur as a result of bugs, network attacks, or conventionally through a network’s natural consensus process.
These events are difficult to monitor as the reorged version of the chain is discarded by the node. Lovejoy provides a new method for detecting transaction reordering events against live cryptocurrencies.
He also evaluates the most significant double spend attacks and provides a potential strategy for counter attacking.
Citation
Lovejoy, James. “An Empirical Analysis of Chain Reorganizations and Double-Spend Attacks on Proof-of-Work Cryptocurrencies”
Link
Core Research Question
What impact do deep blockchain reorganizations have and what can projects do to mitigate the impact of such events in an adversarial environment?
Background
Nakamoto Consensus is a consensus protocol designed to solve the “double-spend” problem, where an adversary spends the same cryptoassets twice, thereby reversing payments that the recipient already considered settled and irreversible, in an event called a Blockchain Reorganization, or reorg.
“Miners” in Nakamoto Consensus (often called “proof-of-work”), are economic agents that continuously perform a computationally expensive lottery in which they compete to append new transactions to a shared ledger, a blockchain, in return for payment in the form of newly minted coins and transaction fees.
A miner’s probability of winning the lottery is equal to its proportion of the total Hashing Power being used by all miners. Thus, security from double-spending relies on a key assumption that adversaries are unable to control greater than half of the total hashing power.
If this assumption does not hold, an adversary could launch a “51% attack”, in which they use their majority to rewrite settled transaction history or censor transactions from users or other miners.
For many years this assumption persisted unchallenged until a large number of additional cryptoassets were launched, each being mined with much less computational power than Bitcoin.
Combined with the introduction of Mining Rental Markets where miners can outsource their computation to the highest bidder, the assumption that a 51% attack is realistically impossible no longer holds for many less prominent cryptoassets.
Challenging this assumption, theorists have since designed models to explain the incentives against double-spend attacks in a world where computational power for mining is available in a liquid market.
Since 2018, multiple alternative cryptoassets have been successfully 51% attacked in practice, with millions of dollars having been disclosed as double-spent in media reports.
Despite the central importance of Nakamoto Consensus to the security claims of a majority of the cryptocurrency market, scarce empirical research has been performed to understand the nature of 51% and double-spend attacks in practice.
Summary
Despite the central importance of Nakamoto consensus to the security claims of a majority of the cryptocurrency market, scarce empirical research has been performed to understand the nature of 51% and double-spend attacks in practice.
Reorganizations or “reorgs”, events in which one suffix of transactions is replaced by another in the transaction history, are transient such that one must observe them in the moment. This is because the ledger only commits to a single, linear list of transactions without branches and discards any alternative transaction histories that may have been proposed in the past.
It is thus not possible to determine whether a reorg occurred by retroactively analyzing the transaction history. Therefore, until this research, the field’s understanding of 51% attacks was limited to media reports, exchange disclosures and theoretical models.
In order to bring empirical data to this discussion, the author implemented a module that analyzes reorgs for double-spent transactions. The monitoring detected three previously unreported likely double-spend attacks on Bitcoin Gold, Vertcoin and Litecoin Cash. The author was the first to publicly disclose the attacks.
One of these events allowed the author to confirm for the first time the existence of counterattacks as a viable strategy for defending against a profit-driven adversary.
Another event provided strong evidence that mining rental markets are being used to carry out 51% attacks, and the viability of active pool monitoring as an early-warning system for impending attacks.
The third event allowed him to identify deficiencies in a variation on Nakamoto Consensus that was originally intended to prevent attacks but failed to do so in practice.
Finally, Lovejoy presented evidence for miner-executed double-spend and front-running attacks against Ethereum smart contracts.
Method
To collect information on mining pools and reorg incidence, the author designed a new system called the “Reorg Tracker” that monitors cryptocurrency networks to detect, save and analyze reorg events in real-time.
Lovejoy analyzed the dataset in aggregate form to present empirical data on the frequency and severity of reorgs between coins, predominantly by analyzing mining pools operators through a popular mining protocol called Stratum:
Further, Lovejoy found that average reorg frequency is inversely correlated with 1) coinbase issuance 2) block interval, but reorg severity is uncorrelated with the 2.
The results also show that for every coin studied, the compensation offered to miners per hour is significantly lower than the transaction volume in the same period, which plays a role in reorg incentivization.
Less than half of the cryptocurrencies studied have an abundance of computational power available on the open market to rent for mining, which confirms the theory that mining rental markets are a viable method for launching attacks.
They also found that the value of mining rewards is a good approximation of the real-world marginal-cost investment required to append to the ledger for many coins.
Finally, Lovejoy found that the 51% attacks detected were likely to break-even or were profitable even without considering the double-spend.
Discussion & Key Takeaways
Are cryptoasset developers responsible for engaging in counter-attacks in the event of a 51% attack?
Can hashrate rental marketplaces offer a reliable method for counter-attacks?
Is this approach less centralized than the existing attack mitigation approaches, such as block header timestamps?
Applicability
This research is applicable to consensus development research, as it evaluated trade-offs with the ability to reorganize chain state.
It is also applicable as a framework to build network monitors and increase the awareness of reorganization events.
Beyond consensus development, cryptoasset projects can use the methodology described here to potentially revert 51% attacks through counter-attacks.
An interesting anecdote: the heuristic described in the paper can be used to detect 51% attacks before they take place.
Last year, the developers of Bitcoin Gold were notified that there was a shadow chain in the works. Before the attacker could broadcast the 51% chain, the BTG Core developers were able to invalidate it by issuing a custom patch that basically tells every node in the network to trust a specific block hash for a given block height (which essentially rejects any version of the chain other than the “trusted” one relayed by the BTG devs).
Even though the patch was celebrated, it is very much a centralization vector. If core devs can dictate which version of the chain to trust, it opens up a can of worms.
That is an interesting anecdote! Maybe this is asking for too much speculation, but what might be a solution to preventing the attack without the centralization worry?
Beyond centralization, the fundamental problem with block hash checkpoints is that they also become single points of failure.
If, for example, a core maintainer’s git keys are compromised, an attacker could use it to release a new version of the client that grants them absolute power over the network.
For networks without sufficient security budgets to make such attacks cost-prohibitive, the best solution is to instruct users to reject the shadow chain through custom RPC calls. That way, users can see what their nodes are rejecting in a more transparent (and optional) fashion.
Would love to see the code here for this vulnerability. Do research articles of this nature typically publish deficient code? Could help make open-source POW chains be aware and resolve issues quicker.
I wanted to add some more to this discussion as some time has passed since this was posted…I would always say no to the quoted question above. Simply from a logistical capacity standpoint, it would be time and resource consuming to engage in a counter-attack rather than address the issue in development. Politically, counter-attacks are equally adversarial even in the justified event, especially if the actor is a nation state. I think the better question would be, can we accept this great of a risk to the business and people’s assets? Are we giving the user all the diligent information they need about our asset to accept that risk alongside us while development moves forward? Rather than how might we attack back. Might be a little common-sense approach here, but I’m one to believe they make the most sense for a reason.
Interest in this post may be revived by an article that appeared on the front page of the June 6, 2022 New York Times entitled, “How Trustless is Bitcoin, Really?" It summarized the findings of an unpublished academic paper focused on the early days of Bitcoin, before the cryptocurrency was worth $1 per coin. (Bitcoin has since reached a high of $68,000 per coin and stands at roughy $28,500 as of this writing.)
In his podcast (starting at roughly 31:30), noted crypto investor Nic Carter calls the piece “one of the most curious New York Times articles I’ve encountered. It’s very irregular to find glowing coverage of an unpublished draft… [where] there’s no determination from serious peers that the paper is actually good. I read the paper and I can tell you that it’s not good…[and] certainly doesn’t find what the article alleges it finds.”
The paper—written by seven authors, none of whom appears to be a cryptocurrency expert—“scientifically” determines that Bitcoin had (at the time) only 64 major agents, including Satoshi himself and early GPU miners, and that at certain times some of these early agents had more than 50% hash power. “Rather than relying exclusively on a decentralized, trustless network of anonymous actors, Bitcoin depended on altruistic behavior” to prop it up and prevent it from being vulnerable to 51% attacks.
The Times characterizes this as surprising and “ironic,” implying that the Bitcoin protocol was extremely fragile and would not have survived if altruistic human beings had not stepped in to save it.
Nic Carter insists that the original paper and the Times article about it misconstruct historical reality. “You don’t just plunge your hand into the blockchain and pull money out. You need there to be commerce, an entity for you to defraud, to conduct a ‘double spend’ against…and those didn’t really exist. When its price was under $1 per coin, the market cap of all Bitcoin was three or four million dollars. The prize just wasn’t there. To say that Bitcoin narrowly escaped 51% attacks is to be completely ignorant of the context.”
In Carter’s view, the main question the article leaves him with is, “Why was this piece published in the New York Times in the first place?”
I completely agree with Carter in this case. All of the things he mentioned as being necessary for an attack to be even “worth executing” are the logical reasons as to why the Bitcoin network didn’t really “need” altruistic reasons to prevent an 51% attack. It would be equivalent to the SCRF team building this forum, and then going on a destructive rampage of politically incorrect and vulgar posts just to undermine the credibility that had been built before the organization has a chance to get off the ground. As we’re still in the infancy stages of our organization, why would we throw a catastrophic wrench directly into the machine’s engine just because we’re small enough to have a nefarious group do it and take down the entire organization? It would make no logical sense. To further illuminate the example, as there start to be more decentralized think tanks; why would these think tanks undermine their own credibility in the early days just because they could?
The notion that any small chain, early Bitcoin days included would have any incentive to undermine a chain with no active commerce or capital effectively equates all 51% opportunities as equal opportunities for gain by attacking the chain. This is clearly a false equivalence. A blockchain that has a trillion dollars worth of commerce is clearly more worth attacking than a blockchain that has 0 dollars worth of commerce. At the time, the Bitcoin blockchain was closer to 0 dollars of “legal” commerce compared to the time of writing where it is much closer to the Trillion dollars worth of legal commerce than 0. This false equivalence is either sloppy, or intentionally misleading. Either is not good.
I would take the argument as being in good faith if it had framed the 51% altruism prospect around the episode when Ghash.io gained enough hashpower to make a 51% attack possible between the three largest pools, then I might be more inclined to think the New York times was being genuine with their framing. However, since they clearly did not make a logical and game-theory founded argument; I’m much more inclined to think this was a non-sensical Bitcoin adjacent article that is meant to get traffic and not necessarily push the discussion of philosophy or data examination forward.
The market conditions when Ghash declared they would not execute a 51% attack are much more complex than the situation mentioned by NYT. That situation would be much more suitable to discuss the notion of altruism within the community as being the safety mechanism that is preventing 51% attacks in a system with capital and commerce. After this article, I am not certain the NYT is equipped to handle that conversation with the expertise needed to completely understand everything that happened as to not create a reconstruction that is based in an incorrect interpretation from a non-expert.
