Summary and TL;DR

Blockchain "throughput" is often measured in Transactions Per Second (TPS), but transactions are a poor indicator of useful actions. It's counterintuitive, but on blockchains with high percentages of batch transactions like Bitcoin, the most efficient blocks actually have the lowest TPS.

For example, the theoretically most-efficient 4M WU Bitcoin block would consist of 1 single transaction packed with 32250 individual 31-vByte P2WPKH Bech32 UTXO output addresses. This would make Bitcoin a 0.002 TPS network despite performing at a much-higher 53.7 useful Transfers Per Second (TfrPS), which is a better metric for useful actions.

In this analysis of over 2 million Bitcoin transactions, I determined that if Bitcoin's blocks were 100% filled, its TPS throughput given the current mix of transaction types is a disappointing 3.9 TPS. This is a major limitation because if even 1% of the world's population used Bitcoin, they would only be able to make 1 on-chain transaction once every 240 days. However, this metric is misleading due to batch transactions.

About 20% of transactions on the Bitcoin network use batching, and this is enough to effectively increases useful throughput from 3.9 TPS to 16.8 TfrPS (still slow, but noticeably higher).

(While this analysis focuses on Bitcoin, other blockchains are also able to do this. But this post is already too long to include a comprehensive analysis of multiple blockchains. This was researched to the best of my knowledge. Please let me know if you spot any errors.)

Theoretical Limit of Batching Ouputs

Theoretical Limit of Batching Inputs

Intro - Throughput Benchmarks

Throughput is the rate at which data travels through a network. For cryptocurrency networks, this is often measured by Transactions Per Second (TPS) because that's the easiest metric to measure on all networks, and the data is ubiquitous. But this is an inadequate measurement of throughput because it doesn't reflect the true rate of useful actions.

Benchmarks: For gaming computers, there is no single benchmark that covers everything. Instead, they are divided into many different categories such as: single-CPU, multi-CPU, 2D graphics, 3D graphics, physics, ray-tracing, etc. There are also composite benchmarks that attempt to estimate typical usage like: office use, gaming use, watching media, video editing, 3D modeling. One way of benchmarking crypto throughput is to divide into different types of "useful actions".

Useful action: A useful action could be a transfer, swap, NFT mint, contract create/destroy, deposit/withdrawal. For batch transactions, a single batch transaction could contain 5000 useful actions, and a single contract could create 100 NFT mints. So what looks like 1 TPS could actually be 5000 useful Transfers Per Second, which I'll call TfrPS.

Useful action in Bitcoin: Bitcoin does not support advanced smart contracts, so there is only one type of useful action: a transfer. You'd think it would be one of the easier blockchains to benchmark. However, this is far from true due to the numerous different types of addresses.

Bitcoin now has P2PKH, P2SH, P2WPKH, P2WSH, P2WPKH/P2WSH-within-P2SH, and P2TR addresses, all with different input sizes, output sizes, and signature/witness sizes. This is due to the Bitcoin community's ridiculously unhealthy obsession with avoiding hard forks (e.g. the Segwit 4M weight fiasco that inevitably ended up splitting the community in a hard fork anyways). Each of the combinations of addresses and headers generates a different size of transactions, each with different TPS and TfrPS measurements. (So Bitcoin, please Go Hard FORK yourself and get rid of all these outdated, inefficient address types.)

About 20% of Bitcoin transactions are batch transactions, which I consider any transaction with more than 3 UTXOs. These are almost exclusively done by exchanges. I've personally noticed BlockFi and Gemini doing small batch transactions of ~10 UTXOs with my accounts, and Coinbase doing a 1:100 batch transaction with them.

Analysis

Tools:

Most of my data is from blockchair.com, blockchain.com, blockstream.info, and btcscan.org for analyzing blocks and transactions. Blockchair was particularly useful because it provides a bulk TSV data download way faster than most API services. Gotta love the speed of traditional databases. I used Google Sheets to compile the results, which was annoyingly slow due to its 10M-cell limit, so I had to optimize by splitting calculations across multiple sheets. Lastly, I used this calculator to double-check my work.

Overall Measurements from the Blockchain:

Overall, across 1271 blocks and 2.19M transactions, there were 1.47B bytes, 3.82B weight units (WU), and 9.60B transfers. On average, the blocks would've been 1.54MB on average if full. The actual TPS with the partially-full blocks was 2.88. Had the blocks been full, they would have seen a throughput of 3.9 TPS and 16.8 TfrPS.

Transaction count varies as much as 10% from day to day. However, the results after correcting for block fullness are quite stable.

• Daily TPS range: 2.8-3.2
• Daily TfrPS range: 11-13
• Daily TPS with 100%-full blocks: 3.9
• Daily TfrPS with 100%-full blocks: 16.8, which is 4.3x the max TPS

What this means is that the Bitcoin blockchain is getting 3.3x more useful actions (TfrPS) than what the TPS metric suggests.

Frequency of Transaction Types

Transfers per Transaction:

Most single-transfer transactions actually contain 3 UTXOs instead of 2 because there is a leftover change UTXO.

Within the 2M transactions, here's the percent breakdown of what kind of transactions were on the blockchain:

Batch Type	Frequency
1:1	78.7%
2 Batch	6.9%
3 Batch	3.6%
4-5 Batch	3.4%
6-10 Batch	3.0%
11-50 Batch	3.0%
51-200 Batch	1.3%
200-1000 Batch	0.2%
1000+ Batch	0.0%
Total	100.0%

Size Details

Block size: Each Bitcoin block has a maximum of 4M weight units (WU), mined an average of once per 10 minutes or 6667 WU/s. On average, 75% of the daily block space was filled.

Transaction weight = 3x base size + 1x full size = 4x (header + inputs + outputs) + 1x witness size

UTXO sizes (vBytes)

UTXO sizes (vBytes)	Description	Input Sizes	Output Sizes
P2PKH	Legacy 1x	148	34
P2SH	Legacy 3x script	153	32
P2WPKH	Segwit	68	31
P2WPKH in P2SH	Script-wrapped Segwit	91	32
P2WSH	Segwit script	68	43
P2WSH in P2SH	Script-wrapped Segwit script	103	32
P2TR	Taproot	58	43

• These vByte sizes include the Witness size. Sometimes the size is 1-2 vBytes smaller due to the Witness having leading zeroes that get trimmed.
• "Scripts" are usually Multisig addresses
• Transactions also have a header, which is normally 10-11 vBytes.
• All the large batch transactions have a good mix of output address types because their recipients are random. On average, they're around 31-32 vBytes since Multisig and Taproot outputs are uncommon.

Common Transaction Weights

These are the UTXO combinations I noticed the most often in the 400-1000 WU range. Almost all batch transactions fall beyond this range, and they vary too much in size to be included here. The largest ones were ~400000 WU.

• 437-439 - Segwit to P2WPKH (common)
• 441-442 - Segwit to P2SH (common)
• 449-450 - Segwit to P2PKH (common)
• 561-574 - Segwit to 2x various (common)
• 658-661 - P2SH to 2x various
• 756-764 - P2PKH to various
• 833-845 - 2x Segwit to 2x various
• 885-900 - P2PKH to 2x various, Segwit to 3x various

​Distribution of Transactions by Weight Units

Theoretical Limits to Batch throughput

• Common Segwit (P2WPKH) transactions: You can increase throughput from 11.8 TfrPS to 53.7 by batching outputs, and from 11.8 TfrPS to 24.5 by batching inputs.
• Common Wrapped Segwit (P2WPKH-in-P2SH) transactions: You can increase them from 12.4 to 18.3 TfrPS with batch inputs.
• Lightning on-chain transactions use a 2/2 Multisig or P2TR Taproot address
• Note that these are purely theoretical limits because there will always be a mix of different types of transactions. You can't expect everyone to join into a single transaction. That would require everyone to use a single centralized exchange. And you can't expect users to only batch outputs, not inputs. This is why the real max throughput is 16.8, which is far lower than the theoretical limit of 53.7.

Batching Outputs - Throughput

Batching Output (1:n) TfrPS	1	2	5	20	200	MAX
Segwit (P2WPKH)	15.2	11.8	28.5	45.3	52.8	53.7
Segwit script (P2WSH)	13.6	10.1	22.7	33.7	38.2	38.7
Wrapped Segwit (P2WPKH in P2SH)	12.4	10.0	25.4	42.7	51.0	52.1
Legacy (P2PKH)	8.7	7.4	20.3	37.8	47.7	49.0
Legacy script (P2SH)	8.5	7.3	20.6	39.4	50.5	52.1

Batching Inputs - Throughput

Batching Inputs (n:1) TfrPS	1	2	5	20	200	MAX
Segwit (P2WPKH)	15.2	9.4	17.5	22.6	24.3	24.5
Segwit script (P2WSH)	13.6	8.7	16.9	22.3	24.2	24.4
Wrapped Segwit (P2WPKH in P2SH)	12.4	7.4	13.4	17.0	18.2	18.3
Legacy (P2PKH)	8.7	4.9	8.5	10.6	11.3	11.3
Legacy script (P2SH)	8.5	4.8	8.3	10.3	10.9	11.0

Side Notes

Outliers

Smallest transactions: Technically, the smallest transactions are [396-397 WU, 1:1 P2TR (Taproot) to P2WPKH] transactions, but they're very rare (< 0.5% of transactions), and they're not used in batch transactions. So they're not relevant to this analysis.

Largest transactions: Technically, the largest batch transactions date back to 2015. They each held 20000 transfers like this one: 30b3b19b4d14fae79b5d55516e93f7399e7eccd87403b8dc048ea4f49130595a, but they were useless wasted block space sent to OP_RETURN without any metadata. If anyone knows the history behind these transactions, please enlighten me.