What are those reasons?

How would it work? Would it be a suggestion that the server can take under advisement and choose to ignore?

I had brought it up with Luke Jr. because I am mining at Eligius Diff 64 and I was having network problems. I'd be dropping to backup pool Diff 1 and then slowly climb to 64 with massive bandwidth usage in the meantime and then a while later I'd be back at Eligius at Diff 1 again with massive bandwidth usage while it made its way back to Diff 64 again. Back and forth with 168GH I was seeing the drawback to having to wait for the pool to figure out my Difficulty and I asked Luke Jr. if I could just set it myself.

Luke Jr. explained thats not possible with Stratum at this time. I have 10TH on order. If I had that hashrate at this time and I was dropping to and from backup pools it  appears I would have a major problem and it would appear the pool would too.

Am I mistaken?

Basically the idea is that miner remember the last difficulty given by the previous mining session and it sends mining.suggest_difficulty(difficulty) on the beginning of the next session (it may be sent before mining.subscribe or mining.resume, but it should not be a requirement). The response to the call is irrelevant for the miner, but if the pool accept the suggestion in any way, it will send standard mining.set_difficulty with new computed difficulty.

Obviously the difficulty can differ from pool to pool while switching between backup pools, because every pool can have different SPM target . The main goal is to give at least some approximation for the newly connected pool, so it won't start with difficulty 1 for 10 THash/s monster rig...

This is one of possible solutions. Unfortunately many users use one worker accross all miners, because they were lazy to set up unique worker per miner...

No, except that slow devices using the same worker name as fast ones will have huge difficulty and it will take some time to settle on natural level.

That is certainly one way a pool can handle it, and one way I've been considering for BTC Guild.  However, I think simple minimum difficulty settings available through the frontend solve problems for large workers.  And at least with my implementation, the pool will adjust very high speed workers to an appropriate difficulty before bandwidth becomes an issue.  They'll see a spike at the very start, but with aggressive difficulty adjustments you can prevent it from being enough to saturate even on a very slow connection (3g/dial-up).



Stratum by definition is per-connection difficulty.  gigavps's suggestion would only affect pools which try to remember/re-instate difficulty on a after worker authorization.

Ok, I can easily implement this.

Moving back to the resume support, since mining.resume breaks your proxy when implemented pool-side with the current format, and there will be lots of miners still using your proxy and this makes the pools not interested in supporting the feature, can I suggest a modification to a use of the mining.subscribe response?

SEND: {"id": 0, "method": "mining.subscribe", "params": []}
RECV: {"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f8019658", 4]}

Is it possible to use the existing unique subscription ID as the session ID with mining.resume instead? I know some pools use this for different reasons, so I'm not sure if that's possible, but just a suggestion. Alternatively, can you put the session ID somewhere else in the JSON response that does NOT break your proxy? While I have committed the changes to cgminer git with the existing format, there are no users currently depending on that format so we can and should change it.

...and I'll also fix proxy to ignore any unknown parameters in subscribe notification. It wasn't intentional, I'm sorry for such kind of issue :-/.

Pool should not close the connection on unknown message. Like this:


Server should close connection only when the payload is corrupted (thus there's no way to identify messages and respond with standard error).

Why there should be any exception for first message?

If the miner knows any recent session id, it should send mining.resume(id) firstly. If miner don't have any session id, it should send mining.subscribe(). When the pool doesn't understand mining.resume message, it should respond with standard error, not by closing the connection.

Is there really any pool which closes the connection on unknown message?