UPDATE:
BTW, if you run cgminer please make sure you set --no-submit-stale on your miners, the default with the latest is to submit stales and it will obviously just return reject/stale for you, the proper handling is to dump stales, no idea what the reason is for enabling it by default in cgminer unless someone can enlighten me.
I think it's because stales are usually valid in P2Pool. (Obviously doesn't apply here)
Its still a fairly odd thing to enable by default if it applies to only p2pool thats why I am confused with the switch from off by default to on by default.
My understanding was that it had to do with the new LP behavior. If I'm mining at your pool but I detect the new block from Slush or Deepbit before I get it from you, the share is stale but your pool might still accept it.
Fair enough, but all I notice with this behaviour is rejected shares 100% of the time and many users are critical over stale percentages thus this doesnt help the visual appearance for having stales submitted after LP's only to cause gauranteed rejects.
That said, getting an LP from another pool still means bonuspool also received the LP and is on the new block allready, you are simply gambling that the active pool is slower to receive confirmation of new block which is a silly approach in my books, if there is a new block then dump old work and start with new work, thats the only approach I know of that works reliably.
