Did not implement a way to track non-share chain blocks, perhaps I will in the future, but the historical stuff is gone.
I believe it is a much higher % than you think. I'd speculate (and yes it's just speculation) that it is somewhere around 5-7% of found blocks.
I understand how your calculation works now, thank you, however I don't see how it could be applied to p2pool practically.
The share difficulty changes with every share, and often nodes disagree on difficulty (due to propagation times).
While the reported hash rate is only an estimate I believe it's the best number we have to work with, and by using the 1 minute average since the last block was found I think we get about as accurate a picture as possible without storing every single share for the long term.
Storing all the shares would be cool, but just don't see how to do it in a way that is directly query-able without creating an additional enterprise scale DB on top of what we already have.
How do you store submitted work for your pool? Do you plan to keep all the data in a query-able state for all time?
After thinking about this on and off for over a year now I'm OK with having an ~estimated~ luck, that is consistently calculated from the data we have available.
It serves it's intended purpose which is to reflect how the pool is preforming overall, over time.
I view having to use imperfect data as a trade off for getting completely trust-less decentralization, something I value much more than a 100% accurate all the time luck stat.
While I do understand your points, I find it ironic for you to criticize P2Pool's infrastructure while running your own closed source centralized pool.
Serious question: What would it take to get you and CK to merge your pool with P2Pool, and focus on it's scalability problems?
We could sure use your expertise
what are you trying to say ?
