miner wrongly interprets JSON-RPC from pool and submits low-diff or invalid shares continuously

[aleqx]

Two full traces of the problem below. These are both pretty serious bugs. Note that they don't always manifest, but if you have many miners (or connect many times) then you will eventually hit them.

Tested on two pools https://pools.bloxstor.com and https://vrm.n3rd3d.com - both fairly big, both behaving the same.

EDIT: compiled from master (pulled yesterday).

problem #1

Debug protocol log: https://pastebin.com/jnPsU3Hz

This first one is from cold start. The miner gets confused because the pool sent mining.notify before replying to the mining.subscribe and drops the mining.notify message from the pool. This pool doesn't always do this -- it's asynchronous behavior.

This isn't invalid behavior from the pool. The miner should cache the mining.notify message and continue to wait for the reply to mining.subscribe which does eventually come. The pool may even send a mining.set_difficulty as well before replying to the mining.subscribe message. Again, the miner should cached this one too and continue to wait for the reply to mining.subscribe.

Here veriumMiner considers the message invalid and drops it, then subscribes again without any parameters (note the empty params for the second mining.subscribe) and then submits low difficulty shares continuously until eventually doesn't submit any more shares (i believe the diff factor it's setting gets too high and it can't get below the target until the next job from the pool).

problem #2

Debug protocol log: https://pastebin.com/TvQVYnvt

This one is more tricky. It happens when:

• the miner has been mining successfully
• the pool breaks connection
• the miner continues to retry every 10 seconds
• when the connection is re-established, the pool sets new difficulty
• the miner does NOT update the difficulty and uses the old difficulty value that it had before the disconnection
• all submitted shares are rejected

Another problem:

• the miner tries to resume the previous session (I think!) and sends a 2nd parameter in the mining.subscribe message.
• the pool ignores this, and replies with a different session
• the miner seems to correctly record the session id
• despite this, the miner seems to send shares using a different nonce space
• all submitted shares are rejected with ntime out of range

[phiten]

I don't know if its related to this but looking at my Pools Log Files i can see the following:

2018-03-06 11:33:02 [Pool] [verium] (Thread 17) Unknown stratum method from Username.Worker [::ffff:IP]: mining.extranonce.subscribe

This shows after a Pool Stratum restart.

[aleqx]

2018-03-06 11:33:02 [Pool] [verium] (Thread 17) Unknown stratum method from Username.Worker [::ffff:IP]: mining.extranonce.subscribe

Normally that's unrelated and also harmless. It's miners which support Nicehash extranonce who advertise it. Pools which don't support it either don't reply (and it times out) or reply with a "not supported" message.

[mooleshacat]

So does this all boil down to disabling NiceHash on the miners? Because if I recall correctly this is a switch or a question the miners ask during setup...

I have same issue with extranonce.subscribe