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

[ustcstone]

suggestion:if one order is dead,and then back to live,this order shoud be list under the other same price orders....

It is. But when it is dead, it is moved down the list under among dead orders.

but it's not! when a dead order come back to live,it will not be under the other same price orders but come to it's old place。

[Joe9]

You could split SHA256 / Scrypt to westhash and keep the other algos on Nicehash? The current solution needs to be rethought

[BombaUcigasa]

We offer 1 BTC bounty to whoever can come up with ideal solution how to "disperse" the system while keeping following intact:
- low rejects (same entry+exit point for all shares)
- ability for customers to select location of their order

Now let's see if someone comes out with something constructive 

I'll come up with something slightly constructive but hard to implement

Miners can be geolocated when they connect to any port, and they can be prioritized to contracts based on their location (some kind of priority list for areas (NW, NE, EU, CN).

Target pools can be geolocated when they are being connected to and have this location presented as a priority for the miners mentioned above.

Have a calculated switch point (say 10% extra or whatever is the reject rate plus a bit) for fulfilling orders based on price and not location (if NW pays more than EU by 11%, switch EU miners there).

You are already switching miners based on capped hashrate, you can just add this into the switching mechanism.

[nicehashdev]

We offer 1 BTC bounty to whoever can come up with ideal solution how to "disperse" the system while keeping following intact:
- low rejects (same entry+exit point for all shares)
- ability for customers to select location of their order

Now let's see if someone comes out with something constructive 

Ugh I wish I had an answer for that...but the ability for customers to choose where...couldn't you just put an option in the order?

Idk how like btc guild or other pools do it but why wouldn't it work for you guys? Why do you need super low reject? I'd be happy with under 5 percent rejects if it keeps this all together... Hehe did ya try to just proxy the U.S.server to yours?

Did you offer that bounty cause you already know it is impossible?

What is the point of proxifying from US to EU? Then we might just keep NiceHash and nothing else. This is not a solution.

Bounty is offered, because we, after moths of discovery, didn't come up with any better solution - but maybe there is someone smarter and can give us an idea, so we went with solution that is best for buyers - buyers are the ones that bring money to the table here, so we should never neglect them.

[nicehashdev]

We offer 1 BTC bounty to whoever can come up with ideal solution how to "disperse" the system while keeping following intact:
- low rejects (same entry+exit point for all shares)
- ability for customers to select location of their order

Now let's see if someone comes out with something constructive 

I'll come up with something slightly constructive but hard to implement

Miners can be geolocated when they connect to any port, and they can be prioritized to contracts based on their location (some kind of priority list for areas (NW, NE, EU, CN).

Target pools can be geolocated when they are being connected to and have this location presented as a priority for the miners mentioned above.

Have a calculated switch point (say 10% extra or whatever is the reject rate plus a bit) for fulfilling orders based on price and not location (if NW pays more than EU by 11%, switch EU miners there).

You are already switching miners based on capped hashrate, you can just add this into the switching mechanism.

Don't forget to incorporate how are miners rewarded in this system (must be fair - like it is now - and not by order miner is working on).

[crashoveride54902]

We offer 1 BTC bounty to whoever can come up with ideal solution how to "disperse" the system while keeping following intact:
- low rejects (same entry+exit point for all shares)
- ability for customers to select location of their order

Now let's see if someone comes out with something constructive 

Ugh I wish I had an answer for that...but the ability for customers to choose where...couldn't you just put an option in the order?

Idk how like btc guild or other pools do it but why wouldn't it work for you guys? Why do you need super low reject? I'd be happy with under 5 percent rejects if it keeps this all together... Hehe did ya try to just proxy the U.S.server to yours?

Did you offer that bounty cause you already know it is impossible?

What is the point of proxifying from US to EU? Then we might just keep NiceHash and nothing else. This is not a solution.

Bounty is offered, because we, after moths of discovery, didn't come up with any better solution - but maybe there is someone smarter and can give us an idea, so we went with solution that is best for buyers - buyers are the ones that bring money to the table here, so we should never neglect them.

can we get a list of what you came up with it and why it doesn't work so we're not coming up with the same ideas

Just trying to help

[BombaUcigasa]

What is the point of proxifying from US to EU? Then we might just keep NiceHash and nothing else. This is not a solution.

Bounty is offered, because we, after moths of discovery, didn't come up with any better solution - but maybe there is someone smarter and can give us an idea, so we went with solution that is best for buyers - buyers are the ones that bring money to the table here, so we should never neglect them.

The same point for which Westhash exists. The point is to reduce lost efficiency by directing US miners to US pools and EU miners to EU pools.

The bount is a good idea, I hope someone provides what you seek.

Don't forget to incorporate how are miners rewarded in this system (must be fair - like it is now - and not by order miner is working on).

Just like now, all servers will have their own payout rates, but since you have that 10% switch condition, the reward difference will never be more than 10%. So it's fair. You can even set the same rate on all servers and have some users subsidize ~5% to other users at various times.

I can't see what other requirements you ask for at the moment, but thanks for taking my points into consideration.

[crashoveride54902]

I don't know why you can't just load balance the front end on both servers and just have us/eu miners connect to the way it is now and just have the order system tell where the mining should come from and send it to that server....Ya I'm totally lost on understanding any of this

[nicehashdev]

We got possible solution over email and it goes like that:

We create round rewarding, where for 5 minutes no miner is being paid, but orders are being depleted for each share submitted. At the end of 5 minute time, both stratums report round balance and number of shares. Then each stratum rewards own miners according to number of shares provided in this 5 minute window. This could work and unify prices across both stratums. We will further analyse this idea and implement if it turns out to be a suitable one.

[crashoveride54902]

We got possible solution over email and it goes like that:

We create round rewarding, where for 5 minutes no miner is being paid, but orders are being depleted for each share submitted. At the end of 5 minute time, both stratums report round balance and number of shares. Then each stratum rewards own miners according to number of shares provided in this 5 minute window. This could work and unify prices across both stratums. We will further analyse this idea and implement if it turns out to be a suitable one.

well gratz to that email then lol least i can say i was close not knowing anything about running a web server or pool

[crashoveride54902]

are you trying the new system? all my miners at 32 diff rate and stat page shows a big dip in hashrate?

[ustcstone]

wtf！someome has all the price orders,like 0.01-0.50,to control the price!

[nicehash]

Important information for ASIC miners

Many ASIC devices are using older versions of mining sofware. Some of these versions are not compatible with NiceHash due to extranonce2-bug (resulting in 99-100% rejects) and most of them doesn't support advanced stratum extranonce subscription for better efficiency (no disconnects).

We have prepared a guide that provides a solution for these issues. By using a lightweight opensource stratum proxy you will be able to overcome the extranonce2-bug and also enable extranonce subscription, resulting in optimal performance and best payouts.

Besides optimal performance and best payouts you'll also get other added value features like single-point management, REST API (pool monitoring, change pool priority, workers stats and much more) and friendly Web-Based client with hashrate graphs.

Take a look at the guide here: https://www.nicehash.com/docs/connect-via-proxy/ and report if it works for you.

Thanks for using NiceHash & WestHash!

[Hyacin75]

I'm consistently getting about a 10% lower hashrate from Nicehash than multipool.us ... I thought it may have just been network related, but I just noticed most of my rejects say this -

Code:

 [2014-07-27 21:47:48] Rejected 3235311f Diff 1.3K/512 AS2 0 pool 0 (Invalid ntime rolling.)
 [2014-07-27 21:47:50] Accepted 0963b632 Diff 6.98K/512 AS2 0 pool 0
 [2014-07-27 21:47:52] Accepted 0eaf3303 Diff 4.46K/512 AS2 0 pool 0
 [2014-07-27 21:47:53] Accepted 2f8a9177 Diff 1.38K/512 AS2 0 pool 0
 [2014-07-27 21:47:55] Rejected 1cc9bed3 Diff 2.28K/512 AS2 0 pool 0 (Invalid ntime rolling.)
 [2014-07-27 21:47:56] Accepted 7f3e1e32 Diff 515/512 AS2 0 pool 0
 [2014-07-27 21:47:58] Rejected 59d3794f Diff 730/512 AS2 0 pool 0 (Invalid ntime rolling.)

I'm guessing that's what is killing my hashrate ... any known fixes for this?  There's VERY little information online about rolling ntime period, and pretty much nothing about shares being rejected with this error ...

Antminer S2 running cgminer 4.3.5.

Now I'm producing invalid shares and being directed to the FAQ with that same miner ... did you change the way the pool handles invalid ntime?  If so the FAQ could use an update because it doesn't address this specifically ...

Are you getting 100% rejects with share above target?

I'll have to check again ... will let you know!

[Hyacin75]

Are you getting 100% rejects with share above target?

I'll have to check again ... will let you know!

~10% rejects with 4.3.5 on the S2 now ... very reasonable!  Great job! 

[Hueristic]

We offer 1 BTC bounty to whoever can come up with ideal solution how to "disperse" the system while keeping following intact:
- low rejects (same entry+exit point for all shares)
- ability for customers to select location of their order

Now let's see if someone comes out with something constructive  

Run buy from original database and use the distributed servers for the forwarding of work.


Also I think It's time we fixed NiceHashDev's trust rating. I have never seen Nicehash screw someone.

[nicehashdev]

Are you getting 100% rejects with share above target?

I'll have to check again ... will let you know!

~10% rejects with 4.3.5 on the S2 now ... very reasonable!  Great job! 

Can you check what kind of rejects these are? Job not found or something else?

[Hyacin75]

~10% rejects with 4.3.5 on the S2 now ... very reasonable!  Great job! 

Can you check what kind of rejects these are? Job not found or something else?

Looks like they're all job not found.  Anyone have any tips on reducing those?  Scantime and expiry I'm guessing?

[StuffOfInterest]

OK, here is an idea for unifying the service.

First off, have regionalized stratum servers such as northamerica.nicehash.com, europe.nicehas.com, and asia.nicehash.com.  Hash providers should connect their miner to the server with the lowest round trip time.  Would be nice if the NiceHash website provided a tool to help find it.

When a buyer submits an order, they should specify a preferred server to service the order but the order book should be a single list across all of NiceHash.  One additional option would be to allow a buy to limit their order to only being serviced by the specified server or from any available.

As the orders are parceled out, the highest order gets first try at it's specified server.  As you work down the list if an order can't be fully serviced by their specified server then, if they have set the order to allow it, service from any other available server.  Delay and rejects may be higher in this scenario but if a buyer wants to avoid that they can either up their price to get higher in the queue on their preferred server or set the "no float" option and accept that their order may not get run as soon.

With a unified price queue there is not as much incentive for providers and buyers to chase the best price of the moment.  Providers will go to the server closest to them for the best performance.  Buyers will set a preference for their nearest server but will deal with more round trip delay if they are in a hurry to get their order serviced.  Market forces will have a much bigger play here as the higher an order price the quicker it gets serviced across the entire system.

[nicehashdev]

~10% rejects with 4.3.5 on the S2 now ... very reasonable!  Great job! 

Can you check what kind of rejects these are? Job not found or something else?

Looks like they're all job not found.  Anyone have any tips on reducing those?  Scantime and expiry I'm guessing?

Scantime is useful only for getwork. Nothing you can do here, but to try WestHash (if you are located closer to US West). Job not found are stale shares - your miner is too late.