store the next difficulty

[bitbandi]

Miner should use diff set with set_difficulty for every NEXT job. Correct?

Looks like cgminer 4.9.0 uses new diff before next job arrives. Here is an example of network output that we have gathered.

[06/17/2015 18:21:03] - Received from pool: {"id":null,"method":"mining.set_extranonce","params":["fb91949075", 7]}
[06/17/2015 18:21:03] - Sending to miner: {"id":null,"method":"mining.set_extranonce","params":["fb91949075", 7]}
...
*[06/17/2015 18:22:33] - Received from pool: {"id":null,"method":"mining.set_difficulty","params":[4096]}
*[06/17/2015 18:22:33] - Sending to miner: {"id":null,"method":"mining.set_difficulty","params":[4096]}
...
[06/17/2015 18:24:10] - Received from pool: {"params":["00000000052f1486", "4ef4a7b5534a292cb1756abf6a08f2bb933abec406235c640000000000000000", .... , "00000003", "18162043", "55820197", false],"id":null,"method":"mining.notify"}
[06/17/2015 18:24:10] - Sending to miner: {"params":["00000000052f1486", "4ef4a7b5534a292cb1756abf6a08f2bb933abec406235c640000000000000000", .... , "00000003", "18162043", "55820197", false],"id":null,"method":"mining.notify"}
...
[06/17/2015 18:24:19] - Received from miner: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "19e30300000000", "55820197", "4e51cf38"], "id": 1318, "method": "mining.submit"}
[06/17/2015 18:24:19] - Sending to pool: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "19e30300000000", "55820197", "4e51cf38"], "id": 1318, "method": "mining.submit"}
[06/17/2015 18:24:19] - Received from pool: {"id":1318,"result":true,"error":null}
[06/17/2015 18:24:19] - Sending to miner: {"id":1318,"result":true,"error":null}
[06/17/2015 18:24:23] - Received from miner: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "fff70300000000", "55820197", "ac350e99"], "id": 1319, "method": "mining.submit"}
[06/17/2015 18:24:23] - Sending to pool: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "fff70300000000", "55820197", "ac350e99"], "id": 1319, "method": "mining.submit"}
[06/17/2015 18:24:23] - Received from pool: {"id":1319,"result":true,"error":null}
[06/17/2015 18:24:23] - Sending to miner: {"id":1319,"result":true,"error":null}
*[06/17/2015 18:24:23] - Received from pool: {"id":null,"method":"mining.set_difficulty","params":[2048]}
*[06/17/2015 18:24:23] - Sending to miner: {"id":null,"method":"mining.set_difficulty","params":[2048]}
[06/17/2015 18:24:25] - Received from miner: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "42050400000000", "55820197", "66fde833"], "id": 1320, "method": "mining.submit"}
[06/17/2015 18:24:25] - Sending to pool: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "42050400000000", "55820197", "66fde833"], "id": 1320, "method": "mining.submit"}
[06/17/2015 18:24:25] - Received from pool: {"id":1320,"result":true,"error":null}
[06/17/2015 18:24:25] - Sending to miner: {"id":1320,"result":true,"error":null}
[06/17/2015 18:24:27] - Received from miner: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "7a0d0400000000", "55820197", "b1324660"], "id": 1321, "method": "mining.submit"}
[06/17/2015 18:24:27] - Sending to pool: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "7a0d0400000000", "55820197", "b1324660"], "id": 1321, "method": "mining.submit"}
[06/17/2015 18:24:27] - Received from pool: {"id":1321,"result":true,"error":null}
[06/17/2015 18:24:27] - Sending to miner: {"id":1321,"result":true,"error":null}
[06/17/2015 18:24:35] - Received from miner: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "81350400000000", "55820197", "82297242"], "id": 1322, "method": "mining.submit"}
[06/17/2015 18:24:35] - Sending to pool: {"params": ["1DSnPFz1xoHgNSJa1P995Yp9kYL23TXH66.S5203", "00000000052f1486", "81350400000000", "55820197", "82297242"], "id": 1322, "method": "mining.submit"}
*[06/17/2015 18:24:35] - Received from pool: {"id":1322,"result":false,"error":[23, "Share above target.", null]}
*[06/17/2015 18:24:35] - Sending to miner: {"id":1322,"result":false,"error":[23, "Share above target.", null]}

The last share marked in bold has difficulty of 3798, which is higher than 2048 (latest reported diff), but lower than 4096 (diff of job '00000000052f1486'). As a result, such share is discarded by the pool with reason share above target, because diff of job '00000000052f1486' is 4096 and not 2048.

This problem is not critical in scenario above, because it does not reduce miners hashrate, but if the vice verse happens (change from low to high diff), miner may miss to send some shares which results in slightly reduced hashrate on pool side.

This commit fixes this issue, please review it.

[kanoi]

Alert - this change causes a dump of 1 diff shares to the pool when you first connect.
Proper BTC testing should have been done on this code change by the author.
I've reverted it.
Please submit a pull without this problem.

[bitbandi]

@kanoi heh? the original ckolivas code set too the sdiff to 1 until a mining.set_difficulty received. And mining is started by a mining_notify, and the share diff is set at that time (to 1 or value from set_difficulty).

Can you give me a situation sequence when my code behaves differently as ckolivas code?

[kanoi]

I reverted just this change and the problem goes away.
It's obvious due to the large number of 1 diff shares rejected when you first connect to any pool - but only with this change.
If you actually just ran the code with and without this change you would have seen that.
The issue is that even though the pool changes diff just after connect and sent a diff increase above 1 diff, your change means the 1 diff shares are sent.

[bitbandi]

A workaround for your pool:
bitbandi@9f9bde5

[ckolivas]

That looks about right. Did you wish to reopen a pull request for it with that fix?