You want to buy 100 Mhs Scrypt and you are willing to pay a total of 0.05 BTC at 5 BTC/GH/day. How long will your order run for?
(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.
You want to buy 100 Mhs Scrypt for 1 day at 5 BTC/GH/day. How much will it cost you?
1 day * 0.1 GH * 5 BTC/GH/day = 0.5 BTC
It will cost you 0.5 BTC for 0.1 GH speed at 5 BTC/GH/day for one day.
Note: These are just examples, you can use the formula for your own calculations or you can simply log in and check the automatic calculations before placing a new order.
Miners switch to a better-paying order gradually - not instantly. This is to prevent excessive "order-jumping" because, due to some stratum protocol limitations, a miner has to be disconnected before it can serve another order again. Too many disconnections would affect the miner's performance (more work would be performed on the backup pool, plus when the connection is dropped, there is a chance of shares being lost). Thus, two limitations were put in place:
The term you pay for "accepted" shares refers to shares that are determined as valid by the NiceHash system (see also: How exactly does pay-per-valid-share and get-paid-per-valid share work?). Validation of shares on NiceHash is mandatory in order to avoid any possible cheats, such as fake/modified pools or similar.
There are 3 possible stability states of your pool:
Keep in mind that the current hashrate, as displayed on the NiceHash.com front page, is not the total available hashrate. Keep in mind that some hashrate providers (sellers) are setting their price threshold a bit higher - usually a bit higher than popular multi-pools are paying. This hashrate is "hidden" but could be available. Therefore, to be able to leverage the full power available at NiceHash, you should probably bid a bit higher than multi-pools are paying. Of course please take this merely as a suggestion from us and please adjust your pricing to fit your individual needs.
The NiceHash stratum engine implements an innovative algorithm that detects the shares' validity and the pool's stability. Our goal is for the providers to be 100% paid for all valid work that their rigs produce (just as using any ordinary pool or multipool) and that buyers pay 100% only for valid work that has been submitted to the buyers' pools (just as it would be using their own rigs).
When a provider submits its work (a share) to NiceHash, it is validated by our stratum engine and validator.
A) If a share is validated by our engine but is rejected by the buyer's pool (by stratum protocol definition), this means that there is something wrong with the pool (whether it's misconfigured, using the wrong algorithm, or has temporary micro issues) and the provider's work was valid. In this case, the provider gets paid for the work they provided. So, in this case, it is the buyer's responsibility to switch to other pools. However, if the provider's rig is misconfigured and is producing some (not necessarily all) invalid shares, these shares are detected by our engine and for those shares, the provider doesn't get paid (and the buyer doesn't pay for them) because it's the provider's responsibility to provide properly configured and stable mining rigs. These kinds of bad shares are usually produced by over-clocked/overheated/misconfigured rigs (there are usually 0% of this kind of invalid shares for good or normally configured rigs and approx. 1 to 5% of this kinds of invalid shares for badly configured rigs).
B) Our engine additionally checks the responsiveness of the buyer's pool. When a buyer's pool becomes unresponsive (pool being DDoSed, the pool is having performance issues, etc.), the engine immediately disconnects this pool, deactivates the buyer's order and reroutes the work to other pools/orders. In this case, the buyer isn't paying any more (their order is on "pause"), and providers are selling their work to other orders (no hashrate is lost, but providers might notice a quick disconnect/reconnect on their miners). This detection is much faster than ordinary mining software detection (cgminer, etc.) and, therefore, buyers pay less than they would be paying by renting physical rigs(which is usually time-based) - even if they had set up backup pools. The buyer can set multiple orders with multiple pools and thereby ensure that the majority of their orders will get processed even if some of the pools are unstable.
C) Some buyers' pools are generating lots of work restarts. This is usually a symptom of coins with very low difficulty or multipools that are switching coins very fast and don't have an efficient implementation of coin switching. In some cases, this is also a result of some custom private pools. Excessive work restarts reduce the efficiency of miners, especially on fast ASIC miners with weak controllers. We have addressed this issue by rewarding providers (sellers) with extra shares paid by buyers when fast work restarts occur. If you are a seller, it is very important for you to monitor the average mid-term hashrate that is reported on our website (it is calculated from shares rewarded to your miner) and the actual earnings, not only the hashrate or accept/reject ratio that is displayed by your miner hardware/software, since in some cases you will be rewarded for more than your miner is showing you in terms of the hashrate.
In essence, this means that the provider is 100% paid for all valid work that their rigs produce (just as using any ordinary pool or multipool) and the buyers pay 100% for the valid work that has been submitted to buyers' pools (just as it would be using its own rigs).
It's a 100% fair game for sellers and buyers.