If pools do not follow specifications, then make them follow. Usually after some time, they adopt.
Eh?
From
Stratum Mining Protocol official documentation (bold is marked by me):
Server Can Occasionally Ask Miner to Change Share Difficulty
Default share difficulty is 1 (big-endian target for difficulty 1 is 0x00000000ffff0000000000000000000000000000000000000000000000000000), but server can ask you anytime during the session to change it:
{ "id": null, "method": "mining.set_difficulty", "params": [2]}
This Means That Difficulty 2 Will Be Applied to Every Next Job Received From the Server.
Let's say a telnet to your pool:
[L0] {"id": 1, "method": "mining.subscribe", "params": []}
[L1] {"result": [[["mining.notify", "00097c41"]], "20a6a503", 8], "id": 1, "error": null}
[L2] {"params": ["55c69c0300006fdc", "a3b32fc515975727a8fe91857c6f4f71a4359df1117c96430000000000000000", ".....", "1814dd04", "55d20bf8", true], "method": "mining.notify", "id": null}
[L3] {"params": [1042], "method": "mining.set_difficulty", "id": null}
...
[L4] {"method": "mining.notify", "params": ["55c69c0300006ff6", "295d51c341c96d1d7690ec202fddef62841374930cb892270000000000000000", "....", "1814dd04", "55d20e33", true], "id": null}
L0: this is the client subscribe
L1: pool response for clien subscribe
L2: first mining.notify -> share difficulty calculates to 1 (default share difficulty based on stratum mining doc)
L3: change the difficulty to 1042 for
next job
L4: next mining.notify -> share difficulty sould calculate to 1042!
The cgminer has the "bug": apply the difficulty for current job: so L2 job has 1042 sharediff. this conflict with mining doc.
Solutions:
- fix the doc: "Applied to Every Next Job" -> "Applied to Every Current Job"
- fix cgminer (with the patch) and fix your pool: send the set_difficulty first and mining.notify next
