Open aleqx opened 6 years ago
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.
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.
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
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 themining.subscribe
and drops themining.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 tomining.subscribe
which does eventually come. The pool may even send amining.set_difficulty
as well before replying to themining.subscribe
message. Again, the miner should cached this one too and continue to wait for the reply tomining.subscribe
.Here veriumMiner considers the message invalid and drops it, then subscribes again without any parameters (note the empty
params
for the secondmining.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:
Another problem:
mining.subscribe
message.ntime out of range