Announcement header or pricing ticker

Bitcoin Network Capacity Analysis – Part 4: Simulating Practical Capacity

This is a continuation of TradeBlock’s block chain and network analysis to address the ongoing block size discussions. It is intended for an audience with at least a fundamental comprehension of block chain technology. If you have not yet done so, we recommend first reading:

Part 1: Macro Block Trends
Part 2: Macro Transaction Trends
Part 3: Miner Incentives


Part 4 – Simulating Practical Capacity


In Part 2 of our Network Capacity Analysis we showed that the bitcoin network, in its current form, can process up to a sustained rate of approximately 3 transactions per second (TPS). Thus far in 2015, the network has realized an average of roughly 1.2 TPS. Owing to increased number of transactions per day (and per block), the trend has been moving higher, as portrayed in the figure below.

In this piece we explore the consequences of increasing transaction volumes in terms of block utilization and wait time – particularly the difference between theoretical and practical realities. We also provide rough estimates of how soon the network might begin to experience noticeable transaction confirmation delays based on current growth rates.

Daily Avg TPS3

A real-world illustration of the network coping with a large number of transactions occurred between May 29 and May 30, during the so-called ‘stress test.’ During this voluntary test, a number of individuals each sent thousands of transactions over the network in order to assess its limitations. Per the chart below, at the peak, there were as many as 26k transactions in the mempool (list of transactions that are waiting to be confirmed in a block). Even assuming the ideal case of only full blocks, it would take more than 14 blocks (or 2.5hrs) for all such transactions to confirm.



Monte Carlo Simulation


In order to devise a practical analysis of block utilization under different TPS instances, we devised a Monte Carlo simulation. The analysis is based on historical transaction sizes and we varied the TPS rates to derive block utilization. For each TPS rate, we simulated 1,000,000 blocks, assessed if the blocks had sufficient capacity to process the full size of transactions that had arrived, carrying over any excess transactions to the next block. See endnotes for assumptions / characteristics of the simulation.


Observations from analysis:
(1): At current TPS of 1.2, the wait time for a transaction to be verified (secondary axis) is negligible, at 0.07 blocks (implying roughly 7% of transactions have to wait more than the current block). Note, in Part 1, we highlighted that ~20% of transactions were above 725KB at present, which coincides with the fact that 16% of blocks that are assumed to be full, per the chart above.
(2): It appears transaction confirmation will begin to experience notable delays at roughly 2.3 TPS – the rate at which average transaction processing time begins to exceed 1 block.
(3): At ~3.0 TPS, roughly the theoretical limit, under current network protocol, the average wait time would equate to roughly 20 blocks.
(4): In reality, the network is likely to experience significant delays well before the theoretical limit (3 TPS) is reached.


Implications for Block Size Debate


Lastly, for argument sake, we simulated the Monte Carlo analysis assuming a larger block size. The chart below shows the output at 8MB block sizes. Interestingly, block wait time becomes noticeable (>1 block wait time) only after 18 TPS and it would take roughly 22 TPS to experience a 5 block average wait time.



Anticipated Timing of Impact on Network Capacity


From the results of the Monte Carlo simulation along with an estimation of expected transaction growth rate, we can also derive an anticipated timeline for when the network might begin to experience noticeable delays in transactions. Recall, in Part 2: Macro Transaction Trends, we estimated the growth rate of transactions per day, based on CAGR (compound annual growth rate) since 2013. Below, we replicate the same chart using average TPS (as opposed to transactions per day).


In summary, the analysis above emphasizes the fact that network capacity effects will likely be experienced earlier than when the theoretical limit is reached in December 2016, assuming transaction growth continues at a similar pace. In particular, by July 2016, the network is likely to see an average wait time of 1 block for the average transaction. Moreover, the analysis assumes miners have a 1MB block size limit. Per the discussion in Part 1: Macro Block Trends, the standard bitcoin client software has a default limit of ~732KB, not the full 1MB, suggesting that the results above may be exacerbated if even a portion of miners cap individual block sizes at 732KB.


View live block chain data with TradeBlock’s Block Chain tools.

The probabilistic characteristics of the simulation were as follows:

  • Blocks used an inter-arrival time with exponential distribution and a mean of 10 minutes
  • Transaction rates were generated with a Poisson distribution, with a mean that varied based on the TPS used
  • Transaction sizes were normally distributed based on the characteristics of transactions that occurred over the last 30 days; mean: 543 bytes; standard deviation: 1,759 bytes


This analysis has been prepared in good faith on the basis of information available at the date of publication without any independent verification. Schvey, Inc. does not guarantee or warrant the accuracy, reliability, completeness or currency of the information in this presentation nor its usefulness in achieving any purpose. Readers are responsible for assessing the relevance and accuracy of the content of this publication. Schvey, Inc. will not be liable for any loss, damage, cost or expense incurred or arising by reason of any person using or relying on information in this publication. This analysis may not be duplicated, shared, or reproduced in its entirety or in part for any reason without the expressed written consent of Schvey, Inc.

Schedule a Demo

"*" indicates required fields