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

[dspair]

You can manually give your miner best paying order, if you restart your miner, because system always assigns new connecting miner to best paying order.

Do not forget about speed limitations. If order is 0.9-1.2 x of limited speed, it will be skipped and assigned to next best paying.

So if I write a script that automatically restarts the miner if there is a new higher paying order, I will get paid more than everyone else? I already wrote a script that restarts it whenever there is a new "No limit" order, because your system just hates switching, even though it takes like 3 seconds, and I usually mine 1-2 BTC lower order because of that. I guess now I have to upgrade it to take that into account Maybe I should just restart miner every 3 minutes?

Can't you just pay the average, so we don't have to rely on luck or write some bizzare scripts to restart the miner every N minutes?

[dloganbill]

I am also confused why you are using a round robin method.  The buyers pay BTC/hash so why don't you average those among all the jobs that are currently being mined.

During some of the short periods where someone puts in a really high bid price, some of us may be locked into long-term lower priced jobs and miss the boat.

Also, if everyone wrote scripts as you suggest, wouldn't that really screw with your stratum?

[nicehashdev]

Often miner restarts actually cause your miner to hash with lower hashing speed on longer run - that is why switches are not happening often. When switch happens there are three things to consider:
- possibility for some shares being lost
- miner procedure to issue reconnect, get new work, load work onto video card and start hashing again
- possibility for miner to switch to backup pool and mine there for few minutes before switching back again

Average payment is something we are consider to implement in future, but there might be some issues regarding tiny values. The BTC amount increase for each share submitted by all miners would be so tiny for slow miners, that we need to first run some calculations to see whether standard double float precision data type is enough or we need perform some tricks to get past this.

[phzi]

Often miner restarts actually cause your miner to hash with lower hashing speed on longer run - that is why switches are not happening often. When switch happens there are three things to consider:
- possibility for some shares being lost
- miner procedure to issue reconnect, get new work, load work onto video card and start hashing again
- possibility for miner to switch to backup pool and mine there for few minutes before switching back again

Average payment is something we are consider to implement in future, but there might be some issues regarding tiny values. The BTC amount increase for each share submitted by all miners would be so tiny for slow miners, that we need to first run some calculations to see whether standard double float precision data type is enough or we need perform some tricks to get past this.

By buffering the next job's work before disconnecting the miner for a switch, you can get switch time down to a fraction of a second, and the risk of lost work is no worse then stales (and if you accept shares after a re-connect, then it's less).  In fact, a famous multi-pool has implemented just this so that when they proxy work to other pools, all you see is "Stratum connection to __ interrupted," and mining never skips a beat. Your post, therefore, seems an unacceptable reason for the poorly designed switching system that so far nicehash has implemented.  The current system isn't fair for providers or miners.  As a miner, I have to abuse the system to get the best rewards (constantly check if there is new work at higher pay, and reconnect whenever there is).  As a provider, there's no solid reasoning behind what bids will garner what hashrate.  I have had 1BTC unlimited rate orders and still watched someone with a 1BTC/GH lower bid continue to have a higher hashrate then my order for the following hour!  (That means over half the pool's buyers were earning less then they could have been, by a margin of over 10%). Not to mention, when bids are getting bumped around, the system will sometimes drop almost all the miners from my job, moving them up a job, and re-assign other miners to my job.  That's just flat out inefficient, and causes hashrate luls for both providers and buyers much worse then faster and appropriate switching would.

I am also not buying your guy's excuse that the idle miners are a problem with sgminer/cgminer.  Yes, you can fix it by patching sgminer...  but, your system is accepting stratum auth for miners that it should not - it accepts connections when there are jobs open but no work available.  That's a logic problem in nicehash, not in sgminer.

---

As for paying based on averages - your stats on the main page seem to show the current average BTC/GH/day rate... this is the rate that all miners should be paid, if you want a fair system.  Round robin is not working.  If you want to minimize switching, then average payment to miners is the only thing that makes sense (because then switching is irrelevant).  Just make sure you take into account reject rates per jobs vs per user when calculating proportional earnings if you want a fair system.

And don't count BTC - count shares, and then compute BTC periodically (say every 5 minutes for the previous 5 minute window) instead of on a PPS basis.  You don't have to worry about round hopping because found blocks aren't directly relevant here, so there is no reason not to use a proportional system based on short rounds.

[nicehashdev]

I am also not buying your guy's excuse that the idle miners are a problem with sgminer/cgminer.  Yes, you can fix it by patching sgminer...  but, your system is accepting stratum auth for miners that it should not - it accepts connections when there are jobs open but no work available.  That's a logic problem in nicehash, not in sgminer.

NiceHash will send authorization error and drop connection. You can see that if you check logs of network traffic (sniff it, if you don't believe). Beyond that, there is nothing in our power to do about it, but to get sg/cgminer fixed. NiceHash cannot refuse connection until it gets authorization request, where p= is specified as password. Until this event, NiceHash will of course keep connection alive.

EDIT: Could you point me in direction of fix for sgminer? Thanks.

By buffering the next job's work before disconnecting the miner for a switch, you can get switch time down to a fraction of a second, and the risk of lost work is no worse then stales (and if you accept shares after a re-connect, then it's less).  In fact, a famous multi-pool has implemented just this so that when they proxy work to other pools, all you see is "Stratum connection to __ interrupted," and mining never skips a beat. Your post, therefore, seems an unacceptable reason for the poorly designed switching system that so far nicehash has implemented.  The current system isn't fair for providers or miners.  As a miner, I have to abuse the system to get the best rewards (constantly check if there is new work at higher pay, and reconnect whenever there is).  As a provider, there's no solid reasoning behind what bids will garner what hashrate.  I have had 1BTC unlimited rate orders and still watched someone with a 1BTC/GH lower bid continue to have a higher hashrate then my order for the following hour!  (That means over half the pool's buyers were earning less then they could have been, by a margin of over 10%). Not to mention, when bids are getting bumped around, the system will sometimes drop almost all the miners from my job, moving them up a job, and re-assign other miners to my job.  That's just flat out inefficient, and causes hashrate luls for both providers and buyers much worse then faster and appropriate switching would.

For each order, extranonce1 has to be changed. This cannot be done otherwise but to drop connection and force miner to reconnect. Once extranonce1 is changed, miner WILL have to change it's internal work that is being hashed, because extranonce1 is part of the work that is being hashed. There is no point in any kind of buffering you are referring to.

If any multipool actually implemented "real" proxifications to other pools like NiceHash is doing, it would hit same obstacle of extranonce bug in cgminer 3.7.2. And I really don't recall/haven't heard of any multipool not being compatible with cgminer 3.7.2. This makes me to believe, that no multipool is actually doing internal job delegation which you can observe with NiceHash service - or when slush's stratum proxy is used. They most likely use same extranonce1 numbers and can of course do "buffering" as you propose, because work for hashing does not change after doing reconnect.

NiceHash appends additional byte to extranonce1 which is taken from buyers pool. It cannot give own set of extranonces, because all work would be invalid on target pool in such case - it can only iterate from 0 to 255 (appended single byte), while the first part of extranonce1 (4 bytes) is equal to what was assigned by the buyers pool.

[elpsycongro]

I am also not buying your guy's excuse that the idle miners are a problem with sgminer/cgminer.  Yes, you can fix it by patching sgminer...  but, your system is accepting stratum auth for miners that it should not - it accepts connections when there are jobs open but no work available.  That's a logic problem in nicehash, not in sgminer.

NiceHash will send authorization error and drop connection. You can see that if you check logs of network traffic (sniff it, if you don't believe). Beyond that, there is nothing in our power to do about it, but to get sg/cgminer fixed. NiceHash cannot refuse connection until it gets authorization request, where p= is specified as password. Until this event, NiceHash will of course keep connection alive.

EDIT: Could you point me in direction of fix for sgminer? Thanks.

By buffering the next job's work before disconnecting the miner for a switch, you can get switch time down to a fraction of a second, and the risk of lost work is no worse then stales (and if you accept shares after a re-connect, then it's less).  In fact, a famous multi-pool has implemented just this so that when they proxy work to other pools, all you see is "Stratum connection to __ interrupted," and mining never skips a beat. Your post, therefore, seems an unacceptable reason for the poorly designed switching system that so far nicehash has implemented.  The current system isn't fair for providers or miners.  As a miner, I have to abuse the system to get the best rewards (constantly check if there is new work at higher pay, and reconnect whenever there is).  As a provider, there's no solid reasoning behind what bids will garner what hashrate.  I have had 1BTC unlimited rate orders and still watched someone with a 1BTC/GH lower bid continue to have a higher hashrate then my order for the following hour!  (That means over half the pool's buyers were earning less then they could have been, by a margin of over 10%). Not to mention, when bids are getting bumped around, the system will sometimes drop almost all the miners from my job, moving them up a job, and re-assign other miners to my job.  That's just flat out inefficient, and causes hashrate luls for both providers and buyers much worse then faster and appropriate switching would.

For each order, extranonce1 has to be changed. This cannot be done otherwise but to drop connection and force miner to reconnect. Once extranonce1 is changed, miner WILL have to change it's internal work that is being hashed, because extranonce1 is part of the work that is being hashed. There is no point in any kind of buffering you are referring to.

If any multipool actually implemented "real" proxifications to other pools like NiceHash is doing, it would hit same obstacle of extranonce bug in cgminer 3.7.2. And I really don't recall/haven't heard of any multipool not being compatible with cgminer 3.7.2. This makes me to believe, that no multipool is actually doing internal job delegation which you can observe with NiceHash service - or when slush's stratum proxy is used. They most likely use same extranonce1 numbers and can of course do "buffering" as you propose, because work for hashing does not change after doing reconnect.

NiceHash appends additional byte to extranonce1 which is taken from buyers pool. It cannot give own set of extranonces, because all work would be invalid on target pool in such case - it can only iterate from 0 to 255 (appended single byte), while the first part of extranonce1 (4 bytes) is equal to what was assigned by the buyers pool.

no phzi is right i know exactly which pool implemented it as i used to mine there(still do on occasion ), it is very possible.

[OSAC5CO]

Is there a the ability to select the coin you mine? How about somewhere else?

[phzi]

The buffering I am talking about is very key. Yes, it has been done before. And you are correct that a reconnect is neccesary to change extranonce1 and possibly extranonce2_size.  Having work buffered on the server ready for the miner before you force a reconnect and update the on-connect nonce params allows you to instantly provide work when the miner reconnects, essentially eliminating switch downtime.

As for the problem with idle miners - I have not observed failed auths in these cases. I see the pool accepting the auth request with p=, but not being able to provide work. This seems to occur when there are jobs at the desired profitability, but those jobs are already maxed on miner (no slots available). The pool keeps the connection open and allows the auth innappropriately.  If I set p high enough that no jobs are available (full or not),  this doesn't happen.

Don't know what you meant about slush's proxy. The pool I am talking about has a fully custom stratum implementation and can proxy traffic at will. The miner sees only the interupted message and mining barely hiccups.

My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?

I also still don't think the idle issue is a cgminer bug.  The addition of stratum commands to change the extranonce params that are limited to on-connect right now would be valuable, however.  Stratum is dying for a few extension like this, as well as for pool provided algorithm and nfactor.

[phzi]

Is there a the ability to select the coin you mine? How about somewhere else?

Buyer or a provider?

As a buyer, you are in complete control of what is being mined.

As a provider, you get work and are paid in BTC. It is completely out of your hands what you are mining (you might even be creating private chains, attacking a blockchain, etc).

[nicehashdev]

The buffering I am talking about is very key. Yes, it has been done before. And you are correct that a reconnect is neccesary to change extranonce1 and possibly extranonce2_size.  Having work buffered on the server ready for the miner before you force a reconnect and update the on-connect nonce params allows you to instantly provide work when the miner reconnects, essentially eliminating switch downtime.

As for the problem with idle miners - I have not observed failed auths in these cases. I see the pool accepting the auth request with p=, but not being able to provide work. This seems to occur when there are jobs at the desired profitability, but those jobs are already maxed on miner (no slots available). The pool keeps the connection open and allows the auth innappropriately.  If I set p high enough that no jobs are available (full or not),  this doesn't happen.

Don't know what you meant about slush's proxy. The pool I am talking about has a fully custom stratum implementation and can proxy traffic at will. The miner sees only the interupted message and mining barely hiccups.

My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?

I also still don't think the idle issue is a cgminer bug.  The addition of stratum commands to change the extranonce params that are limited to on-connect right now would be valuable, however.  Stratum is dying for a few extension like this, as well as for pool provided algorithm and nfactor.

Show me sniffed log. NiceHash will drop connection when p is too high for current order, regardless of what kind of orders are there (maxed out or not). We have seen this faulty behaviour only happening after cgminer/sgminer is running for a while, and it always *fixes* it-self when you restart the miner. Completely logical conclusion is that there is bug in cgminer/sgminer, because NiceHash keeps no track of miners, all it gets is socket with IP and port - it doesn't know whether it is a reconnect after a while or a connect from restarted miner. If the bug was on NiceHash side, then restart of cgminer/sgminer would not help you.

Your secretive behaviour does not help you with your credibility. I am not fully sure whether we should even accept your feedback input at all. You talk about some mysterious pool for several pages now already, and we still haven't learned which pool this is.

[elpsycongro]

The buffering I am talking about is very key. Yes, it has been done before. And you are correct that a reconnect is neccesary to change extranonce1 and possibly extranonce2_size.  Having work buffered on the server ready for the miner before you force a reconnect and update the on-connect nonce params allows you to instantly provide work when the miner reconnects, essentially eliminating switch downtime.

As for the problem with idle miners - I have not observed failed auths in these cases. I see the pool accepting the auth request with p=, but not being able to provide work. This seems to occur when there are jobs at the desired profitability, but those jobs are already maxed on miner (no slots available). The pool keeps the connection open and allows the auth innappropriately.  If I set p high enough that no jobs are available (full or not),  this doesn't happen.

Don't know what you meant about slush's proxy. The pool I am talking about has a fully custom stratum implementation and can proxy traffic at will. The miner sees only the interupted message and mining barely hiccups.

My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?

I also still don't think the idle issue is a cgminer bug.  The addition of stratum commands to change the extranonce params that are limited to on-connect right now would be valuable, however.  Stratum is dying for a few extension like this, as well as for pool provided algorithm and nfactor.

Show me sniffed log. NiceHash will drop connection when p is too high for current order, regardless of what kind of orders are there (maxed out or not). We have seen this faulty behaviour only happening after cgminer/sgminer is running for a while, and it always *fixes* it-self when you restart the miner. Completely logical conclusion is that there is bug in cgminer/sgminer, because NiceHash keeps no track of miners, all it gets is socket with IP and port - it doesn't know whether it is a reconnect after a while or a connect from restarted miner. If the bug was on NiceHash side, then restart of cgminer/sgminer would not help you.

Your secretive behaviour does not help you with your credibility. I am not fully sure whether we should even accept your feedback input at all. You talk about some mysterious pool for several pages now already, and we still haven't learned which pool this is.

if you want to believe him or not is up to you,  but i can tell you he aint lying, i don't have the smarts to explain in detail but i came from that pool.

[phzi]

Lol. I haven't been mentioning the pool by name in this thread because I am avoiding advertising for another pool in this thread... I thought I was showing some forum etiquite. (Nor have you messaged me and asked for more info)

I have observed this behavior on startup, btw.  When there wasn't an unlimited order above the p= setting, and higher orders were full, I was able to restart multiple times and observe the issue. I can try to sniff the traffic from a rig if you need. I have a solution that has been working fine for my rigs, so honestly this isn't even personally relevant.  I have made some solid profits on over 2BTC of hashing power I have purchased from here as well.  I have been more hopeful that my suggestion might bring increased power to nicehash.

Anyway, I have been trying to be helpful. I will happily leave this thread and pool if you don't want me to share my knowledge.

[zneww]

Lol. I haven't been mentioning the pool by name in this thread because I am avoiding advertising for another pool in this thread... I thought I was showing some forum etiquite. (Nor have you messaged me and asked for more info)

I have observed this behavior on startup, btw.  When there wasn't an unlimited order above the p= setting, and higher orders were full, I was able to restart multiple times and observe the issue. I can try to sniff the traffic from a rig if you need. I have a solution that has been working fine for my rigs, so honestly this isn't even personally relevant.  I have made some solid profits on over 2BTC of hashing power I have purchased from here as well.  I have been more hopeful that my suggestion might bring increased power to nicehash.

Anyway, I have been trying to be helpful. I will happily leave this thread and pool if you don't want me to share my knowledge.

You can only help someone so much.

[kenshirothefist]

Anyway, I have been trying to be helpful.

Of course we respect yor help, shareing ideas, etc.! It's also natural that we can't agree on each and every topic discussed here, therefore it's better to discusss some specific issues via PM. Thanks you all guys for your feedback, we'll try to do our best to provide the best possible service to sellers & providers. And also keep in mind that our service is still young and we're probably not getting enough sleep for the last couple of days

[mac-coin]

I think people should give the dev a bit of a brake.  

This website is the first of a kind and has been up and running for 2-3 weeks.  Knowledge is fast moving in crypto coding, and what works on 1 website might no work on another without total starting again on the code.  

Never done much programming myself,  but I've also said to myself and others that if someone tells you it can't be programmed, that means they don't now how to program it.  But that still doesn't mean it's always practically possible mainly due to computer power and speed, which is critical in mining.

Keep up the good work

[phzi]

Nice to see nscrypt buyers picking up a bit.  Interesting opportunities there.

[nicehashdev]

I am trully unable to reproduce any kind of misbehaviours regarding p=, no matter what I set and at what kind of timing I start the miner. Everything is working just fine. I tested with sgminer 4.0.0.

So, until I have a way to reproduce this bug I really have no idea what else to do or look. Believe me, I have been sitting in front of code for hours trying to figure out what could have gone wrong, and I couldn't find it. I can paste you the part regarding it and you will see on your own.

[comeonalready]

I am trully unable to reproduce any kind of misbehaviours regarding p=, no matter what I set and at what kind of timing I start the miner. Everything is working just fine. I tested with sgminer 4.0.0.

So, until I have a way to reproduce this bug I really have no idea what else to do or look. Believe me, I have been sitting in front of code for hours trying to figure out what could have gone wrong, and I couldn't find it. I can paste you the part regarding it and you will see on your own.

I wish I could spend the time to help you find it -- because it just happened twice on one miner and once on another while I had them up on my screen, within twenty minutes of your last post.  I was unable to capture any usable logs, but it went something like this.  I was mining at nicehash with p=7.9 and there were one or two 7.9 orders available (and none higher) that were active and mining properly.  Then they expired or were canceled (they fell off the order list anyway), leaving only lower priced orders, and my miners did not disconnect from the stratum server, instead the GPUs spun down (as seen by decreasing GPU temperatures), and neither accepted nor rejected shares increased.  At this point, my monitoring process will notice stuck accepted shares and restart the miner, but I disabled it temporarily to see if I could gather any more data while it was stuck doing nothing.  Unfortunately before I could, a new 8.1 order popped up and hashing started again.  So I've reenabled my monitor process and will just hope that you find the cause soon.

There are indeed times that nicehash will properly fail over to my backup pool as expected without my monitor process having to intervene, so this problem is almost certainly intermittent in nature.  What you have coded does work at least some of the time, so the source of this problem will probably not be obvious.

Also worth noting is that from what I have observed before, the appearance of a higher priced order will not necessarily pull my miner out of its nap, as that order might already be full.  Perhaps you can think of another non-standard way to get a miner to disconnect before sending authorization error and closing the socket?  I am running sgminer 4.1.271.

[elbandi]

I am trully unable to reproduce any kind of misbehaviours regarding p=, no matter what I set and at what kind of timing I start the miner. Everything is working just fine. I tested with sgminer 4.0.0.

So, until I have a way to reproduce this bug I really have no idea what else to do or look. Believe me, I have been sitting in front of code for hours trying to figure out what could have gone wrong, and I couldn't find it. I can paste you the part regarding it and you will see on your own.

i think, if someone has a issue with nicehash, start sgminer/cgminer with debug mode, save logs to file, and send it to nicehashdev.

cgminer --debug --protocol-dump --log-show-date -o otherparam.... 2>logfile.txt

I'm sure, it'll help they to find the bug.

Elbandi

[nicehashdev]

I am trully unable to reproduce any kind of misbehaviours regarding p=, no matter what I set and at what kind of timing I start the miner. Everything is working just fine. I tested with sgminer 4.0.0.

So, until I have a way to reproduce this bug I really have no idea what else to do or look. Believe me, I have been sitting in front of code for hours trying to figure out what could have gone wrong, and I couldn't find it. I can paste you the part regarding it and you will see on your own.

i think, if someone has a issue with nicehash, start sgminer/cgminer with debug mode, save logs to file, and send it to nicehashdev.

cgminer --debug --protocol-dump --log-show-date -o otherparam.... 2>logfile.txt

I'm sure, it'll help they to find the bug.

Elbandi

These debug logs could be helpful yes.