Python stratum-mining doesn't have an option to decide how it processes packets. It runs under twisted and all of the json code is handled by the stratum package that was written directly by slush himself.
If a miner can connect fine, and then nicehash puts something in between the miner and the pool that makes things stop working, it seems to me it's nicehash's problem and responsibility to fix this and if he needs to involve the pool owner he should be respectful and not try to shift blame by calling out the pool in public like he has. To my knowledge there is no contract between nicehash and ipominer and if nicehash does not give the user a choice in pools then they are responsible when things don't work.
I doubt the issue is inside slushs code, but must be related to recent addition of variable diffs by Ipominer.
I am sorrry, but it looks like you don't have full understanding of how our system works exactly. Did someone ask you to post in this thread? Because you started posting just yesterday.
All other pools except Ipominer works fine.
Cgminer/sgminer is not god. I will remind you of the bugs that we discovered - extranonce in cgminer 3.7.2 and idlebug was present in even most recent cgminer and sgminer. Guess with what was idlebug related? Networking! So, we simply cannot afford to take another publicly available code and say - this code is 100% reliable, we have to build on top of that. No, the only valid document we take are specifications (yes, these are poor) written by slush himself and found at various places around the internet.
I found a post by slush regarding a similar problem, but with regards to the pool rather than miner:
I have read the discussion about separating target/difficulty and work data. I have to say I think this was a mistake as it opens possibilities for abuse. I think something about these issues should go in the docs. Otherwise someone is going to create a naive implementation with some nasty issues.
Well, after discussion with Kano I slightly changed my mind. As I described few posts ago, with slightly modified meaning of "set difficulty" message, everything should be fixed.
Instead of meaning "stop sending lower difficulty shares than X immediately", set_difficulty should mean "all next jobs are using difficulty X". This still keeps the concept of separated difficulty message from the job itself, it doesn't require sending both messages together, fixes the problem of roundtrips (sending some bad-diff shares by the client because of latency) etc. It also gives the possibility to choose if pool wants to change difficulty in aggressive or in lazy way; by just sending "set difficulty" message without new job with clean_jobs=True, clients will slowly adopt higher difficulty as miners will start using new jobs, but pool can enforce higher difficulty with immediate effect by sending clean_jobs=True, as it is now.
This change in protocol is also backward compatible, because pools using current meaning of set_difficulty don't need to change anything, they just *may* stop sending clean_jobs job, if they want. Because of this, it is win-win solution for me. I described this already, but the idea didn't get any significant attention yet.
Is it ok to pipeline commands to the client? That is, send the difficulty change and new work (2 RPC calls) in quick succession without waiting for a reply to the first.
Yes, commands (notifications) can be pipelined. set_difficulty() and notify() don't expect any response from the client. Just sending one packet with both commands serialized is possible.
One interesting part is:
...set_difficulty should mean "all next jobs are using difficulty X".
Which, to me, means that the pool and miner should both be using the difficulty which was *sent most recently*. If this is the case, Ipominer has the issue.
...doesn't require sending both messages together...
Sure, this is talking about pool to miner, but the protocol is (from my understanding) supposed to be pretty similar from both the pool and miner's perspectives (aka "bi-directional" as per slush's specs). He says that sending both messages together isn't "required", which implies that it isn't "prohibited" either. If we can assume that it works the other way around (from miner to pool), then it seems that the pool should allow messages to be sent "together", because that is not specifically prohibited (unless I missed some part of the specification, which wouldn't be difficult to do). However, as has been mentioned, the
time that those particular bytes arrived shouldn't be used to parse them apart.
Slush says notification commands can be pipelined, and then qualifies that allowance by stating
set_difficulty() and notify() don't expect any response from the client.
However, the miner *can* expect a response from its subscribe request, so I think that same qualification doesn't apply in this situaton.
Then he says
Just sending one packet with both commands serialized is possible.
Again this was intended to be regarding the pool->miner direction, but if we can safely assume that the protocol is truly "bi-directional" then the same can be said about the miner->pool direction, as we are talking about here.
Therefore, it is still my conclusion that Ipominer is the one originally at fault and should fix their implementation to allow for multiple commands per packet. NiceHash seems to be using a method which is new, yet is not specifically prohibited, and therefore pools need to allow for it to occur.
This service abstracts the pool it's mining on away from the end user and out of the user's control, correct?
To my knowledge there is no contract between nicehash and ipominer and if nicehash does not give the user a choice in pools then they are responsible when things don't work.
There are two types of "users" on NiceHash - buyers and sellers. The sellers (miners) are the ones who don't know where their shares are being directed at. The buyers are the ones who do the directing. So in that sense, users (buyers) do have a choice in pools.
Now, Ipominer's site says it uses a "modified Proportional scoring system". If this system was paying out based on the higher difficulty (the same one that miners on NiceHash were using), then there shouldn't be a problem other than the aforementioned hashrate display issue. If instead, however, their system was basing share payout value on the lower diff, or not at all for those shares, then there's a problem. The solution would be to recalculate submitted share value and pay their users a compensation for the difference.
