Hi,
Some users were complaining about improper orders sorting, so here I'll explain in details the logic of orders sorting. Sorry for the late replay, but we had to double check the algorithm on our test systems. There is nothing wrong with orders sorting, it just needs a bit of additional explanation. The logic of orders sorting is not trivial. We'll also add a separate FAQ for this topic.
1st Rule: First-Come-First-Served with price evaluation.
2nd Rule: Miners switch to better paying orders gradually not instantly (to prevent too frequent disconnect and work restarts on miners).
Example 1:Let's presume currently there are a couple of running orders:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #11 @ price 0.8
no limit
running (all remaining miners)
Order #15 @ price 0.7
no limit
in queue
Order #10 @ price 0.5
no limit
in queue
Event: Order #11 was finished, new list:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #15 @ price 0.7
no limit
running (all remaining miners)
Order #10 @ price 0.5
no limit
in queue
Event: Order #10 is edited at price 0.7, new list:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #15 @ price 0.7
no limit
running (all remaining miners)
Order #10 @ price 0.7
no limit
in queue
Order #10 stays in queue even if it was submitted
before Order #15, because Order #15
was first to set higher price. This is to prevent placeholders one would submit placeholder orders with very small prices and then would just increase price when the opportunity would be good and thus overtake all other bidders with initial
same pricing. We don't support this, because it is not fair. The first that sets a particular price will be first served at that particular price. No overtaking at same price level (the same logic is used by cryptocurrency exchanges).
Example 2:Let's presume currently there are a couple of running orders:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #11 @ price 0.8
no limit
running (all remaining miners)
Order #10 @ price 0.7
no limit
in queue
Event: A new order Order #13 is added at price 0.9 (the same logic would be if this would be edit of an existing order by increasing price at existing order), new list:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #13 @ price 0.9
no limit
waiting (waiting for miners)
Order #11 @ price 0.8
no limit
running (all remaining miners)
Order #10 @ price 0.7
no limit
in queue
Note that even if Order #13 is set at higher price it's still waiting for miners. It will take several minutes before miners will start to get assigned to new order (to prevent too frequent disconnect and work restarts on miners). New list after some time:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #13 @ price 0.9
no limit
running (some miners)
Order #11 @ price 0.8
no limit
running (all remaining miners)
Order #10 @ price 0.7
no limit
in queue
After some more time:
Order #12 @ price 0.9
1 Gh/s limit
running (100 miners)
Order #13 @ price 0.9
no limit
running (all remaining miners)
Order #10 @ price 0.7
no limit
in queue
Notice that order Order #11 is finished and out of the list. Even if it was lower paying than Order #13 it was finished before because obviously the order budget was spent meanwhile miners were switching to other order(s).
Keep in mind that order/miner switching is even more diverse when there are lots of orders and lots of price changing. In such times one must be patient and carefully monitor the situation. Also, keep in mind that NiceHash doesn't provide it's own hashing power but redirects hashing power from external providers. This way we are able to provide buyers with hashing power on demand, but on a bidding basis and gradual miners switching. Gradual miners switching protects miners and ensures higher efficiency - even at the cost of slightly, but truly slightly lower paying average - efficiency is more valuable and eventually brings better profits for providers. This concept gives attractive pricing for buyers and good payments for providers, but of course can't provide real-time (true on-demand, at click time) hashing power. Usually the ones that are able to predict these "hot" times and are able to bid prices high enough in advance are best served. We also welcome you to utilize our API
https://nicehash.com/index.jsp?p=api which will allow you to automate orders handling and make buying hashing power at NiceHash even more effective.
BTW: we did rigorous testing to provide proper order sorting but if you still encounter some cases that doesn't comply with the rules, described above, please let us know via email to
info@nicehash.comExample: last night I put in an order for 1.0. With a maximum of 2gh. I never got the 2gh filled yet below me there were orders of 0.8 completely filling up to 3gh and their order was placed AFTER mine.
TheFridge Are you sure this was a
new order for price 1.0? If you were editing existing order, that this would explain the described behavior. If not please send us your order# as well as other order#s (if you have them) to
info@nicehash.com. Thanks!
Thanks for using NiceHash and we all wish you nice hashing!
Show Posts
. Attackers are always one step ahead and we, service providers have to constantly improve our services for our customers to be satisfied. Keep in mind that NiceHash is not like ordinary multipool. We are exposed in two ends - at stratum server and at web frontends (because of two-ways users interaction). Also, our service is still novel and obviously some features need to mature to make them rigorous enough. Our motto is to provide easy service for providers with the ability to use one service for multi-algorithm mining and at the same time easy service for buyers to get hashing power on pay-as-you-go basis - and we'll keep it this way. Thanks for your support!
