50% Ethereum Network Hashrate Will Escape? DAG Issue is Rather Troublesome


The DAG file of Ethereum 4G graphics card is almost full, which means that 4G graphics card can no longer be used to mine. Ethereum may face the problem that 50% – 60% of its network hashrate will escape.

It may be the most concern of miners as it costs a lot to upgrade 4G video memory to 8G.

The miners is the most realistic group of people in the whole crypto industry. Whether to go or stay is only about interests, not faith.

The reason why Ethereum is not captured by ASIC mining machine is its consensus algorithm, Ethash, is very memory intensive. This memory-intensive algorithm makes ASIC chip, which is good at computing, have little advantage in mining Ethereum.

However, the Ethash algorithm also has disadvantages as it generates DAG files which will be stored in the memory. Each block will generate a new DAG file, and this file will contain the encrypted information of all blocks before.

Dag files grow by 520M every year. According to investoon.com, currently, the DAG file of Ethereum is 3.59G, and Ethereum’s is 3.67G. It is estimated that DAG files will reach 4G by the end of December 2020.

“At present, 4G graphics cards contributes more than 60% of Ethereum network hashrate. It is expected that from July to August, these 4G graphics cards will lose the mining capacity.”

Said an insider from a China-based Ethereum mining farm. At present, GPU mining machine has different operating systems, such as Windows 10, Windows 7 and Linux systems, and the occupancy rate of video memory decreases in turn. Linux system can last for about one month. That is to say, those GPU mining machines adopting Windows 10 system will first encounter the problem of being unable to mine.

Where will these obsolete 4G video cards go? It is estimated that most of them will return to the second-hand market and become high-performance game cards for cybercafe or individuals. Or it may also be recycled, with some of the available accessories being reused.

In fact, many project parties have focused on these eliminated network hashrate, but in fact, this is not smooth going.

First, although the application range of video card mining is relatively wide, the mining efficiency of different graphics card is not the same due to different algorithms of public chain. There are few small minerable coins that can be mined.

Second, 50% of Ethereum network hashrate is about 90T, which is very large and devastating for small coins. A large influx of computing power may lead to a sharp rise in production in a short period. The miners who have no loyalty may sell coins and directly suppress the price.

In the space of graphics card, the upgrading of chip is not as competitive as ASIC miner, and the upgrading speed of miner is relatively slow, especially with the ETH price falling from the high point, the new miner’s shipping volume slows down, or even almost stops. The replacement boom of GPU miner has strong relation to DAG documents.

At present, Ethereum supports almost the whole GPU video card mining market. So, even if so much computing power escape, security should not be a problem for Ethereum. In crypto space, no one can lay out in a short time to destroy Ethereum network hashrate.

Probe into the $25 Million Lost Over in the DeFi Protocol Loss


The DeFi protocol—Lendf.Me was attacked, attackers use the re-entry bugs to cover their own fund balance and make the number of withdrawable funds doubled. Now its development team has used red letters in the user interface of Lendf.Me to remind users not to deposit into the contracts accounts.

According the analysis from Beosin, one of China’s top blockchain security companies, now the loss of Lendf.Me has exceeded $25 million. The complete attack process is traced as follows:

The attacker’s address is 0xA9BF70A420d364e923C74448D9D817d3F2A77822; the attacked contracts is 0x538359785a8D5AB1A741A0bA94f26a800759D91D. The attacker first conducted multiple attacking tests (as shown in the figure below):


In the third transaction (0xe49304cd3ed) after contracts deployment, the attacker made the first attack attempt:


At the beginning of the attack, there is a problem in the attacker’s initial transaction sending script, which results in that only the first attack in the block can succeed, and all subsequent transactions throw exceptions.

Later, the attacker made changes to the attack script, and only one attack transaction was sent in one block. First of all, by analyzing the three successful transactions, we can see that the attacker ‘s fund basically presents a double relationship, and the attack has begun to profit:

At that time, the attacker has completed the confirmation of the attack process, and the subsequent successive transactions are that the attacker has registered multiple token addresses for token exchange:

Taking ‘0xc906fc184c6f’ transaction as an example, ‘0x06af07097c9eeb7fd685c692751d5c66db49c215’ is the contracts address of token CHAI. The block height of 9899740 ~ 9899741 is basically all registered tokens.

After that, the attacker continues to attack. It can be seen that after each attack, the number of funds (imBTC) held by the attacker will almost double. Through this process of constantly doubling, when 0xced7ca81308 is traded, it has basically reached the maximum stock of imBTC.

Analysis of hacker attacking methods:

Take the transaction ‘0x111aef012df47efb97202d0a60780ec082125639936dcbd56b27551ce05c4214’ as an example:

Lendf.me contracts address: 0x0ee3e3828a45f7601d5f54bf49b01d1a9df5ea

ImBTC contracts address: 0x3212b29e33587a00fb1c83346f5dbfa69a458923


Step 1: Executing the supply function normally, and save 113.21475453 imBTC. No reentry is performed here.

Step 2: Adopting the supply function again and store in 0.00000001 imBTC. In this transaction, as in step 3, the attacker triggers the feature that the sender will be notified when using the transferFrom function to transfer tokens in the supply function. In the sender’s code, call back the withdraw function of Lendf.me and take out 113.21475453 stored in supply and 113.21475516 imBTC in the last reentry transaction, totaling 226.42950969 imBTC. After reentry, return to the remaining code of transferFrom again, and continue to transfer 0.00000001 imBTC into Lendf.me.

Suggestions for defense

1. Add lock mechanism to key business operation methods, such as OpenZeppelin and ReentrancyGuard

2. When developing a contract, we adopt the writing style of first changing the variables of the contracts, and then making external calls

3. Before the project goes online, the excellent third-party safety team should conduct a comprehensive safety audit to find potential safety problems as much as possible

4. When multiple contracts are connected, it is necessary to check the code security and business security of multiple contracts, and comprehensively consider the security issues under the combination of various business scenarios

5. The contract should be set the pause switch as much as possible to detect and stop the loss in time in case of “black swan” event

6. Security is dynamic, and each project party should timely capture threat intelligence that may be related to its own project, and timely check potential security risks