I found a post by slush regarding a similar problem, but with regards to the pool rather than miner:


One interesting part is:
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.

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
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
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.

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.

So in summary, let me see if I understand correctly:

ipominer used code that works with existing mining software and called it good. Since it worked with 100% of clients 100% of the time, there was no reason to do further testing, right? From my understanding, there's really only a small handful of different mining software out there. Sure there are many versions of sgminer, but the original neworking code is probably all the same from the first version (no, I didn't check this myself - that's just a guess). It just so happened that (nearly?) all software out there sends the initial subscribe and authorize requests in the same way - probably ending up in two separate packets.

nicehashdev used an implementation that was slightly different than most (all?) pre-existing miner applications. Instead of those initial subscribe/authorize requests being sent over the wire in two packets, they were sent in a single packet (as is the case in that C# example). I know nicehashdev said they use separate sends, but it seems whatever they're doing ends up combining messages as in the example. In any case it doesn't really matter, and I'll focus on the example given.

nicehashdev is correct that networking communications data must be treated as a stream and not as individual packets. Data could be split/combined in ways you can't control over the internet - there's no guarantee that data will arrive in the same 'chunks' they were sent. There IS a guarantee, however, that the bytes arrive in the same order as they were sent (this was mentioned earlier).

I tried out nicehashdev's C# example (both subscribe & authorize sent in a single packet) and sure enough the response received was the low diff, then the high diff (received all in a single packet  ). However, splitting the initial subscribe/authorize Send() into two different sends (no pause in-between) resulted in a response with the high diff, then the low diff. Exactly the same data was sent, but splitting the data into two send events (and therefore packets) resulted in the 'proper' response.

I've dealt with this kind of problem before in my own experience with network coding. The issue is always in how I read the data - not how it was sent. I always have to remind myself that the receiving end needs to treat the incoming bytes as a stream - never as a 'packet'.

Therefore it is my conclusion that nicehashdev is correct and that ipominer's implementation does not correctly parse the received data. This also explains why other pools don't have this issue with NiceHash.

The situation isn't helped by the fact that the stratum protocol documentation is kinda poorly organized. Seems like programmers are sort of forced to test their code by comparing it to how other preexisting implementations handle things, rather than coding according to the documentation (hard to do since it's seemingly spread out in an unorganized fashion). Frankly I'm surprised these sorts of problems don't pop up more often.

Did anyone else notice that in the Windows Binaries ZIP (Windows 1.3 avx-aes: http://download.darkcoin.fr/darkCoin-cpuminer-1.3-avx-aes-windows-binaries.zip) both
minerd-core-avx-i.exe and minerd-corei7-avx.exe are exactly the same files? A checksum comparison gives the same result. I'm trying to write a little setup script for my buddies to set up the miner on their computers and noticed this.

phzi -

Maybe I'm misunderstanding your posts, but it seems you think network switches forward packets to all physical ports? I think you mean "hubs". Google "switch vs hub" and you'll see what I mean.