You can lower your share diff with "d=128" or whatever you want as password, so you submit shares more often you know.
I fail to understand how this is relevant to anything? Share difficulty affects ONLY variance. It has NOTHING to do with reject rates (a miner at 2048 diff vs 64 diff will be discover an identical number of valid shares, statistically speaking).
Appreciate the link. I did read everything on the site, and this entire thread before I directed any hashing power here, however.
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).
Be nice if it was true... So far it certainly doesn't seem that way. You want fair? Then you need to implement a straight forward reject scheme such as, "shares submitted >1200ms after validity will be rejected". If you base rejects on the last block found, then you will never have a fair system, because that fairness will be completely destroyed when low-diff coins are mined. Otherwise, the highest BTC/MH job won't actually yield the highest BTC/MH, rendering this pool's entire work prioritization scheme broken. If the pool it putting enough hashrate on a job to orphan it's own blocks (I saw at least a dozen shares from my rigs that were valid blocks get rejected in under 2 minutes at one point!), then the pool is not operating optimally or IMO even within acceptable operating tolerances.
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.
Try 10% minimum. With properly tuned rigs that average <1% on most constant coin pools, and <3% on multi-pools, over the last 24hr I am getting >10% rejects here. And for several periods where there were high-diff coins getting mined... it was > 40% rejects for several minutes!!!
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.
It is the amount that the person mining has to "swallow" when mining at a multi-pool, definitely! The person MINING at the pool must swallow, being key. The buyer is the person mining at a pool in this case, and they should be swallowing the cost of rejects due to their pool choice. NOT the miner. Otherwise, you need to allow miners to exclude jobs, or only select the jobs they want.
Anyway - stale shares validation is currently being tested - will let you know when it's fully implemented.
Glad to hear this is still being worked on. I will definitely keep an eye and a few MH here for monitoring purposes.
---
Overall tho, I have to warn the majority of miners to be careful of this pool for now. Due to the "we penalize only the miner for rejects" scheme, even with a properly tuned rig at low intensity you will see > 10% rejects at NiceHash.com. I provided a large portion of his pool's hashing power (around 10%) for over 24 hours, and my with response tuned miners (low intensity, tuned down even), reject rate has been >11% on average. This is completely unacceptable and needs to be fixed. I would have made more mining at WafflePool for the same period, once you account for the reject rate.
NiceHash badly needs to adjust their reject scheme to at least partially penalize the buyer for choosing a high-reject pool or coin before this can possibly be a viable system. Penalizing the hash provider based on the buyer's decision to mine a low-diff shit coin is absolutely ridiculous. It would make significantly more sense to charge based on average reject rate, vs 0% reject rate.
---
I think your definition of "valid" hashpower needs to change if this model is to remain viable. And I say this not because I wish to attack this site, but rather because I would like to see it succeed.
---
One more question:
The pool regularly stops accepting hashes for up to 10 seconds at a time:
[17:22:13] stratum.nicehash.com not responding!
<...>
[17:22:22] Work available from pools, resuming.
I presume this happens on job switches due to an inefficiency in the stratum implementation? Regularly losing 10 seconds of work sucks quite badly, and is costing rigs here an extra percent or so of potential profit.
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" 
