ETC's cheap 51% attack puzzle

Editor's Note: This article comes fromGolden Finance, reprinted by Odaily with authorization.

Editor's Note: This article comes from

Golden Finance

The attack was initiated by an independent miner "0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e". The miner quietly produced 3594 blocks, and then broadcast them to other miners. Due to the large number of these blocks, the order of the blocks has a greater weight than the chains established by other miners, causing other miners to accept this series of blocks. In the end, the attacker block successfully replaced the original block, and reorganization occurred from block height 10904146 to block 10907740.

, reprinted by Odaily with authorization.

On August 3, the official Twitter of ETC announced the investigation report of Bitquery, a blockchain data analysis company, on the 51% attack on ETC.

The report shows that from 0:30 on August 1st to 11:30 on August 2nd, ETC suffered a 51% attack.

The attack was initiated by an independent miner "0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e". The miner quietly produced 3594 blocks, and then broadcast them to other miners. Due to the large number of these blocks, the order of the blocks has a greater weight than the chains established by other miners, causing other miners to accept this series of blocks. In the end, the attacker block successfully replaced the original block, and reorganization occurred from block height 10904146 to block 10907740.

The data on the chain shows that the miner deliberately purchased hash power from the outside to launch an attack, and the miner’s address has only been displayed as active since July 29, generating 30 blocks per day for 3 consecutive days. In the end, the attacker only spent 17.5 BTC (about 170,000 U.S. dollars) to deceive the entire ETC network for 12 hours and successfully implemented the attack.

Furthermore, since not all software run by nodes and miners behaves the same in the ETC network, the diversity of node versions and software makes this attack even more severe:

Nodes based on the two clients of Geth and Hyperledger Besu accept the attacker's block and choose the longest forked chain;

Nodes based on the Open Ethereum client still retain the old chain. All these have caused some miners to transfer money based on the old chain, but it is not reflected on the main ETC chain (forked chain), and nodes based on different clients may face double spending.

According to the investigation of relevant agencies, the specific process is as follows:

1. Malicious miners (ETC address: 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e) mined about 3000 blocks.

2. The 2Miners pool was temporarily offline for maintenance because Multi-geth ended its support for Ethereum classic.

3. During the maintenance period of the 2Miners mining pool, the 2Miners mining pool did not generate new blocks. After the 2Miners mining pool ended its maintenance and went online, about 3,000 blocks were inserted into the 2Miners mining pool at the same time.

4. Since none of the Parity or OpenEthereum nodes on Ethereum Classic could process the 3693 blocks from the Core-Geth node, a chain fork occurred:

All the miners on the Parity or OpenEthereum nodes are still mining on the original main chain, but the miners on the Core-Geth nodes are mining on the new chain that has been inserted for about 3000 blocks.

5. According to the Proof of Work (POW) consensus, the workload on the new chain will gradually exceed the original main chain, and some miners on the Parity node on the original main chain will "choose to mine on the chain with more workload" Guidelines, transfer to the new chain for mining.

Finally, at block height 10904146, a total of 3693 blocks were added to the blockchain through reorganization.

Through the investigation and information release of the two organizations, there are obviously two reasons, one is because of the recent client support problems, and the other is that the attackers just took advantage of this.

Different clients represent different access roles. Miners are both network maintainers and data producers. This means that if the client provides some incorrect data, it is synchronized by other nodes, which is the beginning of the attack .

The above-mentioned attacker took advantage of the re-online timing of the mining pool nodes to make the prepared block data mistake the mining pool for correct accounting data and continue to broadcast. And because of the "discord" of Parity, OpenEthereum, and Core-Geth client miners, the synchronization of different data is inconsistent, so it will lead to forks.

The source of this attack is the confusion of the client, and the cause of this incident has been brewing for a long time.

According to previous reports from Jinse Finance, on January 25, 2020, Bob Summerwill, executive director of ETC Cooperative, recently announced the extension of support for the ECIP-0001 proposal. Some changes in the proposal include the removal of Rust developer Wei Tang.

Bob Summerwill accused Wei Tang, as an ECIP editor and ECIP-1000 author, for repeatedly abusing his power and threatening to soft fork or leave the ETC ecosystem.

In addition, since soc1c's real name was used instead of soc1c in the editor list of ECIP-1000, there are voices in the ETC community accusing Wei Tang of doing a human flesh search for soc1c, another ECIP editor in the community.

In this regard, Wei Tang explained the cause of the incident in his blog, and responded that the changes to the proposals involved are due to the consideration of avoiding the over-centralization of ETC. But in the later period, the controversy actually shifted to himself. At the same time, Wei Tang said that there is no so-called human flesh soc1c fact. Because soc1c himself agreed when merging the editor list before, and soc1c's real name is widely known in the community, and he often uses his real name.

It is reported that the controversial incident originated from the ECBP-1076 proposal. Wei Tang asked for more discussion, but was rejected by soc1c because he felt that the ECBP-1076 proposal was first proposed and accepted at the ETC meeting for the first time, and that the ECIP editor changed the status of the ECBP-1065 proposal to "Active" imprudently ( soc1c performed the revocation review), after which soc1c submitted a request to remove Wei Tang from the ECIP process. Since then, during the hard fork of Aztlan, there have been disputes over ECIP-1061 and ECIP-1072 (the "revocation" operation also appeared in this dispute). Wei Tang believes that the "revocation" operation of soc1c in the proposal process is actually a great centralization risk, and created a new request, arguing that the "revocation" operation violates the process and should not be regarded as a norm.

Wei Tang and the community also have different views on the postponement of the ETC Aztlán hard fork. He believes that the error in the Aztlán specification has already caused irreparable damage to the Mordor and Kotti testnets. Now he only hopes that the damage will not spread to the mainnet. Wei Tang said that "irresponsible hard forks will destroy network security, and it is useless to shout that the code is the law every day."

Bob Summerwill responded that the delay in the fork was due to unpredictable block time factors, rather than the community changing the block number of the previously selected hard fork. Errors in block time predictions are common. In response to the accusation that the community is unhealthy, Bob Summerwill responded that the ETC community is very healthy.

Confrontation is repeated, but unity cannot be confirmed.

On June 14, Wei Tang announced that he would stop supporting ETC personally, because after the Phoenix hard fork, the ETC network broke the logic of Ethereum consistency, especially in terms of immutability.

A month later, OpenEthereum and MultiGeth, the two major clients of ETC, announced that they would stop supporting ETC. And since these two clients still share 70% of the total number of nodes on the ETC network, this is a public service announcement for ETC users to take appropriate action. According to the article published by Wei Tang later, the reason why the two major clients stopped supporting ETC is the same as the reason why Wei Tang stopped supporting ETC.

This is the source of the attack. When a network node client accounts for more than half, and its service is suddenly stopped, the network must be dangerous in the later process of computing power migration.

Regarding the news that OpenEthereum and MultiGeth announced to stop supporting ETC, ETC Asia-Pacific community manager Christian said that Gnosis, the maintainer of OpenEthereum, has made an official statement that the reason for stopping supporting ETC is to devote its limited energy to the development of the Ethereum mainnet, not Wei Tang said reason.

After Phoenix, the actual developer of MultiGeth is only Wei Tang himself. Due to some differences, Wei Tang chose to stop MultiGeth from supporting ETC.

Since last year, ETC has completed three hard fork upgrades, making the ETC network completely consistent with ETH. Among them, the ETC Core team contributed a lot. As early as the first half of the year, the ETC Core team developed a more secure Go language client, CoreGeth. CoreGeth perfectly supports the Phoenix hard fork, and it has been running intact so far. From the reply to Gnosis, you can also see that after OpenEthereum and MultiGeth quit, CoreGeth, as the official client maintained by ETC Core, is completely trustworthy and continues to serve the ETC network.

Then Wei Tang responded that the fact is that OpenEthereum and MultiGeth are the two clients that support ETC for the longest time. Among them, OpenEthereum is 4 years, and MultiGeth is 2 years. No other client has supported ETC for more than a year. Among them, Hyperledger Besu has supported ETC since September last year, CoreGeth has been separated from MultiGeth this spring to support ETC, and OpenETC has just started to support ETC.

In Tang Wei's view, in addition to the ETC network abandoning the principle of immutability, suspending support for ETC is also a reasonable and necessary response, because in the past 6 months, we have seen a very bad side of the ETC community.

This is the most intense comment for ETC. In the face of client issues, community discord, and sudden attacks.