Heh this was fun to see in slush, in response to my post about the terrible luck:
Unlike some competitors, we have always focused our energy and attention on improving our service rater than accusing our competition and we will continue to do so. Bad luck happens and probability of one in X surely does not refute it. We believe that we are the most transparent pool around with the huge amount of data we are publishing. And considering the market share, it seems that miners appreciate this approach and our service better.
I guess it means "please ignore it coz we are bigger than them"
(then pretend it never happened)
When we had a run of bad luck last October ... that was a little better than their run of bad luck ... I did some important additions to KDB and reprocessed the 3 months of shares around the time of the bad luck to independently verify there were no lost blocks.
This involved adding completely independent share checking code to KDB, original code all written by me, not copied from anywhere else, and using the OpenSSL SHA256 hash function to also ensure the hash itself was done with different code to ckpool.
i.e. there are two completely independent checks of each share in KanoPool - one more accurate check done by KDB and one slightly less accurate check done by the ckpool code.
Also of note, the share log I have in KDB (which is in the old source git) permanently stored in the pgsql database, is what he is talking about regarding "a huge amount of data"
That data I use for the luck report - and I added it to the public KDB git long before they ever did it - and I also back processed it to the beginning of KanoPool in Sep 2014.
It also contains more information than they have.
However, no I do not publish it, since if you remove the unique user information you cannot verify the shares.
Not sure how they can do that without removing the user information ... but I can ensure you their data is one of either:
1) there is still user based information in their supplied data
or
2) you can't verify the supplied data
Edit: and to prove my point about the user information: a share that is a block will of course identify the user who found the block.
That will also identify the unique work that the user had, since in the coinbase data hashed there is a unique id for each miner.
Thus to verify the data for a block, you must know the unique id of the miner who found the block.
Thus you can of course associate other data published with the same miner and user.
) then the 5Nd on the Help->Payouts page should be close.
)
)
)