I think your pool shows wrong block in the stats page.
Current Bitcoin block#:   115201, but bitcoin client says 115201.
How can one mine a block which is already solved & accepted & showed by client?

I most times see that the current bitcoin block shows is always the one solved as per bitcoin client & many bitcoin sites.
Your statistic page never showed current REAL block which is mining currently.

I think its a small bug escaped.

Is it possible?
May be i am wrong?

In this particular case, that link to BlockExplorer shows that the 2nd block doesn't exist at all. I suspect it has something to do with the fact that it was found only 21 seconds after the previous one.

I realized something this morning: The average number of shares per block should be close to the current difficulty

Perhaps you all knew this, but it was big news to me. The number of shares per block bounces around a ton, but if you average it over a long enough time period, it should be close to the current difficulty.

Once I came to this stunning realization, I was able to make this graph using data from here: http://mining.bitcoin.cz/stats/?history=1000

Check it out:



My original question to myself was: why the heck is the pool solving blocks as if difficulty was ~80000 instead of difficulty ~69000??

Now I have my answer (we appear to be victims of probability), and I thought I would share it with you guys.

By my estimation, the average should actually be above the current difficulty.

If the range of the possible number of shares is from 1 - infinity  (if the transactions being worked on continue changing over time, then it could be infinite, it is VERY remotely possible for there to be a block that is never solved)

and the current difficulty is only: 68978.8924579

Many more blocks will take longer than the "expected" amount of time, which is simply an estimated amount of time to represent the group as a whole having spent enough time to generate a single full difficulty block.  Each hash you calculate has an equal chance of being the right one, form the very first, to the last one you allow your computer to check they all have an equal chance of being the lucky one.  It taking a long time to solve a block does not actually mean that we are necessarily any closer to solving one.  Therefore, with the likelihood of extreme outliers in any data with a large enough sample, the average time will end up being higher than the difficulty as a result of a few extreme cases.

I'm sure there are several miner [sic] mistakes in there, but the concept is reasonably accurate I think.

Also:  I like puns.

#            Block found                    Duration    Total shares     Your Reward         Block        #   Validity
2538   2011-03-29   04:57:49  0:00:02   8    8                       none                       115552       93 confirmations left

Now that doesn't seem too fair. How could this be "fixed" to be more fair with the score based system? Maybe total shares < 1000, use the ratio from the last round?

EDIT: Ah. so it was a glitch/cheat attempt?

You're right, average round should have the same number of shares as current difficulty is. The graph you did shows the real variance in round durations.

Why? This is not correct - everybody has the same chance to hit first share, of course proportionally to his hashrate. Just for curiosity, 7/8 shares was submitted by normal users with decent GPUs (I know some of the users so I can tell), not by users with strong rigs. Of course probability that CPU user with 1mhash/s hit one of first 8 shares is very low, but don't forget that he has 200-300x slower worker.


Sorry, I still don't see why. And why the limit should be 5k shares and not 3k or 10k shares. Don't confuse fairness and luck; this artifical limit is definitely less _fair_, because it favors unlucky workers.

No, everything is OK. The hashmeter is calculated from current round (is calculated from submitted shares/round duration). This means that after refresh instantly after block is found, you'll see "Cluster performance: 0Ghash/s", because there isn't any share yet. As the round is going, the hashmeter goes up to real cluster performance.

I have also implemented hashmeter with sliding 5min average (submitted shares in last 5min 300 sec), which is currently not enabled. This hashmeter is not affected by round ends, but the hashrate variance is much bigger - 5min is not long enough window and speed is changing in +/- 20ghash/s.

EDIT: I just changed hashmeter from round-based to continuous and rised statistics window from 5min to 20min avg, so number should be much more steady/exact now.