[ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool

[nicehashdev]

No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.

Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.

[1714937734]

1714937734

[1714937734]

1714937734

[1714937734]

1714937734

[1714937734]

1714937734

[ipominer]

No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.

Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.

At the end of the day, the key point to note is that the person developing their own custom proxy software to connect to existing pool stratums is the one that needs to take care in their implementation. As we've already discussed, every other mining software implementation works properly - you need to fix your connection code. Use your own sgminer codebase as an example of proper behavior.

[flound1129]

All I will leave here is proof what happened when NiceHash connected to Ipominer.

{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}

As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances.

EDIT: Using past tense, because we applied temporary fix to get rid of this case.

In fact, this problem can *only* happen if the proxy is reversing the order.

Sending low then high would not be a problem for miners.  The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue.  Then it would start submitting higher difficulty shares.

In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level.  This can *only* happen if the proxy is reversing the order.

[nicehashdev]

All I will leave here is proof what happened when NiceHash connected to Ipominer.

{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}

As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances.

EDIT: Using past tense, because we applied temporary fix to get rid of this case.

In fact, this problem can *only* happen if the proxy is reversing the order.

Sending low then high would not be a problem for miners.  The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue.  Then it would start submitting higher difficulty shares.

In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level.  This can *only* happen if the proxy is reversing the order.

Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool.

[flound1129]

All I will leave here is proof what happened when NiceHash connected to Ipominer.

{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}

As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances.

EDIT: Using past tense, because we applied temporary fix to get rid of this case.

In fact, this problem can *only* happen if the proxy is reversing the order.

Sending low then high would not be a problem for miners.  The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue.  Then it would start submitting higher difficulty shares.

In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level.  This can *only* happen if the proxy is reversing the order.

Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool.

Yes, and the only way this can happen is if the pool and the miner are confused about which is the current difficulty.  And the only way that can happen is if the order of the set_difficulty commands is being changed by the proxy.

[tylerderden]

No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.

Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.

At the end of the day, the key point to note is that the person developing their own custom proxy software to connect to existing pool stratums is the one that needs to take care in their implementation. As we've already discussed, every other mining software implementation works properly - you need to fix your connection code. Use your own sgminer codebase as an example of proper behavior.

YES please fix this shit, cost me a chunk of btc yesterday and last week. I spend quite a bit on nicehash and wont be back until this shit is sorted.

[nicehashdev]

All I will leave here is proof what happened when NiceHash connected to Ipominer.

{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}

As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances.

EDIT: Using past tense, because we applied temporary fix to get rid of this case.

In fact, this problem can *only* happen if the proxy is reversing the order.

Sending low then high would not be a problem for miners.  The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue.  Then it would start submitting higher difficulty shares.

In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level.  This can *only* happen if the proxy is reversing the order.

Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool.

Yes, and the only way this can happen is if the pool and the miner are confused about which is the current difficulty.  And the only way that can happen is if the order of the set_difficulty commands is being changed by the proxy.

How could it be? This is what we got from Ipominer - in order as I posted. And you will get same order with the short example program I posted, if you don't believe me (unless they fixed it by now).

[atomicchaos]

As a neutral party, I must say it would be wise to rethink the strategy of not supporting your customers or miners without taking blame for anything that goes wrong. I am not saying that any of these things are completely your fault, but I can say that reputation is everything on a long term basis, and if these types of things continue, along with not taking any ownership for the customer or miner issues, you won't be around for long.

I've started to switch my rigs over to nicehash, and I'm a little concerned now with all I'm reading, along with the responses to all of the issues I'm seeing.

What I am impressed by is the innovation you've brought to mining, and that was enough to give it a test spin, with my cautiously optimistic outlook.

The issue with the difficulty could have more professionally been resolved by stating that through the assistance of IPOminer, an issue was found and you resolved it by changing code on your side, and apologizing for any issues. We all know things happen, and understand that glitches need to be worked out, but trying to pass sole blame, and not taking at least partial blame is really poor customer service.

[flound1129]

All I will leave here is proof what happened when NiceHash connected to Ipominer.

{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}

As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances.

EDIT: Using past tense, because we applied temporary fix to get rid of this case.

In fact, this problem can *only* happen if the proxy is reversing the order.

Sending low then high would not be a problem for miners.  The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue.  Then it would start submitting higher difficulty shares.

In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level.  This can *only* happen if the proxy is reversing the order.

Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool.

Yes, and the only way this can happen is if the pool and the miner are confused about which is the current difficulty.  And the only way that can happen is if the order of the set_difficulty commands is being changed by the proxy.

How could it be? This is what we got from Ipominer - in order as I posted. And you will get same order with the short example program I posted, if you don't believe me (unless they fixed it by now).

That obviously isn't the case, since the only way for the situation to happen in the first place is if the order is getting reversed by the proxy.  The pool remembers the last difficulty set and credits shares based on that.

[nicehashdev]

As a neutral party, I must say it would be wise to rethink the strategy of not supporting your customers or miners without taking blame for anything that goes wrong. I am not saying that any of these things are completely your fault, but I can say that reputation is everything on a long term basis, and if these types of things continue, along with not taking any ownership for the customer or miner issues, you won't be around for long.

I've started to switch my rigs over to nicehash, and I'm a little concerned now with all I'm reading, along with the responses to all of the issues I'm seeing.

What I am impressed by is the innovation you've brought to mining, and that was enough to give it a test spin, with my cautiously optimistic outlook.

The issue with the difficulty could have more professionally been resolved by stating that through the assistance of IPOminer, an issue was found and you resolved it by changing code on your side, and apologizing for any issues. We all know things happen, and understand that glitches need to be worked out, but trying to pass sole blame, and not taking at least partial blame is really poor customer service.

All issues caused by us were refunded. All customers were compensated for orders that didn't appear due to errors caused by us. There were times, when miners were not paid, because generated transaction was too large. We fixed that too and compensated all miners, working hardly to manually send the transaction and making sure it doesn't happen in future anymore. We took responsibility for all these issues, fixed them and compensated them.

But we cannot compensate for errors caused by other services. We were not even aware of the issue until recently, when we gathered enough information. Not a single customer that complained provided enough details that we could figure it out what is going on. All worked fine on us, all our large buyers that use own custom pools said that everything is working fine. We were under impression that everything is working fine. First one to actually report more details about the issue was Ipominer himself. And thanks to him for that.

We do care of our customers, that is why we quickly applied temporary (and NOT permanent, because that is up to remote pool) fix so that Ipominer works with NiceHash now.

As a miner, you should not be worried about it as long as you use backup pools. Yes, we are constantly targeted by DDOS attacks. We moved our servers to much better location and we are doing various improvements to strengthen our system. The attackers are very clever and we suspect that there is personal vendetta going on against NiceHash (due to reasons I will not disclose to the public, because that is not your concern). We are also targeted by blackmailers and extortionists.

[nicehashdev]

All I will leave here is proof what happened when NiceHash connected to Ipominer.

{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800539c", 4]}
{"params": [0.032768], "id": null, "method": "mining.set_difficulty"}
{"error": null, "id": 1, "result": true}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"params": ["9a12", "0ba33752363c1a2ebf6c2304a0a0b9c54397b3db081e297a0013b53e00000000", "0100000027b5c253010000000000000000000000000000000000000000000000000000000000000 000ffffffff1f0245050435b5c25308", "0d2f7374726174756d506f6f6c2f000000000100203d88792d000023210305f73d52e4778d2a584 727c5cad357d544151df9addb44ca41fd668fec9dfe44ac00000000", [], "00000006", "1b23ab19", "53c2b527", true], "id": null, "method": "mining.notify"}

As you can see, Ipominer first sends low diff, then high. Claiming that other software works fine is pointless here. Your stratum should NOT do what it did, under any circumstances.

EDIT: Using past tense, because we applied temporary fix to get rid of this case.

In fact, this problem can *only* happen if the proxy is reversing the order.

Sending low then high would not be a problem for miners.  The miners would get some share is above target messages because it would be holding some low difficulty shares in its local queue.  Then it would start submitting higher difficulty shares.

In this case, the miner thinks the difficulty is set to the high level, but the pool thinks it's set to the low level.  This can *only* happen if the proxy is reversing the order.

Yes, it would be all okay, if pool considered shares being only over 1.572864. But it turned out, that it considered shares to be over 0.032768. Our proxy sent only shares above 1.572864, and only few of them were sent (due to being high and rare to be discovered) which resulted in low speed on the pool.

Yes, and the only way this can happen is if the pool and the miner are confused about which is the current difficulty.  And the only way that can happen is if the order of the set_difficulty commands is being changed by the proxy.

How could it be? This is what we got from Ipominer - in order as I posted. And you will get same order with the short example program I posted, if you don't believe me (unless they fixed it by now).

That obviously isn't the case, since the only way for the situation to happen in the first place is if the order is getting reversed by the proxy.  The pool remembers the last difficulty set and credits shares based on that.

The print I showed is dump from Wireshark - what was sent from Ipominer pool. There was no reversing made by proxy, proxy only read that data. Obviously pool "messed" which diff was sent lastly. If you split subscription and authorization into 2 packets (make some delay between sending them), then the order of delegated diffs is high then low. Please, try the short example I provided and you will see it with your own eyes what happens if you don't believe me.

[suchmoon]

ipominer / flound1129 / atomicchaos, if it's any consolation unfortunately this is typical nicehash MO - whatever happens blame someone else. I've been mining here since day one and I'm a big fan of the concept but I have given up on trying to resolve any issues. Couldn't connect to the stratum for two days - the suggested solution was to change my IP because their DDOS protection was blocking me, then it turns out it should have unblocked me after three hours so it must "something on my end", as if I'm that dumb. Stratum downtimes happen often, not reflected in the stats on their front page though. Great idea, poor execution. A lot more issues than with any other pool or rental service I've dealt with. Have solid backups if you're a rig owner, count your pennies carefully if you're a renter, be prepared for unhappy miners if you're a pool.

[torontominer]

anyone having problem when switching of pools happens too often?
sgminer just stuck at switching and kept doing it.

would increasing switch gap help?

[tboy32]

No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.

Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.

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.

[flound1129]

This service abstracts the pool it's mining on away from the end user and out of the user's control, correct?

[nwfella]

Bit surprised by the 'profitability spurts' experienced with my few little rig's on nicehash during this past 24h period.  Not that I'm complaining

[flound1129]

No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.

Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.

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.

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.

[ltc_bilic]

Since the last update the service is more stable but there are still connection problems, sometimes the miner has to restart the connection sometimes not, I get lot's of following messages:

stratum_recv_line failed
Stratum connection interrupted

This happens when our stratum terminates connection to your rig. Make sure you are not sending too many rejects.

Used to have many reject when my cards when OC, now i've turned it down to see if it's better.
Now I have 1-2% of rejects and still receive those two lines on all algos, does difficulty influence this? Or how can I improve that?
using ccminer and nvidia 750ti

[nicehashdev]

No, this is just example I put together to get wanted result. We don't send together, we have several sends. In fact, after each JSON string, we have separate send call for \n. And in real case scenario I observed that first JSON string is sent without \n, then second JSON string has \n pre-appended and one \n at the end. Even though in code, it is being done 2x send+send. This is TCP protocol and you have no control over how data is being split among packets - this means you should never rely on PACKETS in TCP, but read it as a STREAM! If your software reads them as packets, then this is very very wrong.

Your software should not parse JSON line until \n is received. If we follow this logic, then first line is parsed with some result (in this case, diff adjusted + reply + mining notify sent), then it is time to parse next line, which is authorization. Your software does something terribly wrong, because as it seems, it parses both lines at the same time (maybe due to multithreading?) or even worse - it parses line that comes second first. I can't judge that, because I have no idea what kind of software you use.

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.

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.

[nicehashdev]

Since the last update the service is more stable but there are still connection problems, sometimes the miner has to restart the connection sometimes not, I get lot's of following messages:

stratum_recv_line failed
Stratum connection interrupted

This happens when our stratum terminates connection to your rig. Make sure you are not sending too many rejects.

Used to have many reject when my cards when OC, now i've turned it down to see if it's better.
I have 1-2% of rejects. I still receive those two lines on all algos, does difficulty influence this? Or how can I improve that?

- Do you get these lines when miner switches algorithm?
- What mining software you use?
- How many miners you have?
- Do you get blocked/banned?