Cover Image for Ethereum Classic 51% Chain Attack July 31, 2020

Ethereum Classic 51% Chain Attack July 31, 2020

Blockchain
ETH2'
Research

This article is based on excellent exploration by Yaz Khoury, Sam Johnson, Austin Roberts and on on-chain data from Bitquery.io

What happened

Ethereum Classic yesterday experienced a huge ‘51% attack’. One miner, 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e generated a series of more than 3500 blocks, as a huge fork from block 10904146 till 10907740. He mined these blocks for many hours and broadcasted them afterward to other miners. As this sequence of the block had more weight than the chain, built by all other miners, they had to accept these blocks, effectively replacing the blockchain history with attacker’s one.

What else happened

It appeared, that not all nodes equally processed this event. Nodes based on Open Ethereum ( and we at Bitquery.io among them ) did not do accept attacker series of blocks. This resulted in fork on 2 blockchains depending on what software installed on nodes:

  1. Geth and Hyperledger Besu — based nodes accepted attacker blocks and selected the longest ( heaviest ) forked chain
  2. Open Ethereum — based nodes remained on the “old” forked chain

Previously at July Open Ethereum announced that they skip support for ETC, but we did not expect that the software will break in such a weird and unpredictable way. Especially when nobody make any changes to it 🙂

What it means for users

Some transfers of ETC that happened during 12 hours, starting from 16:30 UTC July, 31, till 3:30 AM August, 1st, are not included in the new blockchain. If anyone transferred money at this time, now it will not appear in her or his wallet.

There was a period of time at August, 1st, when there was a number of miners ( probably based on open ethereum ) continuing to mine the ‘old’ chain. Users of that wallets made transfers, and they were not reflected in the main ETC chain.

What it means for miners

Miners probably lost a large amount of ETC mined during the attack. Also some miners spent more hash power, mining blocks on wrong ‘old’ fork after the attack.

What it means for all of us

‘Proof of work’ blockchains mostly considered more secure than other consensus types. However in the core idea is the probability theory, which can only gives some level of confidence, never reaching 100%:

Confirmation probability

Confirmation probability

It starts from 0%, when transaction just happened and not included in blockchain, rapidly raising to ‘almost 100%’ when more blocks are added on top of the block, containing the transaction. Proof of work consensus just helps to raise this curve to 100% very very quickly, as 99.99999 confidence in 6 blocks. Thats why wallets and exchanges have a confidence window of blocks.

It is a big mistake to consider the probability numbers and confidence in the predictions. From the high probability you can never derive, that event will never happen, for example, because its probability is very low and it takes an age of universe for this to happen. It just does not work this way, Taleb in his Black Swan book shown that in many examples.

When you own crypto currency on your wallet, it only means that there is some probability of that, and it never 100%. Today example shown, that no reasonable amount of time can raise confidence to the level, when you can assume that it is actually 100%. Nobody can predict that more than 12 hours of history with all transfers could disappear, but it did.

Mining Power

Attacking miner (0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e ) should have more than 50% of mining power of all miners to make such an attack and sustain it for 12 hours.

We observe the raise of price on mining hashrate provider daggerhashimoto, during the attack period:

Mining hashrate price spike in the market

Mining hashrate price spike in the market

The time here is UTC+3, so the spike in the price ( blue line ) starts at the same time as attack, and matches the attack period exactly. It is all time high price for hash power at this service! It may be coincidence, but the matching data telling it can be related to ETC attack.

The price for the hashrate, bought on this service can be estimated from the numbers shown on graph:

5 BTC / TH / day * 1/2 day * 7 TH= 17.5 BTC

Assuming that attacker bought all hash power ( 7 TH / s ). This is in the same order of magnitude as the graph for ETC at 2miners.

Attacker spent just 17.5 BTC ( $170K ) to fool all network for 12 hours.

The miner, 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e only appeared active since July, 29 and for 3 days generated modest number of blocks, 30 per day:

Activity of miner, based on bitquery.io data ( non-reorg fork)

Activity of miner, based on bitquery.io data ( non-reorg fork)

On-chain activity during the attack

We made a preliminary investigation only based on non re-org’ed data, not including the attacker’s blocks. We were very actually lucky that were running Open ethereum nodes, as of now, we will have the ability to have both forks data and match one against the other.

When attacker mined his ‘forked’ blocks he actually was not publishing them, and nobody knew it is happening. Users sent transactions to the chain, and the largest transactions in ETC were:

Data is from Bitquery.io non-reorg database

Data is from Bitquery.io non-reorg database

Some of the transfers from these are included in the forked blockchain, as the largest one. In non-reorg database it is at block 10906346 and in re-orged it is on block 10907763

However, not all of these are so lucky. For example, the transfer 0x069db204ea87f62817dff7320d0177815c9a7f56811a3a4be00e0c2d862dda39 now is not included in the chain, and the balances of addresses ( say, 0x97b2a6ca77e2a0fccd15e082b27cb566ddb31ee4 ) differs in non-reorg’d and re-org’ed chains.

This chain of transfers will not appear in org’ed chain:

money flow

money flow

We are now upgrading our node to geth, and soon will have the data for both chains — re-org’ed and non-reorg, and will be able to match the transactions between them. As we see, there are major differences in these forks, and some addresses may be suspected for double spending.

Conclusion

What happened is a major accident in ETC blockchain. It can be observed in any proof of work blockchain in the future, so any such accident need careful analysis.

There are facts showing that the miner did the attack intentionally, buying hash rate power from external sources.

Further analysis required to find mismatches on re-orged and non-reorged chains to reveal the possible facts of double spending and other issues. We will be happy to share the data for both databases with all interested parties, doing their analysis and investigation of accident. Please write your query to sales@bitquery.io.

Not all software run by nodes and miners, behave the same. The diversity of versions and software made the accident worse than it could be.

Looking for end to end Crypto investigation tool? Explore Coinpath Moneyflow, built for investors and law enforcement agencies. Check it out here!

Also Read

About Bitquery

Bitquery is a set of software tools that parse, index, access, search, and use information across blockchain networks in a unified way. Our products are:

  • Coinpath® APIs provide blockchain money flow analysis for more than 24 blockchains. With Coinpath’s APIs, you can monitor blockchain transactions, investigate crypto crimes such as bitcoin money laundering, and create crypto forensics tools. Read this to get started with Coinpath®.

  • Digital Assets API provides index information related to all major cryptocurrencies, coins, and tokens.

  • DEX API provides real-time deposits and transactions, trades, and other related data on different DEX protocols like Uniswap, Kyber Network, Airswap, Matching Network, etc.

If you have any questions about our products, ask them on our Telegram channel or email us at sales@bitquery.io. Also, subscribe to our newsletter below, we will keep you updated with the latest in the cryptocurrency world.

Subscribe to our newsletter

Subscribe and never miss any updates related to our APIs, new developments & latest news etc. Our newsletter is sent once a week on Monday.