4

According to http://btc.blockr.io/ :

Height  Block created   Transactions    Block fee   Size (kb)   Days destroyed
318525  2 minutes ago   28              0.00370000  8.36 kB     2.00
318524  3 minutes ago   64              0.00746243  25.76 kB    527.97
318523  4 minutes ago   140             0.02336649  67.67 kB    1,666.43
318522  2 minutes ago   16              0.00130000  4.64 kB     10.19
318521  8 minutes ago   359             0.05072184  205.02 kB   4,148.84
318520  16 minutes ago  92              0.01266343  49.22 kB    112.75
318519  7 minutes ago   128             0.01682150  54.51 kB    2,146.34
318518  20 minutes ago  137             0.02128600  86.23 kB    1,213.50
318517  24 minutes ago  657             0.10664839  353.93 kB   6,502.12

So during the past 24 minutes, 9 blocks have been found. One would expect this time to be approximately an hour and a half (90 minutes).

  • How is this explained? Why is the block generation process currently running so fast?
  • Is it safe to assume that the 6 confirmations, which took less that 10 minutes, implies an irreversible transaction?
  • 1
    One possibility is chance; another is that a significant amount of hashing power has joined the network since the last difficulty adjustment. It would be an interesting exercise to compute the probability of this happening randomly. If you look at a larger number of block times (say 100), do you see the same thing? – Nate Eldredge Sep 1 '14 at 1:16
  • So how does this work? Let's say that some new miners get online for the first time and their hashing power is equal to the 25% of the total hashing power until the moment they joined the network, what would happen then? The probability of this happening randomly is very interesting indeed. No, in large number of blocks the average time between block generation is rather consistent, what I described above only happen at times. – Doug Peters Sep 1 '14 at 2:37
  • When 25% more power comes online, the average block time will drop to 1/1.25 = 80% of its previous value, until the next difficulty adjustment. The size and frequency of fluctuations from the average are the interesting part. – Nate Eldredge Sep 1 '14 at 2:45
  • That's interesting.. So what mining power should have joined the network during the times that the above blocks were found? For an average of say 8 minutes that's 1/3 of the normally expected time, in other words according to your formula 200% more power should have come online, which hardly is the case IMO. It hasn't been recorded in blockchain.info's graphs either: blockchain.info/charts/… so what really happened during that time? – Doug Peters Sep 1 '14 at 13:49
  • 1
    The 200% number would assume that the blocks you observed represent average behavior. But since you don't see the same pattern over a longer time, I think we have to reject that assumption. It may be a combination of additional hashing power and chance - estimating how much of each will require the aforementioned computation. – Nate Eldredge Sep 1 '14 at 19:01
3
  1. Block finding is random. The number of blocks in a period of time follows the Poisson distribution. If the average is 10 minutes per block, then the chance of at least 9 blocks in a given 24 minute period is roughly 0.086%. Not a lot but it can happen occasionally. Also, if momentarily the hashrate has increased without the difficulty catching up, the rate, and the probability, will be higher.
  2. Yes, 6 confirmations that due to luck took, say, 30 minutes, are even safer than 6 confirmations that took 60 minutes, since the attacker would have had less time to find blocks in his alternative branch.
2

Finding blocks is a memoryless process which means:

For the network to consistently find six blocks in ten minutes, the hashing power would have to increase by a factor of six.

As we clearly aren't seeing an increase by such margins, it was just a fluke of the random process, just as for example when it took ~411 minutes to find block 74638.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.