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

[kenshirothefist]

Just to clarify: sgminer for Gridseed will not happen:
https://github.com/veox/sgminer/issues/154

Huh, didn't realize that That's quite sad. Not nice to be a GridSeed user these days, latest cgminer is not an option since it's declared as "non-scrypt" and sgminer is not an option since it's declared as "opencl-only" That leaves only two options: encourage luke-jr to incorporate GridSeed support into latest BFGminer or fork cgminer-3.7.2+upstream patches with GridSeed support and create "gsgminer"

p.s.: there are already NiceHash supported options for GridSeed users, see here: https://www.nicehash.com/index.jsp?p=faq#faqs0

[1714862093]

1714862093

[1714862093]

1714862093

[1714862093]

1714862093

[1714862093]

1714862093

[1714862093]

1714862093

[evolvia31]

Hi,

Your pool/concept is very amazing.

I put all my miner on it (~10Mhs).

But if you can solve the only problem that's will be perfect
When your pool switch to job there is a disconnection with the stratum server, if you can remove this disconnection
During 5-20 secondes rigs don't mining in order to reconenct the stratum server.

[kenshirothefist]

But if you can solve the only problem that's will be perfect
When your pool switch to job there is a disconnection with the stratum server, if you can remove this disconnection
During 5-20 secondes rigs don't mining in order to reconenct the stratum server.

Yeah, we're aware of it. This is also what phzi was talking about a couple of posts back. The issue is with the stratum protocol, which currently doesn't support changing the extranonce1. Therefore currently the only option is to disconnect a rig in reconnect it to new order. We'll see if we'll find a technical solution for this. However, another, organizational solution is already being implemented - will make sure orders don't switch too fast. There will be a minimum order time frame (not too long though, allowing for the buyers still to be flexible) and the possibility for order hash limit. This will allow more concurrent orders, less order switching and will make hash power providers to stay on single order for longer time. Will not be perfect, there will still be some disconnects form time to time. But at the end of the day we have to make some trade-offs between optimizations for sellers&buyers (we want to make a ~100% fair game for sellers&buyers). Stay tuned!

[evolvia31]

thanks to your fast answer.

Take your time to find the best solution to buyer and seller.

[phzi]

Yeah, we're aware of it. This is also what phzi was talking about a couple of posts back. The issue is with the stratum protocol, which currently doesn't support changing the extranonce1. Therefore currently the only option is to disconnect a rig in reconnect it to new order. We'll see if we'll find a technical solution for this.

It's possible to fix =).  Multi-pools have had this issue in the past.

However, another, organizational solution is already being implemented - will make sure orders don't switch too fast. There will be a minimum order time frame (not too long though, allowing for the buyers still to be flexible) and the possibility for order hash limit. This will allow more concurrent orders, less order switching and will make hash power providers to stay on single order for longer time. Will not be perfect, there will still be some disconnects form time to time. But at the end of the day we have to make some trade-offs between optimizations for sellers&buyers (we want to make a ~100% fair game for sellers&buyers). Stay tuned!

Sounds like a good plan.

---

I was just replying to your comment that everybody should switch from cgminer to sgminer - that's valid for GPUs only.

bfgminer has scaleability issues on Windows. Can't run more than a couple of instances, can't run more than ~20 miners. But that's another story, it's not a problem with nicehash.

I said everyone should stop using outdated mining software, and gave an example in sgminer.  Yes, sgminer is opencl only.  bfgminer would be an appropriate solution for miners with other hardware.  I have no doubt that there are scalability issues on Windows... I also have no idea why anyone would run windows on a dedicated mining rig.  And if you're using gridseeds, then a Pi is probably a better host platform solution.


---

Looks like the stratum is completely offline right now? - my miners all just fell back to a failover pool.

Nicehash.com not loading now either.

[kenshirothefist]

Yeah, we're aware of it. This is also what phzi was talking about a couple of posts back. The issue is with the stratum protocol, which currently doesn't support changing the extranonce1. Therefore currently the only option is to disconnect a rig in reconnect it to new order. We'll see if we'll find a technical solution for this.

It's possible to fix =).  Multi-pools have had this issue in the past.

Hmm, stratum protocol actually doesn't support changing extranonce1 without disconnect, so I'd be very glad if you know how multi-pools solved this. And than again, NiceHash doesn't operate as a multi-pool behind the scenes, it's a quite different approach. But if you have some hint or a link please post it.

[grendel25]

Hi, I recently joined.  Looks like it mined for a while but then went to all zeroes after first payment?  My bfgminer shows like it is still connected and trying to work but no accepted shares. 17vNQiv5zTQ7sAhKMqmCiZzYg1FWozDG4x

I will try a restart of my miner but this issue needs fixed...

Thanks

[kenshirothefist]

Hi, I recently joined.  Looks like it mined for a while but then went to all zeroes after first payment?  My bfgminer shows like it is still connected and trying to work but no accepted shares. 17vNQiv5zTQ7sAhKMqmCiZzYg1FWozDG4x

Maybee your miner wasn't able to reconnect after a connection failure ... make sure you have properly configured backup pools, stable internet connection, etc. ... PM if you have some other issues.

[kenshirothefist]

Dear users, thanks for bringing us at 1+ GH/s! We'll introduce a small fee in the next days. NiceHash will charge a processing fee from each party of hash rate trade made through the service. Our fee is as low as 2%. In the future the amount of the fee will vary based on a 30 day volume with discounts for the fee to be as low as 0.5% (we'll introduce fee schedule later). Thanks again and wish you all Nice hashing!

[grendel25]

Hi, I recently joined.  Looks like it mined for a while but then went to all zeroes after first payment?  My bfgminer shows like it is still connected and trying to work but no accepted shares. 17vNQiv5zTQ7sAhKMqmCiZzYg1FWozDG4x

Maybee your miner wasn't able to reconnect after a connection failure ... make sure you have properly configured backup pools, stable internet connection, etc. ... PM if you have some other issues.

Never had that issue on any other pool and there were a lot of other miners at zero.  Please answer back when you have a better idea.

[twobitlolz]

cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

-snip-

sgminer lacks GridSeed support, i'm more familiar with the cgminer codebase, sgminer dropped SHA suppport and baked in lots of code that makes it difficult to patch in new algorithms, i get better performance from cgminer 3.7.2 with Kalroth's tweaks, sgminer was susceptible to the client.reconnect exploit last time i checked (fixed by this commit in the latest build), R. M. Davidson's patches don't apply to sgminer out of the box, and my build would be a headache to break into pieces to migrate to sgminer + latest cgminer + misc cgminer forks for other algos. "switch to sgminer" may be a fine solution for many, but not for me today.

The bug we're talking about it related to correct handling of extra nonce 2 (extranonce2, xnonce2) size. In cgminer 2.7.2 xnonce is fixed to 4 ... however by stratum protocol this should be "dynamic/resizable". Well, actually you should ask ckolivas for details regarding that ... I'm not sure in which exact version this was patched but if you can find out I'll be very glad if you'd share the info here.

thanks! i'll drop a patch here when i track down the issue and get around to testing fixes.

Well, what we're seeing here with this cgminer-3.7.2 is similar to WinXP story ... to many users of too old software, and when support ends it's "Houston, we've got problems"

-snip-

similar in the sense that a large part of the userbase didn't like the new direction and chose to rebel against it, but this is free software. cgminer 3.7.2 is still actively improved upon, though unfortunately there's a distinct lack of collaboration among devs, (myself included. )

[grendel25]

cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

-snip-

sgminer lacks GridSeed support, i'm more familiar with the cgminer codebase, sgminer dropped SHA suppport and baked in lots of code that makes it difficult to patch in new algorithms, i get better performance from cgminer 3.7.2 with Kalroth's tweaks, sgminer was susceptible to the client.reconnect exploit last time i checked (fixed by this commit in the latest build), R. M. Davidson's patches don't apply to sgminer out of the box, and my build would be a headache to break into pieces to migrate to sgminer + latest cgminer + misc cgminer forks for other algos. "switch to sgminer" may be a fine solution for many, but not for me today.

The bug we're talking about it related to correct handling of extra nonce 2 (extranonce2, xnonce2) size. In cgminer 2.7.2 xnonce is fixed to 4 ... however by stratum protocol this should be "dynamic/resizable". Well, actually you should ask ckolivas for details regarding that ... I'm not sure in which exact version this was patched but if you can find out I'll be very glad if you'd share the info here.

thanks! i'll drop a patch here when i track down the issue and get around to testing fixes.

Well, what we're seeing here with this cgminer-3.7.2 is similar to WinXP story ... to many users of too old software, and when support ends it's "Houston, we've got problems"

-snip-

similar in the sense that a large part of the userbase didn't like the new direction and chose to rebel against it, but this is free software. cgminer 3.7.2 is still actively improved upon, though unfortunately there's a distinct lack of collaboration among devs, (myself included. )

So you are updating CGminer to work with this pool?  That would be awesome.  I tried SGminer but I don't think it supports both gpu(s) 1/2 at the same time: i.e. my 5870 that runs on GPU threads 1 couldn't run at the same time as my 280x that runs using 2 gpu threads.

I ended up going with bfgminer but I had to scale back the overclock to make it stable and it still isn't stable on one of my rigs so I have to tweak it more. 

Yeah... would be awesome if you are making an update to cgminer.  Anyway I can follow updates/know status?  thx

[bruiser]

Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

[kenshirothefist]

Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

Absolutely agree. Order limiting comming in the next 24 hours! Stay tuned!

[nish2011]

A another nice feature that you could add is the ability to increase your bid instead of having to cancel the order.

[uberua]

Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

Absolutely agree. Order limiting comming in the next 24 hours! Stay tuned!

Does it mean that some rigs will mine with profit let's say 5.3 BTC/GH/Day and some with 5.8 BTC/GH/Day? It will not be fair then.

[hutnik]

Maybe pay the miners weighted average based on how much hashes are going for what price?

That's some serious math

anyway, great service!

[Trestle]

Few comments from a renting perspective:

Pleeease let us limit hash rate. It is cool to see 1GH/s fly over to a pool, but it is really not worth it--especially as you grow bigger. I would much rather be able to calculate and rent 100MH/s for 24hrs instead of getting everything you have for 25 minutes. This is especially annoying because most coins (esp new ones) are not PPS so unless you get incredibly lucky, you're throwing the money away.

This would also allow you to fill more than 1 order at once. If there are 7 people trying to throw BTC at you to rent rigs, it would be nice if you could take all of their money simultaneously instead of just 1 at a time (and risking that person going to another renting site to lock their speed down for set times). I think it would also help so you aren't ping-ponging the hardware around to tons of pools constantly.

Absolutely agree. Order limiting comming in the next 24 hours! Stay tuned!

From a provider standpoint how will this work? Will you have to pay at least what the current set rate is to use that available hash? I would rather not work on a lower rate before the current higher one is depleted.

[seattletu]

please help me understand if i have these calculations right.

if i were to buy hashpower of 0.1 (that's 100mh/s correct?) and spend 5btc at a price of 5btc/day

i would get 100mh/s for 24 hours, is that correct?

also, i would essentially be bidding against other people that are purchasing hash power right? so the higher the price i list, the most likely my offer will get picked up? it looks like there is a wide range of bids, would a bid of say 2.5 btc/day get picked up? it's hard to tell it looks like every bid is being picked up right now.

[insz]

kenshirothefist, can you explain how the hashing power is distributed from the seller's perspective, especially now that there are limits on the GH per job?

For example, which miners are sent to the highest paying jobs? how is that queue determined? when and under what circumstances do miners move from one job to another? is it first come first serve?

Say for example there are 3 jobs, buying at 5.2, 5.3, 5.4. 5.2 is no limit, and 5.3 and 5.4 are limited to 0.1GH. If a new job comes in at 6.0, limited to 0.1GH, which miners move and how is that determined?

On a related note, is it possible to update the page that shows stats for a specific miner to include what job (and perhaps what rate) the miner is working on? The closest to that info right now is in the graph, but it doesn't update that quickly, and at least for me, the speed and price seem to be at around the same height making it hard to read.

I think you've got a great idea going, and hopefully it keeps getting better and better.

Thanks