Quote from: c00w on July 29, 2011, 12:10:00 AM

Huh. We shouldn't be cross submitting shares. However if our connections lag out we leave your pool. And then come back when it delags. So giving us bad connections causes a lot of wounded thrashing.

Cross submitting shares shouldn't happen though... I'll check.

As always though using a proper algorithm would be nice instead of messing with the hoppers.

The high stales reports i received from users using this proxy we're getting unknown-work for over 90% of their stales.

We never broke pool hopping clients, however, our API spit bad data to known hopping clients for a little over a week until it was removed. We moved to a delay because a delay period is much more sensible and cannot be evaded.

Other than the stats delay; habitual hoppers (and tbh they gotta hop a bunch) are flagged by a script to get lowest priority through our load balancer. Plenty fair, why should hoppers get work ahead of or to the detriment of someone that has been "in line" before them.

Hoppers want to maximize their income at the detriment of other users. So we obviously cant support it, a mildly random stats delay ensures that you can take far less advantage.

Quote from: Sukrim on July 29, 2011, 12:08:01 AM

The right thing to do is not some stupid API delay which will be obsolete soonish anyways - just change to a real and fair payout system!

Sorry, proportional is the only fair mining method. A share is a share, no matter when it is submitted.
TBH, I really don't mind hopping that much. But as i said before, when it starts wreaking havoc on the pools you're hopping on the problem must be addressed. Hoppers are hundreds of thousands of work requests all hopping together to the same pool; might as well be a "DDoS".