Vertcoin (VTC) was successfully 51% attacked

TL;DR: In 4 distinct incidents, the latest of which concluded on 12/2, Vertcoin (VTC) experienced 22 deep chain reorganizations, 15 of which included double spends of VTC. We estimate that these attacks could have resulted in theft of over $100,000. The largest reorg was over 300 blocks deep.

Mark Nesbitt
Published in
7 min readDec 2, 2018


Edit: No attacks have been observed from the time this article was published on 12/2. We have therefore concluded that the 4th and most recent incident has concluded. We will provide updates for any additional developments as they arise.

Background Info

Page 3 of Satoshi Nakamoto’s whitepaper, Bitcoin: A Peer-to-Peer Electronic Cash System, states the following:

If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.

The “honesty” of more than half of miners is a core requirement for the security of Bitcoin and any proof of work cryptocurrencies based on Bitcoin. Honest action, in this context, means following the behavior described in the Bitcoin white paper. This is sometimes described as a “security risk” or “attack vector,” but is more accurately described as a known limitation to the proof of work model.

Failure to meet this requirement breaks several core guarantees of the Bitcoin protocol, including the irreversibility of transactions.

The function of mining is to add transactions to the universal, shared transaction history, known as the blockchain. This is done by producing blocks, which are bundles of transactions, and defining the canonical history of transactions as the longest chain of blocks*. If a single miner has more resources than the entirety of the rest of the network, this miner could pick an arbitrary previous block from which to extend an alternative block history, eventually outpacing the block history produced by the rest of the network and defining a new canonical transaction history.

This is called a “chain reorganization,” or “reorg” for short. All reorgs have a “depth,” which is the number of blocks that were replaced, and a “length,” which is the number of new blocks that did the replacing.

This, on its own, might end up being nothing more than a minor inconvenience. After all, the transactions all still exist, but they might have been put into a different order, perhaps delaying some of them.

However, imagine a miner that also owns a large number of coins. The miner could send those coins to a merchant in a transaction, T, while also secretly extending an alternative block history. The miner’s secret blocks do not include T, but rather include a transaction that sends the same coins used in T to a different address. Call that transaction T’. When the miner reveals this secret history, it will contain T’, not T. Because T and T’ attempted to send the same coins and T’ is now in the canonical history, this means that T is forever invalid, and the recipient of the coins sent in transaction T is out of luck. More info on this can be found here.

If this were to happen to a coin in the wild, that would be a serious problem for anyone who uses that coin.

What we observed

We observed repeated deep reorganizations of the Vertcoin blockchain, with the largest reorg having a depth of 307 blocks and a length of 310 blocks. The total value of the double spends was over $100,000.

These reorganizations can be grouped into 4 distinct incidents, based on timing and the characteristics of the attack.

Note: In order to limit the scope of this article, no blockchain analysis was performed on the actual coins that were used in the attack. I invite the community to examine the inputs of the double spent transactions, trace the history of involved coins, scrutinize the block fields such as timestamp, look at the subsequent movement of coinbase rewards from attack blocks, or perform any other relevant blockchain analysis that would shed light on the threat actor or actors behind these attacks.

Incident 1: 10/12/18–10/18/18

There were 8 reorgs in this incident. The first 5 reorgs did not include any double spends, while the final 3 all included double spend transactions of a total of 71,243 VTC.

Incident 2: 10/27/18–10/28/18

There were 8 reorgs in this incident, all of which included double spends for a total of 53,847 VTC. These reorgs were not as deep as the previous incident or either of the two subsequent incidents.

Incident 3: 11/3/18

There were 2 reorgs in this incident, and we did not observe double spend transactions in either.

Incident 4: 11/29/18–12/2

There were 4 reorgs in this incident, all of which included double spend transactions. These were the deepest reorgs observed that also included double spends, suggesting perhaps that the victim of double spends had raised confirmation requirements, forcing the attacker to expend more hashpower for each attack.

What we can learn

These attacks on VTC are not the only examples of a successful 51% double spending attack. 51% attacks occurred in BTG, XVG, and MONA earlier this year; this is merely another incident that shows that threat actors exist that are both resourced and sophisticated enough to execute this kind of attack.

This recent spate of successful 51% attacks has significant implications on what is often referred to as the “long tail” of cryptocurrency assets. There are a large number of cryptocurrencies, including many based on Bitcoin, that implement their own proof of work based blockchains. Observers of the industry have claimed that these assets have the same properties as bitcoin. This claim has now been undeniably, empirically proven to be false.

Exchanges make an ideal target for this sort of attack. This is because exchanges allow deposits to be quickly traded into different assets and then withdrawn. An attacker can make a soon-to-be-reversed deposit, trade for another asset, move the new asset off platform, and then reverse the original deposit.

Exchanges find themselves with very few effective countermeasures for this sort of attack. When an attacker has greater than 51% of hashing power, no number of confirmations can make receiving deposits in the asset safe. An exchange that is under attack has no long term solution other than ceasing interaction with the asset’s blockchain. The fact that the most recent attack had a depth of 307 blocks shows the ineffectiveness of increased confirmations as a countermeasure to this type of attack.

The ease of executing these attacks casts significant doubt on the viability of these assets to provide a stable system of ownership. Unless the dominant application of the underlying hardware used to mine a cryptocurrency is actually to mine the cryptocurrency, there will always be a significant risk of a 51% double spending attack. Let me repeat that: the only way an asset can materially reduce the risk from 51% attacks is to be the dominant application of the hardware used to mine the asset.

While a full exploration of ASIC resistance is out of scope of this article, the observations above strongly suggest that pursuit of ASIC-resistance in a coin is counterproductive to the coin’s security. If you’re interested in exploring this topic, I’d suggest starting by viewing Andreas Antonopoulos’ video here and reading the Siacoin team’s outstanding blog post on the subject.

The second option is strictly worse

In conclusion

As stated above, exchanges make an ideal target for this type of attack. As long as exchanges are willing to provide customers with assets in response to the deposit of a reversible currency, there’s no reason for attackers to stop this behavior. Expect to see more of these attacks.

Exchanges that support these assets will continue to suffer losses, with the ultimate result that exchanges will be forced to delist these assets. In such an environment, it’s hard to find a compelling argument for why these assets should have value.

I encourage you to patronize exchanges that place the security of customer funds as their highest priority.

* It is actually the chain with the most accumulated work, rather than the chain with the most blocks, that defines the canonical history. In most cases, these chains will be the same

  • * The block explorer does not properly handle reorgs and labels the transaction as confirmed. Click on the block to see that the block is orphaned.