Determining the ideal block size for Bitcoin, a story of three graphs

One benefit of seeing congestion this early in Bitcoin’s life is we get a great set of data of the network under load. In this study, we’ll take a look at Bitcoin’s transactional data to see if it points to an ideal blocksize, if there is such a thing.

Bitcoin has been operating for 8 years, from the early days when we only saw a few transactions in each block through until today, where blocks are crammed packed and congestion is the norm. One benefit of seeing congestion this early in Bitcoin’s life is we get a great set of data of the network under load. In this study, we’ll take a look at Bitcoin’s transactional data to see if it points to an ideal blocksize, if there is such a thing.

Is the Bitcoin Network keeping up?

The chart above shows the transactions per second on the Bitcoin network over time. It’s on a log graph which shows exponential growth as straight lines. Bubble size denotes the size of Bitcoin’s mempool, a kind of storage tank that temporarily holds transactions before they are processed.

Despite users complaining that the blocks are now crammed full and that the network overloading, this graph tells a surprising story. While we see by Q4 of 2016, the mempool swelling to take up peak loads, the network catches up off-peak. The network is keeping up with exponential demand.

Yes, we are seeing congestion, but no, we are not yet turning away any significant transaction volume due to this congestion. If this was true, we’d see this as a downwards arc on our log graph instead of our straight line. But it’s quite obvious from the swelling of the mempool we’re close to the limits and our downward arc is likely in the weeks and months ahead as transactional volume starts to be turned away.

Projecting future demand

We can use this chart to project future transactional demand simply by extrapolating the our straight line… by the next block reward halving in 2020, we can expect around 20 transactions per second on the network.

Having predicted 20 transactions per second by 2020 using this chart, I’ll now explain why this probably won’t be true.

The Bitcoin network is mainly used as a store of value, but by 2020, the Bitcoin price volatility should be stable enough for it to be used as a currency so I suspect we’ll see a step change upwards in demand as merchants start using it for general commerce.

Something like the Lightning Network that allows for nearly unlimited transactions for the cost of two normal transactions will alleviate some of that on-chain transactional demand, but we’ll also see new use cases open up such as micro transactions from the Internet of Things which will drive new demand.

The two takeaways is that we can use this chart for predictions, but they will only be valid as long as Bitcoin’s use case remains the same, for now it’s store of value, in future it could expand greatly.

A side note on “coffee”

Users of the Bitcoin network, and in particular businesses, tell us that fees have increased to the point where paying for coffee and other even smaller micro transactional use cases are not viable anymore. The argument is that Bitcoin is losing utility for general commerce, therefore the Bitcoin network is at risk of declining as payments move to cheaper competing altcoin technologies.

Clearly we see that the exponential growth of transactions per second hasn’t skipped a beat. This tells us “paying for your coffee with Bitcoin”, though much talked about, was essentially a negligible aspect of the network transactions. The network is keeping up. It’s core use case has always been transmitting and securing high values securely.

As mentioned earlier this will change as Bitcoin volatility becomes stable enough to be used as an everyday currency. My numbers show this will be around 2019, so we’ve got time up our sleeves to expand the transactional throughput orders of magnitude bigger. This does not discount the fact businesses today are experiencing pain from high fees and slow confirm times, which we’ll look into further.

What’s the ideal block size for maximum miners revenue?

Maybe a year ago, there was debate among miners whether big blocks or small blocks would yield them higher profits. Some even saying big blocks would allow more transactions to be carried and therefore more fees would be generated. However by Q4 2016 we saw the impact of momentary peak hour congestion hit the network. It’s been clear that a demand driven market has emerged, resulting in much higher revenues.

Here’s a graph plotting the fees impact of congestion on the network.

As average blocksize hits 95% of maximum, the mempool starts ballooning, users start leapfrogging one another with their fees in order to get into the next block without delay. As a result the fees start to hockey stick… just a pure vertical climb in fees.

If you were a miner, solely motivated for short term profit, you would want the maximum blocksize to be small enough to always keep those blocks 95% filled. You’d want to limit the supply of transaction space so the fees competition gets rabid. The optimal block size for miners is “small enough to drive congestion”

Question: What would 8MB blocks have produced in mining fees?

Lets run a hypothetical scenario… say Bitcoin XT was approved and we have 8MB blocks today, what would miners be earning from fees?

Obviously, supply overwhelms demand and dynamic fee algorithms in wallets will set lower fees according to network conditions. We can use our graph to estimate the new earnings.

Today’s transactional load is using 0.95MB of space per block on average, you can read this from the bubbles at the right of the chart (you can see this more clearly at Blockchain.info). This would be a 12% fill rate with 8MB blocks. At 12%, the graph shows miners earning 0.1 BTC per block from fees.  Today miners earn 1-2 BTC in fees with 1MB blocks, so 8MB blocks would serve to reduce this by a factor of 10-20x.

The ideal block size for users

Okay, let’s move on to the what users want – fast confirmation times, reasonable fees and good security. We’ve seen the speed of the network grind to snails pace at peak times. The graph below shows how long we are waiting for a confirmation as the blocks reach their maximum.

The bubble sizes denoting the number of transactions in the mempool just goes crazy whenever blocks are 95% or more filled, and confirm times just go vertical. Even before things get crazy at around 80%, the median confirm times start to deviate upwards significantly.

It’s important to note that the higher the fees we pay as users on the system, the more security we get as miners can afford to compete with higher hash power with more revenues. This becomes super important in due time as the block reward subsidy drops with each halving event. Currently fees make an important part of miners revenue – 1.5 BTC fees vs 12.5 BTC in reward subsidy. At the next halving when the subsidy drops to 6.25 BTC the fees component will become critical to the security of the network. Thus there is a “goldilocks zone” for fees, not too cheap for better security and not too expensive.

My conclusion here is the ideal block size to keep confirm times from ballooning while keeping fees and security reasonable is around 80% of blocks being filled.

Putting it all together

So we have 3 results so far.

  • 1MB blocks currently has kept pace with network demand so far, despite undesirable delays in transaction processing times and expensive fees during congested time.
  • The most optimal blocksize to maximise miner’s revenues is any size small enough to congest the network which is around 95% filled or more. Getting congestion and an onset of “leap frogging” fees scenario between users would be the optimal miners game to play.
  • The transaction confirmation times start to suffer when blocks are above 80% filled. At this level fees are reasonable but not exorbitant, but not too cheap to substantially impact the security model of Bitcoin as the block reward subsidy diminishes in future years.

The optimal network, based solely on the economic game theory, will need to balance security/miners revenue, speed, and low cost of transactions.**

Given these constraints, I think the best blocksize would have to be dynamic, adjusting to network transactional demand to keep it inside the sweet spot as much as possible. The goal would be to keep the blocks at around 80% filled. At this setting the median confirm times will be unaffected, yet will keep the demand driven fees market high enough to be significant for miners and therefore the security of the network in years to come, but it would be still 4x cheaper than todays congestion driven price.

In this light, Monero’s approach to dynamic blocksizing where the adjustment is algorithmic according to network load seems ideal. It would constantly be adjusting to keep the best balance between miners revenue, security and reasonable fees for users.

** These considerations completely ignore technical aspects of the network which others have covered at great length such as block propagation times and Great Wall of China impacts.