Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 270. (Read 794394 times)

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

Okay, so to clarify the issue then, if your proxy behaves as your code reads, you are improperly sending subscribe and authorize at the same time. You should send subscribe, and then authorize, like every other mining software does.

When you send subscribe, stratum will send you POOL_TARGET (high) difficulty. Then when you send authorize, it sends you the appropriate worker-specific difficulty. If you're sending them at the same time instead of subscribe then authorize, that's not standard behavior.

Look at your own version of sgminer for an example of proper behavior:

subscribe happens here: https://github.com/sgminer-dev/sgminer/blob/v5_0/util.c#L2442
authorize happens here: https://github.com/sgminer-dev/sgminer/blob/v5_0/util.c#L1961

Let me help you. Following scenario causes your stratum to send low first, then high:


It is C# .NET code. Try it and sniff data, you will see. My guess is that if authorization is sent too fast right after subscribe (which can happen in case of network congestion, TCP specs do not guarantee same set of data to be sent together, but it may split data or combine with other sends - so you need to consider all this when programming with TCP) then your stratum messes up diffs.

Again, we do not send difficulty settings out of order as low->high. Anyone can easily verify that with their own miner and tcpdump session, using our stratum. They are sent high->low, which is correct, and every other mining software on the planet works perfectly. Miners always take the last sent difficulty setting, so if we were truly sending a higher difficulty second, all mining software, including sgminer would behave similarly as you claim. That's not the case.

And, just for the sake of further evidence, here's a full tcpdump of the simplified example I posted previously, for anyone that's interested: http://pastebin.com/NKbwE7FK

You may want to read about:

http://www.diffen.com/difference/TCP_vs_UDP

and

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Stratum protocol uses TCP underlying protocol. Now, the most important part is following, saying:


Your pool did send first low diff, then it sent high diff, but it used low diff to calculate hashing speed (because only few high diff shares were sent, your pool actually displayed very low speed, but that was because your pool "tricked" NiceHash stratum to believe that actual diff is the last one you sent - high one).

Our code did change it, because we know what you do now and consider your first diff as valid one and not the second highest.

Incorrect. I paid for 100MH/s and my order was totally used up.  They delivered 16MH/s or 16% of the hash I paid for, period.

This is *your* proxy misbehaving, and that's why *your* code change fixed it. I've already shown tcpdumps from our end which indicate that we are sending difficulty in the proper order, and any miner can easily confirm that on their own by tcpdump'ing a connection from their own mining rig.

Furthermore, attacking one of your largest customer bases in public after they've gone out of their way to try and help you troubleshoot an issue privately is poor business, as is refusing to accept responsibility for your mistakes.

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


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.

Lol, I'm sorry, but what kind refund do you want?
You pay only for valid shares.

Ah, I see, "miningrentals" in signature. Direct competitors?

I was one of the first to notice and report this problem to NH.  I asked for a refund on only one of the many orders that delivered about 16% of the hash I paid for.  They refused to give a refund on even one small order, which I told them there were a few others as well.  Then they asked for all kinds of pool information and my first born child before they would even look into a refund.  Since my orders were only about .04 btc, I didn't want to bother IPO's pool owner, he does a great job and doesn't need this hassle.  All I can say to Nice Hash is that whenever I have rented from Mining Rig Rentals or Betarigs, and there was a problem, I was quickly refunded for the lost hash, no questions asked.  NiceHash has not been very "Nice" to it's core renters, and if this continues, I can only see a competitor sprouting up that will offer the same service, and with the same customer support and refund policies as Betarigs or MRR.  I have put a trademark name on this new company, FairHash, so if any devs are interested in starting it, just let me know, and I only want a "Fair" compensation for my name.

Nicehash, you really need to make some fixes or I don't know. When I rent at nicehash, pretty often orders going "Remote pool terminated connection.". At different algos and different pools. So I suppose problem at your side. Before - I had a conversation with dedicatedpool's admin(the previous pool I had such problems with, not the last one), he checked for the nicehash being whitelisted, I suppose it is whitelisted.

I don't have time to read thread(to check for same problems), I'm sorry, but I believe I'm not the only one having such problems.

It started not so long ago. Before - everything was fine.