Quote from: MintCondition on August 18, 2011, 01:58:19 PM

There are definitely pools that do this. Actually, *all* non-PPS pools that purport to be paying for stale shares, actually don't. I do understand the confusion, since it also took Us some time before I realized that pay-for-stales claims can not ever lead to extra earnings at non-PPS pools.

Slush's pool for example has no LP, so it can not possibly notify its workers of a new block. Practically this means those workers do stale work ~3% of the time, although Slush accepts most of these stale shares as valid shares. They therefore report a 0.3% stale rate. Total block reward will be the same 50 BTC in the end, and since everyone has approx. 3% extra shares, payout per user is still the same. Only everyone thinks they get payed for stales.

On the other hand, any PPS pool would shoot itself in the foot if it was reporting a lower stale share amount than was actually the case: It would mean they now also have to pay the promised per share amount for those 'fake valids', whereas normally those would be worthless. The aforementioned dilution effect does not exist at PPS pools, since there is no 50 BTC block reward to be distributed (just the pay per share).

For ABCPool, this goes even further: since we pay as much for stale shares as we do for valid shares, your earnings would be exactly the same if we report 0% stales, 0.5% stales or 100% stales.

For more info, see http://www.abcpool.co/stale-shares.php.

NB: SMPPS, ESMPPS, or other PPS-like reward methods are just as vulnerable to this issue as Prop or PPLNS pools. Even Solo mining has a stale rate, which is reflected in the number of orphan blocks found over time.

NB2: The 'secret' behind real low stale rates is having a highly connected bitcoind running so you are quickly notified of new blocks, wherever they may come from.

After I wrote that a bit later I realized it might have sounded accusatory or advasarial and I apologize for that. It was not my intent, but by that time it was already out there and editing it would have been pointless. However, the contention in the message still stands and I'm not seeing where there's a rebuttal in so far as providing anything to refute the fact that you simply aren't reporting the stale/invalid shares even though they exist.

I said as much that it's great that you are paying for stales and being a PPS pool, it's a definite advantage - I have absolutely no argument with that. But whether or not you report it is immaterial to the fact that you are paying for stales - you pay for them either way, so it is to your advantage to NOT report them to give the illusion that you have a better (lesser) reject rate than other pools.

I'm not sure you understand how LP works when talking about stales in relation to LP. It's completely immaterial how connected your bitcoind is or how quickly your bitcoind gets notified of a new block - your bitcoind and pushpool (if you are using pushpool or something else, it doesn't really matter) are a little microcosm of the larger network. All that matters for LP and stales is when pushpoold is notified of a block change, the LP is pushed out and the workers receive new shares for the block bitcoind is currently on. The Bitcoind -> Work Distribution Server interaction are all that matters. Bitcoind is going to be doling out the getworks to your getwork server based on what it thinks is the current block. Your bitcoind could be 10 blocks behind and that will not have an effect on your stale count because your getwork server is serving up what bitcoind thinks is the latest block and submitting it back, which bitcoind tests against what it thinks is the current block. If your bitcoind is behind and you find a hash that fits, it will then submit it to the network and get an orphaned block because it was behind.

So again, I still content that you are either not reporting the actual number of stales or you've found some magical new method to a) reduce latency between your getwork server and bitcoind by a factor of two or three and more importantly b) found a really magical method to notify all miners of new work with less latency by several orders of magnitude.

Since you have no control of the links between your getwork server and the miners, and you have no control over the miners and their systems, it would really be a magical method to reduce your stale shares beyond possibly maybe 2% maximum at a theoretical limit. If you gain control over those system, then yes you could reduce that further, but barring controlling the entire system, with the current GPU miners out there, you simply can't reduce it beyond that threshold because of built in problems with the protocol in general.