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

[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 

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

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