Bitcoin is frequently criticised for having high transaction fees but this month saw Paxos pay a fee over $500,000 for a transaction of a mere $2,000 in BTC. Fortunately for Paxos, F2Pool, the miner of block 807,057 which contained the transaction acknowledged the error and agreed to refund the fees in full a few days later in block 807,732.
It just goes to show that no matter whether you’re new to crypto or are in the business costly mistakes can happen.
But is this the largest fee paid for any transaction in Bitcoin’s history? In terms of BTC no, that honour goes to a transaction in 2016 when a fee of over 291 BTC was paid to transfer a mere 0.0001 BTC! Around this time BTC was around $460, therefore this fee was worth approximately $133,860; all to transfer just 50c in Bitcoin.
Over the course of Bitcoin’s history there has been four transactions with fees higher than 100 BTC, the previously mentioned example as well as one on the 12th December 2011 (block 157235; fee almost 172 BTC), another on 10th January 2013 (block 215936; fee 111 BTC) and 28th August 2013 (block 254642; 200 BTC).
The table below provides the highest fees paid per year since Bitcoin’s genesis block.
Since the introduction of Ordinals onto the Bitcoin network in January 2023 there has been criticism of them clogging up the network and resulting in higher fees for users. Large image files are often shown as examples of taking the majority of the size of a block but there are a large number of text based ordinals which consume significantly less space.
I consider the transactions per second throughput of the Bitcoin network from 2021 to the present to establish if ordinals were impacting the network.
Originally I intended only to consider 2022 and 2023 but on an initial review of the data the results were unexpected; the throughput was greater in 2023 despite ordinals being introduced. This is discussed later.
Mean Transactions Per Second
Month
2021
2022
2023
January
13.77
8.58
8.63
February
13.41
7.96
10.27
March
14.95
8.59
12.31
April
13.12
9.36
14.97
May
10.57
8.82
31.17 (Partial)
June
9.84
8.73
July
6.33
7.90
August
7.12
8.41
September
9.47
8.93
October
8.90
7.42
November
8.64
8.91
December
8.72
8.86
Median Transactions Per Second
Month
2021
2022
2023
January
4.70
2.99
3.39
February
4.71
3.10
4.05
March
4.24
3.14
4.41
April
4.05
3.17
4.97
May
3.47
3.21
9.62 (Partial)
June
2.85
3.12
July
2.65
2.94
August
2.82
2.98
September
3.00
3.10
October
3.25
3.08
November
3.33
3.39
December
3.18
3.17
To my surprise, the transactions per second have increased, on average, since the introduction of ordinals onto the Bitcoin network when compared to the same months in 2022. I extended my analysis to include 2021 to establish if this was consistent behaviour. The figures between 2023 and 2021 were more similar to that of 2022. I suggest that this is due to the bull market of 2021 vs the bear market of 2022 resulting in there being significantly fewer transactions on the network in 2022.
Reviewing the mempool transaction account chart on Blockchain.info lends support to this.
Considering the results, the conclusion appears to be that ordinals haven’t negatively impacted the transactions per second throughput of the Bitcoin network, however, it must be considered that this is during a bear market. If the ordinals remain popular during the next bull market where transaction volumes increase there is a realistic prospect of the network becoming saturated leading to higher transaction fees and longer waits for users before transactions are included in a block.
In the previous post I touched upon SegWit and how it was used to fit almost 4MB of data within the 1MB block size limit present in Bitcoin.
SegWit was introduced to the Bitcoin network in 2017 and removed (segregated) the witness data from the transactions’ inputs and moved them to a separate structure within the blockchain. This had the effect of reducing the block size requirements for transactions (and therefore the often the transaction costs) and protecting against transaction malleability.
The move also brought in a means to increase the storage potential as seen in the previous post relating to ordinals of around 3.9MB being stored on chain. This is due to a move from bytes to Work Units (wu) for calculating the size. Since the SegWit update, blocks are limited to 4 million weight units, with 1 byte in a legacy transaction being 4wu, but 1 byte in a SegWit transaction being 1wu.
Native SegWit addresses can be identified as starting bc1 on the mainnet, or tb1 for the test net. P2SH (Pay to Script Hash) addresses can also be used for SegWit transactions which start with ‘3’.
The adoption of SegWit for transactions appears pretty rapid, perhaps not unexpected given the savings made in fees by users. In 2018, approximately 1/3rd of transactions used SegWit. By 2019 this was around 43% and by 2022 approximately 87% of transactions used SegWit. Impressively, in 2023 SegWit usage appears to continue to rise with 86.5% of transactions using SegWit.
The table below summarises the quantity and percentage of SegWit transactions each year.
Transactions per second (TPS) is an important metric when comparing Blockchains and features in the Blockchain trilemma (security, scalability, decentralisation). Bitcoin is heavily criticised for its low throughput which is often suggested to be approximately 7 transactions per second. This would equate to approximately 4200 transactions of around 250 bytes in each block (based on a 10-minute block time). This size of the transaction appears optimistic given recent average transactions, meaning the actual performance is lower.
The Bitcoin network’s TPS is frequently compared to VISA, with a figure of 24000 oft-cited for their payment service. VISA themselves claim a capacity of 65,000 transaction messages per second (it is unclear if each transaction required more than one message). It is important to note that this is a suggested capacity of their network, not how many occur. Based on VISA financial reports, the average (mean) transaction throughput in recent years was between approximately 4500 (2020) and 6100 (2022).
But I digress…
The typical calculation for a Blockchain’s throughput is (block size/transaction size) / block time
In Bitcoin, in its current configuration (as based on target block time), this would be (1MB / transaction size) / 600.
The transaction size on the Bitcoin network is variable and therefore this isn’t a constant. Bitcoin Visuals (bitcoinvisuals.com) assesses the average Bitcoin transaction size in recent years (2017 to 2022) to be between 455 and 636 bytes. This would equate to a transactions throughput of between 2.75 and 3.84 transactions per second based on the target 10-minute block time.
As I’ve written previously, the 10-minute block time is a target and is most frequently beaten. This has an impact on the calculation of transactions per second. There are instances where blocks are found within a second of the previous block. If the mempool (where pending transactions wait to be included in a block) is full, or near capacity at this time then the spot transactions per second value could be very high.
I reviewed the block headers for all blocks up till block 772089 (15th January 2023) and calculated the spot transactions per second for each block. In instances where a block was recorded as being mined earlier than its predecessor, the time difference was considered as a positive value.
Since the genesis block, Bitcoin has achieved approximately 5.7 transactions per second on average. The peak value I identified was 3087 transactions per second when block 572037 (16:02:17 17th April 2019) contained 3087 transactions, and was mined within 1 second of block 572036 (16:02:17 17th April 2019). It should be noted that this is one of the examples where the block height is positive, but the higher block is recorded as being mined earlier than the lower block emphasising the problems with the timing on the Bitcoin network.
The highest ‘non-negative’ time was in 2020 when block 649548 contained 3058 transactions and was mined one (1) second after block 649547 resulting in 3058 tps.
The table below summarises the last 12 years; in each of these years, there was at least one transaction a day.
Year
2011
2012
2013
2014
2015
2016
Max
140
387
652
766
821.83
1795
Block Height of Max
155293
203685
224618
323678
364691
442517
Average (Mean)
0.15
0.71
1.37
1.51
2.70
6.17
Year
2017
2018
2019
2020
2021
2022
Max
2856
2786
3087
3058
2940
2398
Block Height of Max
465972
549076
572037
649548
687073
752998
Average (Mean)
13.05
7.93
14.97
13.66
10.86
8.71
If negative time values are ignored, rather than being inverted, the figures change slightly. These results are summarised below:
Year
2011
2012
2013
2014
2015
2016
Max
42
278
558
766
821.83
1382
Block Height of Max
133623
191425
216547
323678
364691
442239
Average (Mean)
0.13
0.61
1.23
1.33
2.33
5.88
Year
2017
2018
2019
2020
2021
2022
Max
2856
2493
3041
3058
2940
2398
Block Height of Max
465972
556417
565275
649548
687073
752998
Average (Mean)
12.07
7.25
13.30
12.81
10.37
8.54
The increase in TPS from 2017 is expected, in part, the introduction of segwit to the Bitcoin protocol. By moving the witness data out of the block this allowed more transactions to be fitted within the 1MB block size.
Based on my previous experimentation with the accuracy of block timing where the average time between time in the block header and the time identified on my full node was 21 seconds then despite the findings above, they may not represent the throughput of the Bitcoin network. For example, if the timestamp of block 572037 was off by 21 seconds, then the TPS would go from 3087 to just 140. Still significantly higher than the expected throughput but lower than the summary figures would suggest.
During my usual browsing of various resources this morning I spotted an article on Cointelegraph entitled “You don’t see that every day: Empty Bitcoin block found”. This piqued by interest and in true ‘trust but verify’ mentality I thought I’d look into how frequently this occurs.
The Cointelegraph article focuses on block 776,339 which was the most recent zero transaction as of the time of the article. Since then there has been another zero transaction at block 776,521.
At the time of writing (17:00 14th February 2023) so far in 2023 there have been 13 blocks with no transactions (other than the coinbase) present in them; 770100, 770404, 770952, 771087, 773011, 773329, 773966, 774234, 774486, 774845, 775654, 776339 and 776521.
Since the genesis block, there has been a total of 89,453 blocks with zero-transactions. This is greatly influenced by the first two years which account for 88% of the zero-transaction blocks. Overall approximately 11.5% of blocks have contained no transactions, but in recent years this has been consistently under 1%.
The table below provides the total number of zero transaction blocks per year since the genesis block.
Year
2009
2010
2011
2012
2013
2014
2015
2016
Number of Zero Transaction Blocks
32311
46489
3585
1526
420
547
1701
977
Percentage
99.45
68.45
6.01
2.80
0.66
0.93
3.13
1.78
Year
2017
2018
2019
2020
2021
2022
2023 (Partial)
Number of Zero Transaction Blocks
528
438
314
240
221
144
13
Percentage
0.94
0.80
0.58
0.45
0.42
0.27
0.19
The graph below shows the last 10 years:
In writing this I noted that the Cointelegraph article reports that prior to block 776,339 the previous empty block was 774,486 a little over two weeks before. In analysing empty blocks I noted that there were two blocks closer to 776,339 which were empty (blocks 774,845 and 775,654). I’ve e-mailed the Cointelegraph editor and hopefully this will be corrected.
EDIT: The author reached out to me after my e-mail but as of 26th February 2023 the article remains uncorrected.
I’ve previously looked at block timing against the target 10-minute time and we have seen that since 2010 the Bitcoin network, despite the difficulty retargeting every two weeks, has consistently beaten, on average, the target time.
With that in mind, when will the final block reward be granted? It is often cited that this will be 2140, but could the current trajectory bring this significantly sooner?
The Bitcoin network halves the miner’s reward every 210000 blocks, which should equate to 4 years. The block reward for the first 210000 blocks was 50 BTC, or 5000000000 Satoshis. This halves every 4 years until block 6,720,000 when the reward will be 1 Satoshi for each of the next 210000 blocks. At the next halving, the value falls below 1 Satoshi which is the minimum representable amount within Bitcoin and therefore no block rewards will be offered; miners will be rewarded transaction fees only.
The table below summarises the block rewards:
Block Height
Block Reward (Sats)
0
5000000000
210000
2500000000
420000
1250000000
630000
625000000
840000
312500000
1050000
156250000
1260000
78125000
1470000
39062500
1680000
19531250
1890000
9765625
2100000
4882813
2310000
2441406
2520000
1220703
2730000
610352
2940000
305176
3150000
152588
3360000
76294
3570000
38147
3780000
19073
3990000
9537
4200000
4768
4410000
2384
4620000
1192
4830000
596
5040000
298
5250000
149
5460000
75
5670000
37
5880000
19
6090000
9
6300000
5
6510000
2
6720000
1
6930000
0
If the block time was a consistent 10-minutes from the genesis block (3rd January 2009 at 18:15:05) onward, block 6930000 would be expected on 8th October 2040.
Based on the average (mean) block time from the genesis block to block 762150, block 6930000 would be expected on 1st December 2137, just over three years ahead of the expected date.
Is this realistic? I would not expect so.
The first 10 years of Bitcoin’s existence saw huge gains in hashing power from general purpose processors (CPUs) to more specialist graphics processing units (GPUs) to specific hardware being designed with the sole purpose of hashing (Application Specific Integrated Circuits; ASICs). It has also seen a large increase in the number of individuals and companies investing resources into mining bitcoin, although less so in recent years due to the difficulty targets and the cost of hardware and electricity.
This growth has resulted in similarly huge variations of the difficulty target but with only two week of granularity, the protocol is relatively slow to change to accommodate the increased hashing power.
I would expect that in time, the advances and investment into increasing hash rates will decrease, especially in later years where the block reward is very small. However, this depends on the value of bitcoin and the transaction fee values rewarded to the miner. This stabilisation of hashing power will allow the Bitcoin protocol’s difficulty retargeting to be more effective and I would expect it will drift closer to the 10-minute mark over time. It does not negate, however, that we are ahead at this point, as the retargeting only takes into account the previous 2016 blocks and not all previously existing blocks, and therefore I would expect that we will ‘beat’ the target of 8th October 2040.
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 (28th November 2022) and 765873 (4th 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.
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 (15th 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
Maximum 6-block confirmation time per year
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 7th November 2022 at block height 762150. The average (mean) block time from the genesis block (3rd 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
Average Block Time Aggregated By Year
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
Longest Block Time 2017 to 2021
These represent the longest blocks, however. Analysis indicates that 95% of blocks will be mined within around 30 minutes of the previous block.
