Bitcoin wants to be a universal payment means, providing rapid transactions. Here is an analysis on the blockchain timing, based on their timestamps.
More on blockchain in this overview and in the simple, humorous, yet thorough article «Hitchhiker’s Guide to the Blockchain».
Data sets
Data set 0: Everything
This data set includes all 725 287 blocks created up to 2022-02-28 14:13 (all times UTC), the time at which the data was extracted.
Data set 1: All but genesis
Every start has its own teething problems. For example, the Bitcoin “genesis block” (the first block, numbered 0, the one without ancestors) was created on 2009-01-03 18:15:05, according to the timestamp embedded in it. The next block, number 0, was only created 5½ days later, 2009-01-09 02:54:25. The following 13 intervals range from around 1½ to 13½ minutes, in the expected range. Therefore, the first interval of 5½ days was removed from the data set.
However, the 15th interval, of just over a day (24:12:37), is included, as there are 3 more such events in 2009, dated in May and June.
Data set 2: 2010+
The year 2009 includes 9 intervals of 10 hours or more, which none of the other years have. Also, the entire blockchain history lists 152 intervals of more than two hours, 137 of which are in that “genesis year”. (These 2+ hour intervals continue into 2021, with two events listed there.) Therefore, a data set 2 is created, which includes all but the genesis year, 2009.
Data set 3: 2020+
A last dataset only includes the last roughly 26 months, ranging from 2020 to today (2022-02-28). This is meant to represent the current state, but might have a too narrow spread.
Negative durations (data set 0)
2 % of the blocks show a negative interval length. This is possible, as the timestamps inside the blocks are created by the winning miners themselves, and are in no way externally validated. Possible reasons for these negative interval lengths include unsynchronized clocks, not updating the time field while updating the hash, or someone purposefully manipulating the hash (although I do not see an obvious benefit for doing this).
The following table lists the number of negative intervals in a given year. Most of those intervals are one-off, i.e., while the timestamp at block i+1 may show a time before that of block i, the one at i+2 is again in the right order (i.e., after both i and i+1). The latter events are labelled as “double negative”. Three or four consecutive blocks without a time ahead of the first are labelled as “triples” and “quadruples”. Especially for the latter categories, it is more likely that the first block had a timestamp wrongly set into the future.
| Year | Negative | Double | Triple | Quadruple |
|---|---|---|---|---|
| 2009 | 524 | 41 | 23 | 14 |
| 2010 | 1050 | 106 | 46 | 36 |
| 2011 | 629 | 132 | 61 | 36 |
| 2012 | 2730 | 711 | 258 | 128 |
| 2013 | 1516 | 264 | 86 | 49 |
| 2014 | 3936 | 637 | 198 | 72 |
| 2015 | 2442 | 509 | 118 | 24 |
| 2016 | 482 | 83 | 16 | 1 |
| 2017 | 338 | 16 | 5 | 1 |
| 2018 | 223 | 6 | 1 | |
| 2019 | 230 | 6 | 2 | |
| 2020 | 171 | 7 | 3 | 2 |
| 2021 | 122 | 5 | 1 | |
| (2022) | 15 | 1 | 1 |
We can clearly see that the number of backward timesteps in the past four years has greatly improved.
The following table lists the median and maximum size of these backward steps.
| Year | Median | Maximum |
|---|---|---|
| 2009 | 01:53 | 01:04:56 |
| 2010 | 00:42 | 01:58:35 |
| 2011 | 01:10 | 01:58:45 |
| 2012 | 02:14 | 01:30:33 |
| 2013 | 01:20 | 01:43:21 |
| 2014 | 02:17 | 01:32:48 |
| 2015 | 02:10 | 01:04:20 |
| 2016 | 01:08 | 11:16 |
| 2017 | 00:18 | 09:05 |
| 2018 | 00:09 | 12:28 |
| 2019 | 00:09 | 08:15 |
| 2020 | 00:44 | 31:51 |
| 2021 | 00:56 | 06:46 |
| (2022) | 00:11 | 17:55 |
Up to 2015, maximum clock offsets of one to two hours were possible, with half of the backsteps in the one to two minute range. Since 2017, the median backward step is less than a minute, in many years only on the order of ten seconds. Maximum errors since 2017 never exceeded 32 minutes, often less than ten minutes.
Given that this is expensive high-tech equipment dealing with large amounts of money and being touted as the basis of the future of finances, document timestamping, and much more, it is baffling that time is not better synchronized, given that time synchronization with possible sub-second accuracy is a 1970’s technology, standard on most computers today.
Timestamp accuracy estimation
The section above is just to show potential sources of errors, as all analyses rely on the timestamps recorded in the blocks themselves, with no ground truth available. Assuming that the sizes of the backwards steps are a good first approximation of the clock errors, the maximum error for blocks minted before 2016 should not exceed two hours, for blocks minted afterwards, they should not exceed 30-40 minutes.
Over the entire lifetime of the Bitcoin blockchain, about 2 % of the intervals have a negative duration.
However, in recent times (data set 3: 2020+), only 308 out of 114 596 intervals have negative duration, less than 0.27 %, or, on average, 1 out of every 373 blocks. More than 90 % of those reverse steps in data set 3 are shorter than a minute; only 16 out of the 114 596 intervals (0.014 %) go back more than one minute. For data set 3, we can therefore safely assume that an overwhelming majority of intervals is accurate to a minute or less; also, for the other data sets, such an assumption likely holds true.
Block mining interval distribution (data set 3)
On the right, you see the probability distribution of the interval length over data set 0. As the distribution has some strong tails, the outermost 0.01 %, the shaded areas, have been horizontally enlarged by a factor of 1000. (Click on the image to see it in full resolution.)
The center 99.98 % of the distribution cover time differences between -58 minutes and +3 hours and 11 minutes (all data under this heading are rounded to minutes, no seconds). However, there is a 1:5000 chance (on average, about every 20 days), that an interval is outside of those boundaries, extending to between -1:59 and 25:08, or, roughly, -2 hours to +25 hours.
Other key data points: ±0 is at 2 %, +2 minutes at 19 %, +10 minutes (the Bitcoin target) at 65 %, +20 at 88 %, +30 at 96 %, +40 at 99 %, +1 hour at 99.73 % (i.e., more than once a day, on average, you have to wait more than an hour for the next block).
Data set 2 (2010+) still looks essentially the same at the lower end, but more benign at the higher end. The maximum is 6:51, just below 7 hours, the 99.99th percentile at 1:37. But again, the one hour mark is at 99.79 %, still about one interval of more than an hour every two days.
Data set 3 (2020+) shows further calming on both ends: Extremes are now -32 minutes and +2:19 hours, with the inner 99.98 % spanning -1½ to +1:45. The shaded areas only cover 11 intervals each, as the total number of intervals during these 26 months is only 114 595.
The average interval duration is about 9.8 minutes, very close to the 10 minute target. The median is at 6.9 minutes (actually, 6 minutes and 52 seconds)
±0 is at 0.27 %, +2 at 18 %, +10 at 64 %, +20 at 87 %, +30 at 95 %, +40 at 98 %; i.e., with the exception of ±0, they all moved left just slightly.
The mining process is a Poisson process; its interarrival time is 10 minutes. The associated Poisson distribution has the interarrival time at around 63 % (actually, at 1-1/e), which closely matches our observation.
Block confirmation delays
The rule of thumb to accept a block as “confirmed” for “normal” purposes is to wait until it reaches a depth of 6. (For important transactions or if there might be a powerful adversary involved, higher numbers such as 60 are recommended.)
If you submit a transaction now, you have to wait for this transaction to be incorporated into a block (which might or might not be the next block being added) and then wait for 5 more blocks to be mined.
As an approximation, we assume that it takes 6 intervals between submitting your transaction and it being considered “confirmed” for most purposes.
Therefore, the period of 6 intervals is also interesting. It’s distribution (based on data set 3, i.e. 2020+) is shown on the right.
The minimum 6-interval duration seen in the past 26 months is 2 minutes, the maximum 6:02 hours. The 99.98 % center ranges from to 0:07 to 3:44, with 2 % corresponding to 20 minutes, 22 % corresponding to 40 minutes; and 57 %, 81 %, 93 %, and 97.7 % corresponding to 60, 80, 100, and 120 minutes, respectively.
So, on average, on about 6 of the 240 daily intervals, you have to wait longer than 2 hours before your block is confirmed. Given that this 26 month dataset contains 112 intervals longer than 3 hours, on average, about once peer week you confirmation will take longer than 3 hours.
In summary, neither the block generation intervals, the likelihood of your transaction being included in a particular transaction, nor the duration of the confirmation interval are reasonably predictable. In my opinion, this alone puts serious question marks on the claim that Bitcoin should become a replacement for traditional money.
