@deepceleron: how are you getting on with LP penalty - Did you end up with a significant increase in accuracy?
I kinda gave up on it for a while. As you saw from my post like five pages back, I put in the delays to the results I had already gotten and analyzed that. The conclusion was that even after inputting (or auto-learning) and even hand-tuning the average delay for each pool, the current 'first pool wins' method is suboptimal. A better algorithm, that in my limited sample gave no false positives, is to take the average delay of all
pools after correction, and then analyze each pool against this average to determine if one stands out above the standard deviation expected if no
polled pools were the finding pool. This improves results, since you aren't merely comparing the winning pool against the second-fastest, you are averaging out the LP delay capriciousness of your baseline over 15 pools.
Secondly, I propose a better p2p-IRC result sharing format, where all
pool new block LP receive times (and the getwork timestamp) are published raw to IRC by each miner, perhaps after gathering LPs for a 10 second period after the first response. This would be better than the current "I think this pool won" publishing method, as then similar averaging can be done by the bithopper software independently, but with everybody's
data, which, if we continue with the premise that the block-finding pool responds faster, should make identification clear.
This also will only last as long as pools don't take countermeasures, such as modifying bitcoind to randomly delay the RPC change to a new block if the local bitcoin found it, or by simply disabling long polling, like slush's pool.
As I would have to learn python, some database libs, and the current codebase before making improvements (and since improving hopping software was labeled as equivalent to "making poison gas for the Nazis" by hoppers themselves), I will leave it to someone else to implement this.