OK, so we were very busy in the past hours due to several service upgrades. Notably the most important is the option to limit the hash power. Behind the scenes some other features have been added to lower rejects, improve efficiency and allow miners to set lower diff.
Providers/Sellers:I see the majority of the questions are regarding how providers are assigned to orders. For now this is simplified and we are using the option that is most suitable for now (keep in mind that our service is still young!) and this is round-robin. Providers are randomly assigned to orders in a round-robin fashion to provide fairness between providers. This means that you'll be mining a certain amount of time on lower paid orders and a certain amount of time on higher paid orders. Since we are doing round-robin providers will be more or less equally distributed among different orders which does guarantee fairness between providers. Although there still might be some slight difference at the end of the day. Differences between prices are relatively low - a couple of percents between highest and lowest paying
active order (10% in max for a
very short time between order switching) and if we take into account round-robin "fairness" you should see <1% difference between providers payments (in a daily average).
However, since we strive to 100% fair game, we're already working on a even better solution. What we're trying to do is to implemente a scheme where all workers are getting paid for their portion of work completed irrelevant of what task it was on. However, this is not at all a trivial task. There are several issues we are facing; orders are dynamic, can be canceled at any time, providers are dynamic, and there are tons of shares to be processed at any time which bring us to the issue of the "precision" of IEEE double precision floating point if we're to calculate the pricing distribution for each an every single share that is being processed through our system. It is doable, but first we have to mathematically prove that our algorithm is correct and then we have to do test on real examples to see what kind of error are we getting due to rounding.
I would just like to stress out that the current round-robin scheme is doing very good in average. It's also worth noting that any kind of multi-pool is having similar issues (immature/unexchaged/rounding precision) ... it is very very hard to do an absolute 100% fair game for all providers. But hey - what's important is that you're getting paid a
good price for your hash power. It shouldn't really matter if you're paid 1% more than your friend in the morning while in the afternoon it will be vice-versa, and at the and of the day you'll both be happy
Buyers:Calculations:
BTC/GH/Day = BTC/1000*MH/Day
BTC/TH/Day = BTC/1000*GH/Day
How much time will I get for a specific amount of BTC at a specific rate?
Time in
days = (amount BTC / speed GH) / rate BTC/GH/day
Example: I wanna pay 0.05 BTC at 5 BTC/GH/day for 0.1 GH of speed
(0.05 BTC / 0.1 GH) / 5 BTC/GH/day = 0.5 BTC/Gh / 5 BTC/GH/day = (0.5 / 5) day = 0.1 day = 2.4 hours
You'll get 2.4 hours of 0.1 GH speed for 0.05 BTC at 5 BTC/GH/day.
Will add this calculation on the order submit page today.
Order submission:
What we're seeing is an excessive fight for the "unlimited" hash power. We're happy to see this, however very small/short orders are killing the efficiency of the system. Therefore we'll probably have to introduce minimum time frame for the duration of your order at submit time (you'll still be able to cancel it at any time, though). It's pointless to run a 1.5Gh/s job for only 15 minutes, this only messes-up the orders and probably isn't efficient for you as well (we're thinking about 0.5h minimum time at submit time). We'll also consider the upper limit for order speed in dependence of the total available speed (for example, max speed 1GH if 1.5GH is available, 2GH if 3 GH is availabe ... 7 GH if 10GH is available, etc.).
Providers/sellers and buyers! Please keep in mind that NiceHash is still a novel system and we'll try to adapt to both of you to make a service as valuable as possible for both of you!
Thank you for using NiceHash!
btw:
more providers are needed, currently there are good priced orders!