Only for the BTC that were actually spent on the order. The amount that was not spent is returned without being charged for the fee, of course.

Yesterday's order 2014-04-16 11:17:42 was before fee's (we introduced fee like 20 hours ago, as we announced), so only static one-time order submit fee was applied.

Today we introduced editing of orders (https://bitcointalk.org/index.php?topic=562238.msg6265356#msg6265356) and thus raised static one-time order submit fee (to prevent spamming with orders and to encourage you to rather edit existing orders over canceling/submitting new orders), therefore the calculation for order 2014-04-17 14:56:24 would be:

0.01 - 0.0005 one-time order submit fee = 0,0095 - 2% service fee (0.00069000) = 0,00931

Hope this clarifies your concerns. Thanks for your support and welcome again!

This is explained here  https://bitcointalk.org/index.php?topic=562238.msg6261856#msg6261856 in details, please take a look.

OK, new update has been applied to the service, both buyers and sellers should benefit from this update.

Editing orders:
A) We've finally enabled the ability to edit orders. Now you're able to edit running orders on the fly. You can change the price as well as (optional) max hash limit. This will allow you to bid higher within your's existing orders. As a consequence, miners (sellers) won't be disconnected (basically miners will "travel" with you). Edit: Price is only allowed to be increased (otherwise you'd be able to "pull" miners with you to lower paying order).

Order submition:
B) When adding new order you'll see the approximate duration of the order (time), presuming your order will run at selected speed full time.

With these updates we would like to encourage you to properly limit and update you orders and thus keep the system in high-efficient mode. We've also slightly raised the "new order fee" to prevent spamming with orders and to encourage you to rather edit existing orders over canceling/submitting new orders (of course there is no fee for editing orders).

btw: when you edit your order you can't change the amount of BTC (this can't be done and will probably never be enabled), so we suggest you to load your order with a reasonable amount of BTC for you to be able to make proper bids. Of course, you can still cancel you order at any time with no penalty.

We all wish you nice hashing and thanks for bringing us close to 2 GHs!

The distribution of miners of course doesn't affect buyers. All providers (miners/sellers) are of the "same quality" (NiceHash won't charge you for invalid shares, produced by providers, if there are some). So you get mining power of "equal quality", but of course, if there are too many better paying orders and there are no miners left for lower paying orders, your order will be on pause until better paying orders are processed.


Agree, we don't want for prices to go to the Venera , because this wouldn't be too good neither for buyers nor for seller on the long run. As I mentioned in my previous post we'll introduce some limitations for the service to be attractive to various kinds of buyers. We still wan't to be able to provide massive hash rate to some buyers - that's one of our important features ... but we'll make sure even smaller orders will get its hash rate. Then again, I can't promise you a completely whales-proof system ... it's like in the coin market ... if a whale comes in you just can't stop it, it'll just buy it all ... unfortunately (it's a free market, what can we do...).

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!

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

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!

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.

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.

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!

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

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"

Anyway, the correct path would be to adopt newer software. The absolute correct path would be for the GridSeed community to step together and build modular approach for GridSeed support in sgminer/bfgminer so that it would be easy for veox/luke-jr to include support for GridSeeds in upstream versions. Not sure how to accomplish that though, community/gridseed users should step together for this.

See FAQ "Which miners are supported?" https://www.nicehash.com/index.jsp?p=faq#faqs0 (BFGMiner is supported)

And if you really want to use cgminer, cgminer-3.1.1 (this version doesn't yet introduce the xnonce2 bug) is also supported (https://github.com/gridseed), but I really don't recommend to use these old versions.

The bug we're talking about it related to correct handling of extra nonce 2 (extranonce2, xnonce2) size. In cgminer 3.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.

Well, unfortunatelly we can't support it since it's based on cgminer 3.7.2 which has the known "extra nonce bug". Kalroth should patch it from the upstream versions.

I know Kalroth did a great job with his cgminer branch (even I helped him with testing some early versions...) and it's quite popular. But on the other hand basically all the important patches he introduced were incorporated into recent sgminer versions. Therefore I really dont see any reasons why you wouldn't switch to sgminer (in fact there are many benefits such as easy kernel switching, nFactor support, bugfixes, etc.). Please take a look at https://nicehash.com/index.jsp?p=faq#faqs8

phzi, are you reading my mind? That's exactly what we've been working on recently. We've implemented the first version of reject scheme and now you should see a lot less rejects. We've updated our stale shares detection about 15 minutes ago. Please check the reject rate in the past 10 minutes and let me know if it is any better (also check your graphs stats on NiceHash).


Yeah, this issue was due to "partly-bad" end-point pools ... It's easy to detect when pool is really bad or really good, the tricky part is to detect when pool is "swapping". We also improved this - let me know if you still see "not responding" messages.

Thanks for your feedback!

Sorry, not blaming anyone, just trying to provide fair service for providers & buyers. And yes, it's not perfect yet.

However! We've updated our stale shares detection about 15 minutes ago. Please check the reject rate in the past 10 minutes and let me know if it is any better (also check your graphs stats on NiceHash).

Also, if you're using "--no-submit-stale" option (or ["no-submit-stale" : true] if using conf file) then do not use it anymore. Set ["no-submit-stale" : false] if using conf file or remove "--no-submit-stale" option from your command line. Stale shares shouldn't be submitted since buyers pool won't be able to use them (and you'll get more rejects).

You're partly right about this. Please, take a look at FAQ (you probably already did) "How exactly does pay-per-valid-share and get-paid-per-valid share work?" - https://www.nicehash.com/index.jsp?p=faq#faqg2

We'll make sure it's a 100% fair game for sellers and buyers. Currently we've already resolved all the issues regarding general validation of the shares and this is already implemented. Provider is paid for all valid work it produces (even if some of this valid work is rejected by the buyers pool, because pool is not operating correctly).

What we're currently working on is better validation of stale shares. When a buy order is set to a pool that produces excessive stale shares on the provider side, provider is actually not being paid for those stale shares. However, even without intelligent stale shares detection we're not talking about 50% rejects but more like 5-10% worst-case scenarios. But this is the exact same reject rate that a provider would have to "swallow" if you would be mining on any other pool or multipool which is hitting high-profitability fast-switching low-diff coins. But since our service is about renting (valid) hash power, buyer should pay for all the valid work that he gets, even if these are stale shares (buyer is the one that chooses a pool that produces stale shares) - therefore we'll improve this.

Anyway - stale shares validation is currently being tested - will let you know when it's fully implemented.

There is nothing to worry about this. Please, take 15 minutes and carefully read this FAQ:

How exactly does pay-per-valid-share and get-paid-per-valid share work?
https://www.nicehash.com/index.jsp?p=faq#faqg2

I can assure you this is a 100% fair game for sellers and buyers.

If there is a buy order with a pool for extremely low diff and possibly even on a unstable or overloaded pool, you still will be paid for the valid work you provided, because NiceHash validates your work before it is sent to the pool. You can make sure about this if you check your payouts and your statistics.

It is true - sometimes buyers risks and submits order for extremely low diff and possibly even on a unstable or overloaded pool - but this is their risk (I guess they know what they are doing - hint: biggest profitability can be made when you try to "attack" coin with massive hashrate, maybe even try to fork it or take the majority of network hashrate for yourself). However, they will of course still have to pay for the valid work that was provided by providers, even if pool can't "eat" all the work that has been provided (it's just the same risk as having own rigs or rent dedicated rigs for fixed time). But since there are so many benefits for buyers with NiceHash (no contracts, no time boundary, no risk for failed rigs, etc) they prefer to mine on NiceHash instead of renting dedicated rigs.

It is also true that even if we validate all of your work when we're hitting some very low diff coin, it will happen that the reject rate will be a bit higher on providers side (because rigs actually aren't capable to produce all valid work on very low diff) - but here we're talking about reject rates 2-5% instead of normal 1-2%. But this is the exact same reject rate that a provider would have to "swallow" if you would be mining on any other pool or multipool which is hitting high-profitability low-diff coins. All you have to take into account is this: you might see 2-5% higher reject rates at some intervals (again, look at the graphs on our site, not your sgminer) but you'll get paid 25% more than multipools pays. So it's up to you weather you'll go for a bit lower reject rate, or for a significantly better payout

I hope this clarified your concerns at list a bit. Since NiceHash is an innovative approach to selling/buying hashpower I do understand that there are lot's of thing to be clarified. And probably there will be some exceptions where will have to improve the algorithm - therefore your feedback (from sellers and buyers) is highly appreciated!