Please follow stratum spec

[sammy007]

Protocol Flow

Client sends mining.subscribe to set up the session. Server replies with the session information. Client sends mining.authorize for their worker(s). Server replies with the result of authorization. Server sends mining.set_target. Server sends mining.notify with a new job. Client mines on that job. Client sends mining.submit for each solution found. Server replies with whether the solution was accepted. Server sends mining.notify again when there is a new job.

https://github.com/str4d/zips/blob/77-zip-stratum/drafts/str4d-stratum/draft1.rst

@Genoil your miner sends 2nd subscribe regardless received it job after first auth or no, my software works correctly and pushing target followed by new job immediately after authorization request, but your miner still ignores it and only hashing after new job appears on pool and new notification sent because for miner it will be a job after subscribe.

  {"id": 1, "method": "mining.subscribe", "params": ["xxx.xxx",5555, "genoil+tromp/0.1", "NULL"]}.
##
  {"id":1,"result":[null,"00000000000000000000000003e63fe4"],"error":null}.
##
  {"id": 3, "method": "mining.authorize", "params": ["z","z"]}.
#
  {"id":3,"result":true,"error":null}.
#
  {"id":null,"method":"mining.set_target","params":["7ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0"]}.
#
  {"id":null,"method":"mining.notify","params":["523333875480617","04000000","219e2bfc7b803f691815d242f3e026ddf93f853a8ff648f62f17af8304000000","c3d7e26bcf8159f42ccfba9cc34144459bda45095c747e31a9989fffaf27398a","00000000000
  00000000000000000000000000000000000000000000000000000","e6b51558","cba30b1d",true]}.
#
  ......
#
  {"id": 1, "method": "mining.subscribe", "params": ["xxx.xxx",5555, "genoil+tromp/0.1", "NULL"]}.
#
  {"id":1,"result":[null,"00000000000000000000000003e63fe5"],"error":null}.

So simply your miner work with both broken stratums and does not work with correct.

Solution is simple, wait for nonce on subscribe reply and wait for target and job after authorize.

[the-Arioch]

How long should one wait "after authorize" before giving up. How long should it take to safely tell 100%-correct servers working in 100% reliable network from a situation when the job failed to be sent or transmitted, so the error recovery should be started?

[sammy007]

Last version (5.0) pushing bad shares before new block appears on a network and server sends notify.

[d57heinz]

I can confirm this behavior. Not every start either just once in while when I restart my rigs it throws bad share null 20 I believe was error but it does not fix until next block. BR

[sammy007]

@Genoil I believe the simple solution is to check if miner received target and job after mining.authorize before sending second immediate mining.subscribe request.

[the-Arioch]

to check if miner received target and job after mining.authorize

actually - to WAIT for those for a second or two (because you cannot check by other means than waiting, can you?)

That exactly what I proposed in the original thread....

[sammy007]

@the-Arioch I am not interested in your bs please never reply to me.

@Genoil could you publish stratum sources, I am not asking about whole miner. Or at least reply if you are going to fix it or not so I will not waste time with assumptions that it will be ever fixed.

[sammy007]

6.0

14:43:38 pool : Connected!
14:43:38 pool : subscribed
14:43:38 pool : authorized worker X
14:43:38 pool : received new target: 0x01ffffffffffff...

!!! stratum sent `mining.notify` right after `mining.set_target` so miner ignored this message.

14:43:38 pool : subscribed
14:43:38 pool : already authorized <- So wh
14:43:43 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:43:48 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:43:53 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:43:58 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:44:03 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:44:08 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:44:13 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:44:18 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:44:23 main : zec-sa#0: 0.0S/s        total: 0.0S/s
14:44:25 pool : received new job #287844447219123

!!! Bingo, miner recognized `mining.notify` when pool sent it after new block mined in network.

14:44:26 gpu#0: submitting solution
14:44:26 pool : submitted and accepted

Still hoping it will behave correctly in next version.