Category: TIME

In a previous post, I summarised that the block time recorded for any Bitcoin block could be as much as 1 hour earlier or 2 hours later than the actual time, under the ideal timing of 10-minute blocks.

This is theoretical, based on what block validators would accept, but I was curious as to the actual time inaccuracy present within blocks. Between blocks 765069 (28^th November 2022) and 765873 (4^th December 2022) I sampled 100 blocks, comparing their timing to when my full node received and exposed those blocks via the RPC API.

A simple python script was written that continuously polled my full node for the current block height. This was compared to the previous response and if it differed, a new block had been found. On a new block being identified, the script obtained the local machine’s time (which is synchronised via NTP, Network Time Protocol, daily) and logged it against the block number and block time. These were then compared to establish the offset.

The following should be noted when considering this data:

• It does not account for the time taken for my node to be updated by peers as to a new block being found. This is expected to be variable but within a few seconds, depending on the peering of the miner and my node. The node reported a maximum latency of 281ms for peers when reviewed; this will be variable, however.
• It does not account for any delay in my node exposing a new block via the RPC API. This is expected to be minimal as once the block is validated it is expected to be exposed. Validation requires minimal resources and the node is operating on a modern multicore system with ample RAM.
• The block samples were taken during the period 09:00 to 20:00 UTC; it does not, therefore, account for variations relating to timezones/blocks found outside of these hours. This is considered to be negligible as most miners and nodes will operate 24/7 (bar maintenance) and therefore are not affected by the time of day.
• The script polled was configured to query the node every 50ms. This rate was chosen so as not to overload the RPC server, or delay/block the processing of a new block. In addition, the code’s overhead means that additional time is required to perform the checks and logging as well as network latency. From the output, this appears to be around 50-70ms.
• Block header times being in Unix time are only as precise as 1 second. This analysis does not seek to determine accuracy to 10s of ms but rather provides an overview.

Overall I would expect the local time to be within 1-4 seconds of the block creation, but this is unproven. This may be considered further with an experiment on the Bitcoin Testnet.

The results were somewhat unspectacular; the largest difference was 51 seconds, the smallest -16 with an average (mean and median) of 21 seconds. Based on the sample, a tolerance of +/- 60 seconds appears reasonable when considering block times.

The full captured data is below:

Block Height	Detected New Block (Readable)	Detected New Block (Unix)	Block Time (Unix)	Time Difference (seconds)
765069	28/11/22 17:24:36	1669656276	1669656248	28
765070	28/11/22 17:42:17	1669657337	1669657337	0
765071	28/11/22 17:42:49	1669657369	1669657337	32
765072	28/11/22 17:43:23	1669657403	1669657368	35
765073	28/11/22 17:47:34	1669657654	1669657624	30
765074	28/11/22 17:49:46	1669657786	1669657774	12
765075	28/11/22 17:54:36	1669658076	1669658048	28
765076	28/11/22 18:07:37	1669658857	1669658818	39
765077	28/11/22 18:15:57	1669659357	1669659324	33
765078	28/11/22 18:19:35	1669659575	1669659560	15
765079	28/11/22 18:25:54	1669659954	1669659920	34
765080	28/11/22 18:27:04	1669660024	1669660015	9
765081	28/11/22 18:58:21	1669661901	1669661882	19
765082	28/11/22 19:04:53	1669662293	1669662264	29
765303	30/11/22 09:12:13	1669799533	1669799493	40
765304	30/11/22 09:22:14	1669800134	1669800098	36
765305	30/11/22 09:35:16	1669800916	1669800896	20
765306	30/11/22 09:35:38	1669800938	1669800916	22
765307	30/11/22 09:37:09	1669801029	1669800978	51
765308	30/11/22 09:38:34	1669801114	1669801110	4
765309	30/11/22 09:40:12	1669801212	1669801204	8
765310	30/11/22 10:12:19	1669803139	1669803134	5
765311	30/11/22 10:19:10	1669803550	1669803530	20
765312	30/11/22 10:22:22	1669803742	1669803720	22
765313	30/11/22 10:28:26	1669804106	1669804105	1
765314	30/11/22 11:23:03	1669807383	1669807358	25
765315	30/11/22 12:22:14	1669810934	1669810918	16
765316	30/11/22 12:34:40	1669811680	1669811649	31
765317	30/11/22 12:43:18	1669812198	1669812172	26
765318	30/11/22 12:49:20	1669812560	1669812520	40
765319	30/11/22 12:51:41	1669812701	1669812662	39
765320	30/11/22 12:52:25	1669812745	1669812722	23
765336	30/11/22 17:01:23	1669827683	1669827672	11
765337	30/11/22 17:04:00	1669827840	1669827832	8
765338	30/11/22 17:09:20	1669828160	1669828141	19
765339	30/11/22 17:10:19	1669828219	1669828182	37
765340	30/11/22 17:33:33	1669829613	1669829586	27
765341	30/11/22 17:37:53	1669829873	1669829839	34
765342	30/11/22 17:45:15	1669830315	1669830282	33
765449	01/12/22 09:09:59	1669885799	1669885752	47
765450	01/12/22 09:23:44	1669886624	1669886614	10
765451	01/12/22 09:26:54	1669886814	1669886787	27
765452	01/12/22 09:34:53	1669887293	1669887266	27
765453	01/12/22 09:44:25	1669887865	1669887863	2
765454	01/12/22 10:03:22	1669889002	1669888984	18
765455	01/12/22 10:22:07	1669890127	1669890088	39
765456	01/12/22 10:31:08	1669890668	1669890684	-16
765457	01/12/22 10:47:09	1669891629	1669891602	27
765458	01/12/22 10:56:48	1669892208	1669892200	8
765459	01/12/22 11:04:53	1669892693	1669892689	4
765460	01/12/22 11:05:25	1669892725	1669892723	2
765461	01/12/22 11:15:02	1669893302	1669893294	8
765462	01/12/22 11:28:46	1669894126	1669894113	13
765463	01/12/22 11:38:08	1669894688	1669894683	5
765464	01/12/22 11:40:48	1669894848	1669894829	19
765465	01/12/22 11:57:31	1669895851	1669895831	20
765466	01/12/22 11:57:44	1669895864	1669895851	13
765467	01/12/22 12:21:48	1669897308	1669897265	43
765468	01/12/22 12:25:17	1669897517	1669897489	28
765492	01/12/22 17:38:10	1669916290	1669916282	8
765493	01/12/22 17:42:12	1669916532	1669916507	25
765494	01/12/22 17:43:30	1669916610	1669916576	34
765495	01/12/22 18:01:50	1669917710	1669917689	21
765496	01/12/22 18:02:50	1669917770	1669917734	36
765497	01/12/22 18:14:01	1669918441	1669918434	7
765498	01/12/22 18:18:35	1669918715	1669918681	34
765584	02/12/22 09:11:29	1669972289	1669972281	8
765585	02/12/22 09:12:09	1669972329	1669972319	10
765586	02/12/22 09:12:52	1669972372	1669972359	13
765587	02/12/22 09:42:20	1669974140	1669974128	12
765588	02/12/22 10:48:37	1669978117	1669978106	11
765589	02/12/22 11:01:44	1669978904	1669978875	29
765590	02/12/22 11:07:43	1669979263	1669979232	31
765591	02/12/22 11:10:53	1669979453	1669979437	16
765592	02/12/22 11:43:52	1669981432	1669981415	17
765593	02/12/22 11:49:53	1669981793	1669981764	29
765594	02/12/22 12:46:13	1669985173	1669985136	37
765595	02/12/22 13:01:57	1669986117	1669986090	27
765596	02/12/22 13:02:41	1669986161	1669986152	9
765597	02/12/22 13:04:07	1669986247	1669986202	45
765598	02/12/22 13:06:29	1669986389	1669986383	6
765599	02/12/22 13:11:02	1669986662	1669986665	-3
765600	02/12/22 13:30:13	1669987813	1669987810	3
765601	02/12/22 13:31:08	1669987868	1669987844	24
765602	02/12/22 13:32:53	1669987973	1669987969	4
765603	02/12/22 13:47:45	1669988865	1669988854	11
765758	03/12/22 18:07:12	1670090832	1670090811	21
765759	03/12/22 18:42:51	1670092971	1670092945	26
765760	03/12/22 18:45:11	1670093111	1670093072	39
765863	04/12/22 12:57:03	1670158623	1670158612	11
765864	04/12/22 13:17:57	1670159877	1670159860	17
765865	04/12/22 13:24:47	1670160287	1670160264	23
765866	04/12/22 13:37:48	1670161068	1670161040	28
765867	04/12/22 13:39:41	1670161181	1670161149	32
765868	04/12/22 14:05:38	1670162738	1670162732	6
765869	04/12/22 14:22:54	1670163774	1670163755	19
765870	04/12/22 14:49:31	1670165371	1670165321	50
765871	04/12/22 15:04:39	1670166279	1670166273	6
765872	04/12/22 15:15:31	1670166931	1670166910	21
765873	04/12/22 15:37:56	1670168276	1670168257	19

In the previous post, I explored the timing of individual blocks. Generally, 6 blocks are used to confirm a transaction. This attempts to mitigate the possibility of the transaction being included in an orphaned block as a result of a fork caused by two blocks being found concurrently and to act as security against a malicious actor with considerable hashing power reverting previously mined blocks. A block is considered immutable after 6 confirmations.

While the previous analysis showed blocks in recent years may take up to 2 hours and 19 minutes, the chances of 6 constitutive blocks taking a similar amount of time is considered highly unlikely.

---

A snapshot of block headers was taken at block 763308 (15^th November 2022) and an analysis of rolling 6 block timing was completed.

The average 6-block confirmation time over the entire history of the blockchain was 3436 seconds (57 minutes, 16 seconds). Closely aligned to the target time of 3600 seconds (60 minutes); 6x target block time of 10 minutes.

Over the past 5 full years – 2016 to 2021 – the longest 6-block confirmation time was just over 6 hours in 2021. This was exceptional, with other years being around 4 hours. If you were lucky enough to be awaiting your transaction confirmation during the shortest period in these years you could have been waiting for as little as 2 minutes (2020)!

Year	2009	2010	2011	2012	2013	2014	2015
Block Range	0-6	74637-74643	149092-149098	208508-208514	215900-215906	297493-297499	386679-386685
Max (seconds)	465284	26789	15624	14392	12042	13514	14428
Max (HH:MM:SS)	09:14:44	07:26:29	04:20:24	03:59:52	03:20:42	03:45:14	04:00:28

Year	2016	2017	2018	2019	2020	2021	2022 (Partial)
Block Range	425375-425381	494062-494068	514763-514769	578632-578638	622894-622890	688986-688992	760246-760252
Max (seconds)	13922	13941	14972	12057	15075	21760	13434
Max (HH:MM:SS)	03:52:02	03:52:21	04:09:32	03:20:57	04:11:15	06:02:40	03:43:54

Overall, 75% of transactions awaiting 6 block confirmations would be expected to be confirmed within approximately 1 hour and 10 minutes, with 95% being confirmed within approximately 1 hour and 45 minutes.

Bitcoin has a target block time of 10 minutes. Due to the hashing mechanism, it is unknown when a target hash will be achieved; it may be a second or it may be several hours but on average it is aimed to be 10 minutes. The greater the hashing power of the network, assuming a static target difficulty, the quicker a block would be expected to be mined, but due to the randomness of finding a solution the network hashing power is not directly correlated to the block time.

To achieve the 10-minute target block time, the difficulty of the target hash is altered every 2016 blocks, approximately 2 weeks. This re-targeting considers the time taken to mine those 2016 blocks and compares that to the expected time of 20160 minutes (2 weeks). The Bitcoin network then changes the difficulty appropriately; if the 2016 blocks were mined in under 20160 minutes the difficulty target will increase. If the 2016 blocks were mined in over 20160 minutes, the difficulty target will decrease.

The block header contains both the target difficulty and the time the miner reports to have mined the block. The target difficulty is calculated and checked by all verifying nodes on the network. It is therefore considered accurate.

The time, however, is not always accurate, but it is checked that it is greater than the median time of the previous 11 blocks, and not over two hours ahead of the current time as agreed by the connected nodes. In ideal circumstances (11 blocks of exactly 10 minutes each), the median would be 3600 seconds (60 minutes/1 hour). A valid timestamp would therefore be accepted if it were T-60/+120 – a three-hour window, under ideal conditions.

---

A snapshot of the Bitcoin network’s block headers was taken on 7^th November 2022 at block height 762150. The average (mean) block time from the genesis block (3^rd January 2009) to block 762150 was 587 seconds; 9 minutes and 47 seconds.

The data was then aggregated by year to give a summary of the Bitcoin’s network performance over that year.

Since 2015, the performance has been impressively consistent; the yearly average (mean) ranged from 563 to 598 seconds; 09:23 to 09:58. In 2010, 2011, 2013, and 2014, the average (mean) time was all under 9 minutes; 07:44, 08:48, 08:17 and 08:55 (respectively). 2012 was an exception during this period with an average block time of 09:39, more aligned with 2015 to 2022 values. Not surprisingly, given the introduction of the Bitcoin network that year and limited adoption, in 2009 the average block time exceeded the target considerably, achieving an average block time of 16:03.

The table below summarises the average (mean) block time per year since Bitcoin’s inception.

Year	2009	2010	2011	2012	2013	2014	2015
Mean (Seconds)	963	464	528	579	497	535	580
Mean (HH:MM:SS)	00:16:03	00:07:44	00:08:48	00:09:39	00:08:17	00:08:55	00:09:40

Year	2016	2017	2018	2019	2020	2021	2022 (Partial)
Mean (Seconds)	576	563	578	581	594	598	589
Mean (HH:MM:SS)	00:09:36	00:09:23	00:09:38	00:09:41	00:09:54	00:09:58	00:09:49

Overall, the Bitcoin network has adapted well to the significant increases in hashing power over its lifetime.

---

The average, however, doesn’t tell the whole picture. Whilst the time required for a 6-block confirmation for transactions may be considered acceptable based on the average block time, on occasions the block time is significantly greater than 10 minutes.

The table below summarises the longest block times in a given year for the past 5 complete years.

Year	Block	Time	Previous Block Time	Time Difference (HH:MM:SS)
2021	689301	12:46:53 07/01/2021	10:27:39 07/01/2021	02:19:14
2020	621701	08:39:25 15/03/2020	06:46:15 15/03/2020	01:53:10
2019	597273	17:07:42 30/09/2019	15:08:45 30/09/2019	01:58:57
2018	554323	08:06:20 18/12/2018	06:27:32 18/12/2018	01:38:48
2017	451858	21:10:52 06/02/2017	19:31:38 06/02/2017	01:39:14

These represent the longest blocks, however. Analysis indicates that 95% of blocks will be mined within around 30 minutes of the previous block.