Ethereum Classic reached 385 epoch: Problems and Solving

hiveon · November 7, 2020, 5:07pm

The time has come

Yesterday, November 6, a significant event took place on the Ethereum Classic network — the 385 epoch came.

What is the significance of this event? With the onset of the 385 epoch, a number of problems were discovered that apply equally to both the Ethereum Classic network and the possible problems with the main mining coin — Ethereum.

Problems

First, DAG file size exceeded 4GB and some miners stopped working, for example the legendary Claymore ETH Dual Miner, the latest version of which v15.0 - was released back in August 2019.
Most miners have fixed the problem of working with a DAG file larger than 4 GB, you just need to update and use the latest version. Otherwise, miners may either not work at all, or send incorrect shares to the pool, and your worker will most likely be banned by the pool.

Secondly, the problem was found in the code of the Ethash Lib library, so the error is reproducible for both Ethereum Classic and Ethereum, and it can appear in many scenarios, and cause instability of the entire network as a whole.
You can read more about this in this article by our colleagues from 2miners.com.

Solving

To keep your Ethereum Classic mining workers running smoothly, update Hive OS and use the latest versions of miners. We remind you that if you exceed the 5% barrier of incorrect shares on the Hiveon ETC pool, your worker will be banned.

So, in order to avoid a ban on the pool due to invalid shares, which were produced by the version of the miner that does not work correctly with a DAG file of more than 4GB or the loss of money due to the idle worker due to non-working, miners need:

If you use Claymore for mining ETC you should switch to another miner (see below miner testing for compatibility)
If you use PhoenixMiner with AMD Navi change it to TeamRedMiner or lolMiner
If you use another miner than update your miner to latest

Globally, we removed Claymore ETH Dual miner from the list of recommended miners for our Hiveon pool, and the pools with which we cooperate did the same.

Miners testing for compatibility with 385+ epoch

We tested ethash miners for AMD (tested on OpenCL versions 19.20, 19.30 and 20.30) and Nvidia (v455.38) for compatibility with the 385+ epoch.
We share the results with you:

AMD

Status	Miner	Notices
	Claymore v15.0	miner stops working with the “Pool sent wrong data, cannot set epoch, disconnect” error
	EthMiner v0.19.0.1+nhfix	performance on Vega and Navi family isn’t optimal
	Bminer v16.3.4	miner is not working with DAG >4GB even on drivers v20.30
	lolMiner 1.12	supports the “Zombie” mode
	PhoenixMiner v5.1c	incorrect shares on the Navi family are possible
	TeamRedMiner v0.7.17	supports the “Zombie” mode
	NBMiner v33.3
	NanoMiner 1.13.0	supports the “Zombie” mode
	SRBMiner v0.5.5

NVIDIA

Status	Miner	Notices
	Claymore v15.0	miner stops working with the “Pool sent wrong data, cannot set epoch, disconnect” error
	EthMiner v0.19.0.1+nhfix
	Bminer v16.3.4	doesn’t support RTX 30xx
	lolMiner 1.12	supports the “Zombie” mode
	PhoenixMiner v5.1c
	T-Rex v0.18.6	the problem in the latest version was fixed, supports the “Zombie” mode
	NBMiner v33.3
	NanoMiner 1.13.0	supports the “Zombie” mode
	GMiner v2.29
	TT-Miner v6.0.0

Cryptokurti · November 8, 2020, 4:00pm

hi, i realized a lot of rejected shares on ethermine with phoenix miner. Than I switched to hiveon pool and they where gone. Now I am back on ethermine and have no rejected shares at all with phoenix miner. When I use Teamredminer, I have less hashrate (from 57 to 55,5) (AMD RX5700XT Cards) So Teamred seems less efficient. Do you think I can use Phoenix in the future or will I get problems?

HaloGenius · November 8, 2020, 5:12pm

Yes that’s right. There was such an error on the ethermine pool (it is related to an error in the library code, which is mentioned in the article). They quickly eliminated it.

I think this is a topic for a separate article.
Because the numbers that the miner shows you and which are considered a pool, they are completely different and not in favor of PhoenixMiner.

carlos213 · November 9, 2020, 9:01pm

i got ban what to do …i was not watching my miner

hiveon · November 9, 2020, 9:18pm

From “Hive OS Announcements” Telegram Channel

HIVEON ETC POOL NEWS

Pool protocol changes
Hiveon ETC servers now support eth-proxy only. Сheck your miner settings.

Update your miners
Ethereum Сlassic reached the 385 epoch and we wrote about the problems associated with it here (Ethereum Classic reached 385 epoch: Problems and Solving).

To avoid a potential ban on the pool due to exceeding the 5% threshold of incorrect shares please ensure the following:
If you are using Claymore ETH miner, you should switch to another miner
If you are using a different miner, make sure to update it and use the latest version.
The ban is removed by contacting technical support or automatically after 6 hours. Please update your miners to avoid a halt in your mining and profits.

Contact technical support in one of the following ways:

Hive Live support from your account or Hive web portal (message icon on right bottom)
Telegram Pool support channel
e-mail to address bee@hiveos.farm

FreemanMaudib · November 9, 2020, 11:26pm

I’m running teamredminer and I upgrade every time there’s a new hiveos version.
That being said, I still had serious glitches this weekend that seem to only go away when I switched mirror sites and servers. Maybe I can go back to defaults now?

Folca · November 10, 2020, 5:56am

So I ran into the invalid share issue with ETC Saturday with PhoenixMiner 5.1c. These invalids would show up on my end as invalid.

Switched to teamredminer no issues. On Sunday, phoenixminer 5.2a issue fixed until today. After about 24 hours of mining on the na-etc server, I started seeing invalid shares being reported by Hiveon and not my miner. Again switched to teamredminer and went away. I tried Phoenixminer again with 5.2B, but no luck. However, if I switch to the EU server, then Phoenix works fine. It is only malfunctioning on the NA server.

In the logs I started seeing this when a share was found.
2020.11.09:17:38:34.272: eths Eth: Received: {“id”:9,“jsonrpc”:“2.0”,“result”:null,“error”:{“code”:23,“message”:“Low difficulty or invalid share”}}

Before the errors started I got this message,
2020.11.09:17:37:52.041: eths Eth: Received: {“id”:4,“jsonrpc”:“2.0”,“result”:true}

There was some message I found on the miner screen saying disconnected or some other connectivity issue with the server, so I restarted and looked like it was working on the miner screen, shares found, telling me the difficulty just no acceptance message. but I I move from NA to EU server, no issue.

I could troubleshoot much more on the NA server as my invalid had gotten up to 4.9%, but I did try another etc pool to see if I had issue - Works fine on ethermine.org/works fine on eth with hiveon, and no issue on nicehash - just NA-etc seems to be the issue with me.

So i’ll be using the EU server even though it has more risk of stales as I in the States and latency is about 125 ms vs the 60-80 ms I would get on the NA server.

Anyone else ever have anything similar? Or happen to know how to fix?

HaloGenius · November 10, 2020, 7:39am

Contact support. Seems you was banned by NA server

mansey · November 10, 2020, 1:47pm

Hi HeloGenius,
did you do anything? I had a hell of Stale Shares this morning and get the warning from the Pool. I start changing OV settings and miners. A bit later i go back to my old settings (Phoenix Miner) and everything was fine. Indeed my hasrrate at the pool is better than before. So thanks what ever you did.

111155 · November 10, 2020, 4:48pm

можно батник на класик Teamredminer и куда его вбивать .там токо ефир батники. или я непойму

HaloGenius · November 10, 2020, 9:18pm

Для Windows ?

CryptoMining · November 18, 2020, 1:02pm

Phoenix just released Update to 5.2d with driver compatibility up to AMD driver 20.40. Could you pls add this new miner to HiveOS? Thx

Gustavo_Barcenas · November 23, 2020, 4:58pm

hola, actualmente estoy presentando este problema

=== Last 50 lines of /var/log/miner/claymore/lastrun_reboot.log ===
12:38:13:366 3effd700 ETH: GPU0 0.000 Mh/s, GPU1 0.000 Mh/s, GPU2 0.000 Mh/s, GPU3 0.000 Mh/s, GPU4 0.000 Mh/s, GPU5 0.000 Mh/s
12:38:16:095 3effd700 buf: {“id”:null,“method”:“mining.notify”,“params”:[“2f01”,“0x89E8416eA5b69863CCb34D3A5C74A86bf5549147137698a1d2fa5f20af4508be”,“0x89E8416eA5b69863CCb34D3A5C74A86bf5549147fe542d50748cfe7c2098fabb”,“0x89E8416eA5b69863CCb34D3A5C74A86bf5549147fffffe00000007ffffffe000”,true]}

HaloGenius · November 24, 2020, 12:12am

Claymore now dead as for ETH and as for ETC.
Change miner!

BobDodds · November 26, 2020, 12:15am

I tried to update TeamRedMiner by sudo hpkg update ; sudo hpkg install miners teamredminer. It stayed with 0.7.17 but repository has 0.7.18 which has the etchash updates for the November 29, 2020, epoch change. I used :
sudo apt install hive-miners-teamredminer-0.7.18

Find the latest TRM in hiveOS repo, compare to github TRM:
sed -n -E '/teamred.*[-_]0\.7\.1.*\.deb$/s/^.*\///p' /var/lib/apt/lists/download.hiveos.farm_repo_binary_Packages | sort

Best options to use for November 29 changeover:
–eth_variant_mode=pool or --eth_variant_mode=deduce or --eth_variant_mode=auto
and later:
-a etchash

USAGE.txt
–eth_variant_mode=X This argument controls activation of the ethash changes for ETC from epoch 390 as described
in ecip-1099. The following modes are available:
pool - Default mode. Only activates if the pool sends an algo flag containing etchash.
Once this flag is seen, all pool jobs will be assumed to be etchash unless another.
algo flag containing ethash is received.
etchash - Etchash mode. Epoch >= 390 will be assumed to be etchash, lower epochs ethash. Pool
algo flags are not used.
deduce - Ignore pool algo flags and only apply a heuristics based on the current system time
and known heights and times for ETC and ETH. This mode should work as a generic
approach when ETH reaches epoch 390 in Jan 2021. The system clock needs to be correct.
It should also handle any profit switching setups that switch freely between ethash and
etchash jobs by proxying underlying pools.
auto - As long as the pool hasn’t passed an algo flag, use deduce mode. When an algo flag
is seen, switch to pool mode.
ethash - Forced ethash mode. Never apply ecip-1099.
force_etc - Forced etchash mode. Always apply ecip-1099 rules. Use for ETC testnet mining.

HaloGenius · May 30, 2021, 4:15am

This topic was automatically closed 185 days after the last reply. New replies are no longer allowed.