** POOL.BIBLEPAY.ORG hashing status update **

Rob did some testing on Sunday night with Capulo so far, and Rob believes the multiwallet "edge" against pools has to do with multiple slow threads solving similar work in the same 500ms range - work that would not help the pool solve an actual block.  This was found by auditing reports of solved fractional shares comparing the pool itself at large to the largest miners - IE select all work being solved sorted by solve time descending, and I found a high incidence of clumps of 2 threads solving a share within 500ms of another on the large miners, but not from the pool at large.

So at this point, pool.biblepay now marks work that is solved within 1 second of another share as Stale (the user still gets credit for the first solution, first in still wins).  This resulted in an approx 50% decrease in rewards to the top 5 pool users (IE anyone running multi-wallets).

At this point Capulo is auditing the running nodes, he might be setting up two environments for us one with multi-wallet one with no multi-wallet. 
Licht is also testing purepool to find how this affects his pool, as I'm sure there is a similar effect going on since we use the same hash algorithm and fractional share types.

So until I hear back from the testers, for now the small miners should see a boost in payments.

I also wanted to say, there is quite a bit of confusion, and miscommunication being spread.

Pool.biblepay does not pay users off of the HPS2 figure.  We pay off of the shares solved in the Leaderboard.  So if you solve 10 shares in the leaderboard and receive 100bbp, a person with 20 shares would be receiving 200bbp.  There is no strange calculation on the back end going back to HPS2 then back to PPH.  (You can see in block distribution its always been this way).  (Someone here had written a tool to try to exploit the pool based on HPS2 figures in error, and misled some of the miners).