Bitcoin block time

You know: The expected time between two Bitcoin blocks is on average \(10\) minutes. Now you are making an important Bitcoin transaction and waiting eagerly to see if and when it appears in the next block:

e50bfacc95975a4e7545d83d8954645f


Since you have not checked when the previous block was completed, you actually expect an average of \( \frac{t}{2} = \frac{10}{2} = 5 \) minutes of waiting time. After \(5\) long minutes have elapsed, check when the last block was actually completed:

e50bfacc95975a4e7545d83d8954645f

The last block was already completed \(7\) minutes ago. Now that you know this information, the expected time changes from \(5\) minutes to a total of \(10\) minutes. That means: In about \(3\) minutes it will probably be so far. You issue the command over and over. And wait. After another \(10\) minutes you get the feeling that something is wrong.

But then you remember that Waiting paradox:

If buses run every \(t\) minutes on average, the waiting time for a random arrival time at the bus stop does not correspond to \(\frac{t}{2}\) minutes, but in the case of exponentially distributed distances \(t\) .

Bitcoin block occurrences are a Poisson process and are therefore exponentially distributed. Since Poisson processes are memoryless, the next block is also completed in \(10\) minutes on average. That always applies - no matter how long we've been waiting. The quality of memorylessness applies both backwards and forwards in time.

How can that be?

To do this, we consider the following two statements:

  • A) The actual average waiting time between two blocks is \(10\) minutes, not \(20\) minutes.
  • B) If a random point in time is chosen, we expect that the previous block \(10\) minutes in the past and the next block \(10\) minutes in the future. So we can expect a waiting time of \(20\) minutes between the blocks.

We check both statements.

To do this, we first extract the relevant data, specifically the times at which the blocks were completed, into a TXT file (to be carried out with a locally running full node based on bitcoind ):

e50bfacc95975a4e7545d83d8954645f

This gives us the following text file , which we now process further and store in /time.txt . The following Rust program is used for this with the /Cargo.toml file:

e50bfacc95975a4e7545d83d8954645f

The file /src/main.rs contains the actual test logic:

e50bfacc95975a4e7545d83d8954645f

We install the dependencies, build the program and start it:

e50bfacc95975a4e7545d83d8954645f

Indeed, both statements are true when we analyze the output:

e50bfacc95975a4e7545d83d8954645f

This can also be explained intuitively as follows: If the block times vary significantly, the specific waiting time varies - if we carry out the transaction at a random point in time, the probability is higher that we will end up in an interval in which the waiting time is longer than 10 minutes is because these intervals also take up more space on the timeline because of the longer time.

Back