Identifying the BSV 51% Attack
On August 4th, 2021, we identified and broke news on a 51% attack on the Bitcoin Satoshi’s Vision (BSV) blockchain. A total of 14 blocks vanished as the blockchain went through a reorganization event, commonly known as a reorg.
I have written in the past about the intrinsic flaws in BSV’s design, warning specifically about the issues around its ludicrous block size limit. Nodes simply cannot stay synchronized when relaying and validating blocks that exceed 1GB in size. Even when we used state-of-the-art, high IOPS machines at Coin Metrics, the node struggled and sync issues continue to be a common occurrence.
Generally, synchronization issues can be diagnosed when the node is unable to keep up with the latest block height seen by its network peers. At times, the node might get outright stuck and need to be restarted. Given that were familiar with these issues with BSV, we were able to quickly identify that this time around, syncing was not the culprit.
At around 11:45 AM that day, one of our nodes suddenly faced a 14-block reorg. Five minutes later, our second node reorg’d as well. Upon investigating, we immediately knew there was something wrong going on. We estimated that an attacker had allocated over 180,000 TH/s for over two hours to trigger a reorg at that depth. For context, this would require the power of around 12,800 BITMAIN S9 miners.
Attackers have historically monetized 51% attacks by targeting crypto exchanges. Their power to reorganize the blockchain enables them to invalidate transactions previously considered “confirmed” and thus spend the same funds twice — a double spend.
A double-spend usually works as follows:
The attacker deposits funds, in this case, BSV, into a crypto exchange.
The exchange then requires a fixed number of blocks to elapse after the deposit has been made. This is usually referred to as a “confirmation requirement” before the deposit can be used for trading.
Once funds are available, the attacker trades them for another cryptoasset, like BTC or ETH.
The attacker then withdraws the funds from the exchange, which is usually processed right away.
Once funds have been withdrawn in the form of another cryptoasset, the attacker unleashes the 51% attack and reorgs the blockchain in order to erase the deposit transaction from step #1. The attacker now has the original funds plus whatever cryptoasset it was able to extract from the exchange.
No exchanges publicly disclosed being attacked but it’s possible the attacker targeted, perhaps multiple times, the few exchanges that required 6 block confirmations for BSV.
One interesting aspect of this attack was that we were able to see what happening at the BSV mining pools. As part of the Coin Metrics FARUM risk suite, we were able to see which “branch” of the blockchain mining pools were working on. We do this by connecting to them via the Stratum mining protocol and requesting mining jobs to the mining pool server.
Above is what a Stratum mining job looks like. The highlighted field represents the previous block hash the pool is mining on and the second-to-last field is a Unix timestamp in hex form. Combined, these two fields enable us to predict which branch is likely to “win”, during and after an attack like this. If you know the hashrate produced by each of the supported mining pools, you can estimate the probability of a specific branch winning the mining competition at a point in time.
In the aftermath of the BSV 51% attack, mining pools were all in disagreement on which branch to follow. Like us, mining pool operators likely faced syncing problems hours after the attack. This level of monitoring is critical because it allows us to identify when a network is “up” again.
Our research in this area was featured on Forbes, CoinDesk, and many other publications.