I'm working on getting this live this week. I plan to try and reproduce all the data from the original, and include some other stuff we are already storing. I've looked over the p2pool.info Azure code (not something I am familiar with) and have decided that it will be faster to write my own version on a LAMP stack as that is already the foundation of the Coin Cadence site.
As you might expect there are already some substantial differences between Coin Cadence and p2pool.info as to what and how p2pool data is stored and collected.
The biggest change/advantage of my version will be the fact that all data is gathered locally from p2pool and bitcoind compared with the current p2pool.info implementation which pulls block data from blockchain.info
I have a few questions for the community as a whole as to how to calculate and present some of the stats:
Estimated time to block:
This is currently calculated on the fly by p2pool using the pool hash rate and "attempts_to_block" from:
http://mining.coincadence.com:9332/local_stats
Code:
attempts_to_block=
parseInt(local_stats.attempts_to_block || 0);
time_to_block= attempts_to_block / pool_hash_rate;
$('#expected_time_to_block').text((''+time_to_block).formatSeconds());
The problem I see is when to store this value in the DB. The pool hash rate fluctuates pretty wildly even when miners are relatively consistent, this is a fact of life when trying to calculate the global rate of the distributed pool. Add the fact that miners are joining and leaving p2pool on a regular basis and it becomes even more complicated.
Should the expected time to block be stored immediately after or before a block is found? Should it be stored every x minutes and an average calculated on a per block basis? Very open to suggestions!
Pool Luck:
Assuming we have decided on a satisfactory answer to storing the expected time to block above, this is pretty straight forward...
The question is how the luck stats are presented. In the current p2pool.info implementation luck is presented as a % over the last 7, 30 and 90 days.
I'm considering 2 alternatives:
1. Borrowing Slush's time frame and using 1, 7 and 30 days.
2. Basing it on blocks rather then time, i.e. current block luck, last 5 blocks, last 15 blocks, etc...
What do you think?
Estimated Hashrate:
in current p2pool.info implementation:
Quote
The following users / addresses have submitted at least 1 valid share in the past 24 hours. Note: Hashrates are very rough estimates based on the number of shares submitted in the past day. They may be off by 10-20% or more due to variance.
This uses some fuzzy math that I don't fully understand. If anyone has a method of calculating this and can explain it to me I'd love to hear it....
Here is my proposed solution, and to be honest I'm not sure if it is better or worse then the current implementation, and am very open to suggestions:
Using data provided by p2pool here: http://mining.coincadence.com:9332/current_payouts
Retrieve the following: current total block payout (including tx fees), payout per miner, global pool hashrate
Calculate miner % of total expected block payout.
Miner estimated hash rate = % of global pool speed based on % of expected payout??
So for example if a miner has 10% of the expected total payout, we can assume they have 10% of the global hash rate...
Again, fuzzy math at best and am open to suggestions....
Summary
I'd like feedback on my 3 suggested methods:
1. When to store estimated time to block (every x minutes and use average, just before or just after a block is found)
2. Calculating/Display format for pool luck
3. Estimating miner hash rates
Thanks!
