Quote from: poolwaffle on February 10, 2014, 04:54:02 PM

Quote from: Vbs on February 10, 2014, 04:14:26 PM

poolwaffle, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

This should minimize stales.

Yep. We send it on every work change request that isn't difficulty adjustment (which we send again after 30 seconds with the flag if the user isn't respecting the new difficulty).

But we're seeing a TON of shares submitted a significant amount of time after the clean jobs request. A lot of them 15-20 seconds after telling them the old work isn't valid, and those shares are still being accepted, which leads me to the guess that people have pushed their miners to max out hashrate (and in this case accepted shares) rather than actual accepted shares.

I see.

Since avg_time_block = (coin_difficulty * 2^32) / pool_hashrate_on_coin, you could, for example, reject stale share submissions after avg_time_block doubles (meaning more than 50% of the pool has already switched over to the new coin).

Quote from: qsrab on February 10, 2014, 05:31:01 PM

If the 1 block old shares have any chance of resulting in a valid block (they do) they should be accepted! Rejecting them only makes profitability "look" higher while it is actually lower. You were the only pool doing this right don't be like the crap pools!

The problem is the probability of finding a block in the old coin tends very quickly to zero, as less and less miners are mining the old coin.

Once more than 50% of miners have switched, stales should be discarded. Tongue