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

[zmhaha]

How is the Payout for Nicehash compared to a decent sized ordinary multipool like trademybit.com??
Unless there are massive amount of buyer to compete with each other on the bids, the price should always be noticeably lower than a decent sized traditional multipool, given their profit switching are both efficient.

[miner256]

How is the Payout for Nicehash compared to a decent sized ordinary multipool like trademybit.com??
Unless there are massive amount of buyer to compete with each other on the bids, the price should always be noticeably lower than a decent sized traditional multipool, given their profit switching are both efficient.

Good question. I moved to trademybit yesterday when nicehash had its problems. I must be misunderstanding something here so can some check my numbers?

Nicehash    X13 paying 0.5 BTC/day/Ghash this is 0.0005 BTC/day/Mhash (1GHash = 0.001Mhash)
TradeMyBit X13 paying 0.00079 BTC/day/Mhash which is 0.79 BTC/day/Ghash (currently via APEX, but I autoexchange to BTC)

So doesn't that make TradeMyBit more profitable? 0.79 vs 0.5?
Assuming the stats are both inaccurate, then I would say my actual BTC payments are much higher with TMB?
Is this because I have just a very small minnow running around 10Mhash/s?

Interested in the views of others

[acemaster15]

Will fresh algo be in nicehash soon?

[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

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

[slapper]

I couldn't find any references - what is it about at all? Keep in mind, we do not offer mining of Darkcoin, we only offer shares being validated (x11) and forwarded on and that is being done with help of stratum protocol. We don't use Darkcoin wallets.

http://wiki.darkcoin.eu/wiki/Important

[nicehashdev]

I couldn't find any references - what is it about at all? Keep in mind, we do not offer mining of Darkcoin, we only offer shares being validated (x11) and forwarded on and that is being done with help of stratum protocol. We don't use Darkcoin wallets.

http://wiki.darkcoin.eu/wiki/Important

We don't run Darkocode wallet. We are just running stratum proxy that forwards work of miners to the remote pools.

[nicehashdev]

URGENT ANNOUNCEMENT TO ALL BUYERS

Long version:
Lately, we have been receiving complaints that hashing rate on Ipominer is only several percents of what NiceHash reports. Today, we have been contacted by Ipominer and took a deeper look into the situation. We found out, that there was an issue with difficulty, where Ipominer pool sent lower diff before sending higher diff, but then using lower diff to calculate hashing speed. That resulted in very poor performance shown on Ipominer.

Now, we are not fully sure, what kind of software Ipominer use for stratum, but if it is something publicly available, it means that there may be other pools with same issue.

We have applied temporary fix for this situation and Ipominer is now again compatible with NiceHash.

If you detect such issue in future, please, do not hesitate to contact us, but also provide details. Claiming only that you get bad hashrate does not help us analyse the issue.

In short: NiceHash did not cheat anyone. There is a bug in stratum software used by Ipominer (and perhaps some other pools).

[ipominer]

URGENT ANNOUNCEMENT TO ALL BUYERS

Long version:
Lately, we have been receiving complaints that hashing rate on Ipominer is only several percents of what NiceHash reports. Today, we have been contacted by Ipominer and took a deeper look into the situation. We found out, that there was an issue with difficulty, where Ipominer pool sent lower diff before sending higher diff, but then using lower diff to calculate hashing speed. That resulted in very poor performance shown on Ipominer.

Now, we are not fully sure, what kind of software Ipominer use for stratum, but if it is something publicly available, it means that there may be other pools with same issue.

We have applied temporary fix for this situation and Ipominer is now again compatible with NiceHash.

If you detect such issue in future, please, do not hesitate to contact us, but also provide details. Claiming only that you get bad hashrate does not help us analyse the issue.

In short: NiceHash did not cheat anyone. There is a bug in stratum software used by Ipominer (and perhaps some other pools).

I'm glad to see that NiceHash finally addressed this issue at our insistence, after days on end of customer complaints. Seeing as how I'm the one that brought the issue of their failure to respect difficulty settings properly to their attention, I find their blaming of ipoMiner to be extremely disingenuous.

Let's review their claim here that ipoMiner was erroneously sending lower difficulty before sending higher difficulty with a bit more detail...

1) Sgminer, and every other mining software released to date, have always worked perfectly with ipoMiner's stratums, and show correct behavior in their console. Here's a recent example from my own sgminer I ran as a test today:

Code:

[14:03:00] Probing for an alive pool
[14:03:00] Pool 0 difficulty changed to 1.573
[14:03:00] Pool 0 difficulty changed to 0.016
[14:03:01] Network diff set to 1.2K
[14:03:05] Accepted 1fe58d97 Diff 0.031/0.016 GPU 1 at Pool 0

As you can see, difficulty is initially set to 1.573 and then changed to 0.016, which is the configured difficulty for that worker.

2) These issues with NiceHash began approximately 7-10 days ago, and have been ongoing since then. Users have complained about this, but they have done nothing to address the issue until now. In addition to seeing problems with NiceHash at ipoMiner, I've also heard several other large, popular pools having similar problems with NiceHash usage as well recently.

Now, during that time period, NiceHash has been under DDoS attacks and recently moved to a new proxy server, which we initially assumed were the likely causes of their problems. However, after digging into it more in the past 24 hours, I realized that the real issue is that they were not respecting difficulty retargeting properly.

3) To disprove their claim that we erroneously were sending lower difficulty before sending higher difficulty, let's look at a tcpdump of a single connection from a miner at our proxy layer:

Code:

{"id": 0, "method": "mining.subscribe", "params": ["sgminer/4.1.0"]}
{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f8004373", 4]}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"id": 1, "method": "mining.authorize", "params": ["Wuher.1", "x"]}
{"params": [0.016384], "id": null, "method": "mining.set_difficulty"}

This is for an X11 miner connection, and as you can see, just like in the sgminer console output, a difficulty of 1.572864 (equivalent to scrypt difficulty of 49152) is initially set, then the configured worker difficulty of 0.016384 is set.

[biohammer]

URGENT ANNOUNCEMENT TO ALL BUYERS

Long version:
Lately, we have been receiving complaints that hashing rate on Ipominer is only several percents of what NiceHash reports. Today, we have been contacted by Ipominer and took a deeper look into the situation. We found out, that there was an issue with difficulty, where Ipominer pool sent lower diff before sending higher diff, but then using lower diff to calculate hashing speed. That resulted in very poor performance shown on Ipominer.

Now, we are not fully sure, what kind of software Ipominer use for stratum, but if it is something publicly available, it means that there may be other pools with same issue.

We have applied temporary fix for this situation and Ipominer is now again compatible with NiceHash.

If you detect such issue in future, please, do not hesitate to contact us, but also provide details. Claiming only that you get bad hashrate does not help us analyse the issue.

In short: NiceHash did not cheat anyone. There is a bug in stratum software used by Ipominer (and perhaps some other pools).

I'm glad to see that NiceHash finally addressed this issue at our insistence, after days on end of customer complaints. Seeing as how I'm the one that brought the issue of their failure to respect difficulty settings properly to their attention, I find their blaming of ipoMiner to be extremely disingenuous.

Let's review their claim here that ipoMiner was erroneously sending lower difficulty before sending higher difficulty with a bit more detail...

1) Sgminer, and every other mining software released to date, have always worked perfectly with ipoMiner's stratums, and show correct behavior in their console. Here's a recent example from my own sgminer I ran as a test today:

Code:

[14:03:00] Probing for an alive pool
[14:03:00] Pool 0 difficulty changed to 1.573
[14:03:00] Pool 0 difficulty changed to 0.016
[14:03:01] Network diff set to 1.2K
[14:03:05] Accepted 1fe58d97 Diff 0.031/0.016 GPU 1 at Pool 0

As you can see, difficulty is initially set to 1.573 and then changed to 0.016, which is the configured difficulty for that worker.

2) These issues with NiceHash began approximately 7-10 days ago, and have been ongoing since then. Users have complained about this, but they have done nothing to address the issue until now. In addition to seeing problems with NiceHash at ipoMiner, I've also heard several other large, popular pools having similar problems with NiceHash usage as well recently.

Now, during that time period, NiceHash has been under DDoS attacks and recently moved to a new proxy server, which we initially assumed were the likely causes of their problems. However, after digging into it more in the past 24 hours, I realized that the real issue is that they were not respecting difficulty retargeting properly.

3) To disprove their claim that we erroneously were sending lower difficulty before sending higher difficulty, let's look at a tcpdump of a single connection from a miner at our proxy layer:

Code:

{"id": 0, "method": "mining.subscribe", "params": ["sgminer/4.1.0"]}
{"error": null, "id": 0, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f8004373", 4]}
{"params": [1.572864], "id": null, "method": "mining.set_difficulty"}
{"id": 1, "method": "mining.authorize", "params": ["Wuher.1", "x"]}
{"params": [0.016384], "id": null, "method": "mining.set_difficulty"}

This is for an X11 miner connection, and as you can see, just like in the sgminer console output, a difficulty of 1.572864 (equivalent to scrypt difficulty of 49152) is initially set, then the configured worker difficulty of 0.016384 is set.

Based on this newly clarified information  it seems as though NiceHash May owe some of us some btc for providing less hash than we paid for .  While you may not have intentionally Cheated users you may have inadvertently  done so.  By coding the diff adjustment improperly

[Hodor_keeper_of_the_light]

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.

[jimlite]

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.

[Hodor_keeper_of_the_light]

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.

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?

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

[ipominer]

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.

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.

[jimlite]

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.

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?

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.

[nicehashdev]

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:

There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent.

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.

[ipominer]

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:

There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent.

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.

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

[nicehashdev]

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:

There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent.

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.

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.

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

Code:

        
        static void Main(string[] args)
        {
            TcpClient cl = new TcpClient("pool.ipominer.com", 3335);

            cl.Client.Send(ASCIIEncoding.ASCII.GetBytes("{\"id\": 0, \"method\": \"mining.subscribe\", \"params\": []}\n{\"params\": [\"nicehashdev.1\", \"x\"], \"id\": 1, \"method\": \"mining.authorize\"}\n"));
            System.Threading.Thread.Sleep(1000);

            cl.Close();
        }

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.

[ipominer]

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:

There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent.

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.

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.

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

Code:

        
        static void Main(string[] args)
        {
            TcpClient cl = new TcpClient("pool.ipominer.com", 3335);

            cl.Client.Send(ASCIIEncoding.ASCII.GetBytes("{\"id\": 0, \"method\": \"mining.subscribe\", \"params\": []}\n{\"params\": [\"nicehashdev.1\", \"x\"], \"id\": 1, \"method\": \"mining.authorize\"}\n"));
            System.Threading.Thread.Sleep(1000);

            cl.Close();
        }

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.

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