Contents
As you may know, Ethereum Classic is preparing to undergo a fork that will activate the ECIP-1099 proposal. In short words, this was the team’s decision to cut down the amount of hashing power on the network to prevent attacks using NiceHash and to reduce the number of ASICs mining on the network. In the meantime, the Ethereum Classic has switched to epoch 385 last night.
After the activation of the new epoch, we have noticed a much increased invalid share rate coming for ETC from our miners. This means, the miner software finds a valid solution but the pool rejects it and thinks it is not valid. The DAG file used to verify solutions has grown over 4 Gigabytes for the first time, which gave us a clue where the problem may lie.
Ethash Lib Problem Explained
Let’s step back for a second and remind some of the basic computer science concepts to you so it’s easier to grasp the source of the issue. Any number processed on a computer is stored in so-called variables, that are constrained to a particular number of bits. The more bits the variable size is, the larger number it may hold. If the variable is signed (as in, it can go from negative to positive numbers), it can hold an equal range of negative and positive values; if it is unsigned, it can hold only positive numbers but in a greater range. For example, as we all remember from basic CS, an 8-bit value can contain at most 256 values, ranging 0…255 for unsigned variables (yes, zero is considered a valid distinct value too) and -127…127 for the signed ones. For 16 bits the range increases to 65536 (2^16), for 32 bits — 2^32 equalling about 4 billion values, and so on.
With thorough investigation, we have discovered that the math in one of the core libraries used in many Ethash-based cryptocurrencies is a little off: in the solution validity calculation values of 32 bits were used instead of 64 bits, thus failing the checks on the newly grown DAG file in the ETC. Moreover, the routine that was 32-bit is multi-threaded and the calculation breaks depending on the number of threads available on the host machine, which means some nodes of the same version could fail the verification and reject some new blocks, while other nodes may accept it, potentially inducing increased network instability due to a flawed consensus.
2Miners Pull Requests to Fix the Network
We have identified the problem and patched our pool software, so you could mine ETC on 2Miners without any rejected shares shares now.
PPLNS: etc.2miners.l1q3urman.workers.dev
SOLO: solo-etc.2miners.l1q3urman.workers.dev
We have also submitted a pull request for the core Ethereum library that fixes the issue — here and here. But this also means the currently running ETC network is still not functioning correctly and is rejecting valid blocks because of the overflow problem. This already leads to the increased invalid block rate and could potentially lead to network splits. 2Miners remain in close contact with the developers we could reach in attempts to propagate the fix.
Our pools are already patched and are accepting all shares correctly. Let’s hope for a fast turnaround time for the core ETC devs… as another hard fork may be in order.
Remember to follow us on Twitter to get all the news as soon as possible.
