tl;dr: under full SegWit adoption you should expect blocks in the 1.6-2 mb range, with larger outliers.
How big will Bitcoin blocks get under reasonable assumptions? This investigation began with the simple realization that Bitcoin had recently hit an all time high in its average block size over a 24 hour period, at 1.20 mb.
You can find the chart here: we put it together with our chartbuilder tool. We don’t host that data in our default charts, so you have to combine two metrics to get there, using BTC.blockSize/BTC.blockCount.
What’s interesting is that the blocksize ATH on November 20th didn’t also represent an ATH in data transmitted over the Bitcoin system — that came on January first of this year. We are 24% off that peak now. The reason for the difference is that blocks are actually coming more slowly now. In January, hash power was being added faster than the difficulty adjustment could cope with, and blocks were flying in at a rate of 174 per day (the average “should” be around 144) versus 130 today.
It’s well understood that SegWit represents an increase in capacity as well as solving the transaction malleability problem. But the exact increase is obscure. Forecasting it involves grappling with obscure concepts like block weight. Some efforts (Jimmy Song, BTC Monitor) have been made to estimate the size in bytes of blocks in a post-Segwit world, but most of these were written prior to August 2017. We now have a year’s worth of adoption data and more information on the transaction mix, so we can recalibrate those predictions. It’s important to be able to reason about this, as the byte size of blocks informs the bandwidth and storage requirements of running a full node. If blocks were to go to the maximum of 4 mb and stay there, running a non-legacy node would become considerably more costly from a bandwidth perspective, even if signature data does get eventually pruned. And, as we recently learned with Bitcoin Cash, larger blocks can have an effect on propagation and can serve as an unintentional self-DOS.
Let’s briefly recap how SegWit works. Recall that the objective was to solve the transaction malleability problem, provide a capacity boost, and do this in a backwards-compatible way. What SegWit actually does is move signature data from the middle to the end of a block and strips it when sending it to legacy nodes. It also restricts blocks by a new concept called “block weight” instead of mere block size. Effectively, the outcome is that the upgrade is backwards-compatible with legacy nodes who receive valid, sub-1 mb blocks with the signature data omitted. And the effective capacity of the system increases by approximately a factor of two. Again, it would have been trivial to increase capacity by increasing the block size parameter (Bitcoin Cash style) but the Bitcoin developers wanted to solve the malleability/capacity problem as an opt-in soft fork and this was one way to do it.
Despite a lot of strife, the upgrade was eventually adopted. SegWit is now used in roughly 44 percent of all Bitcoin transfers, and the block size is reacting predictably.
So just how big will Bitcoin blocks get? The answer isn’t simple at all. It depends, in fact, on three variables:
- The fraction of overall transactions that use SegWit
- The prevalence of signature data within blocks
- (Less crucially) the adoption of native SegWit addresses (also known as bech32 addresses)
With a year’s worth of evidence, we can make reasonable assumptions about the first variable; the second is a known quantity; and the third is largely irrelevant right now.
To put it as simply as possible, while blocks are bounded by a ‘block weight’ of 4,000,000, using SegWit addresses instead of legacy addresses allows you to use that block weight more efficiently. One mb worth of legacy transactions would occupy the entire block weight, but SegWit transactions are “denser,” so to speak, and fill the 4m block weight with more transaction information.
We used a code snippet published by BTC Manager and Jochen Hoenicke to create a visualization of block size under various conditions. Naively assuming that bech32 addresses end up being widely used, the formula for block size in kb is the following:
1000/(((1000–0.1*SW*SIG)*4+SW*SIG*0.1)/4000)
Where SW is the percentage of transactions that use SegWit and SIG is the percentage of data which consists of signature data. In normal usage, around 65 percent of transaction data consists of signature data, so we used that as the basis for our chart.
The other dimension is bech32 usage, which unlocks more capacity. They are not yet common. Today, they are used in less than one percent of all transactions, according to p2sh.info. Instead, p2sh addresses are more popular. P2sh SegWit inputs/ouputs are slightly larger than native SegWit inputs/outputs, so using p2sh use reduces the ability of SegWit blocks to get very large. Thus the first chart assumes no bech32 address use.
[Chart no longer available]
You can find the state of the network today by triangulating 45 percent SegWit transactions and 65 percent signature data, which gives you about 1200 kb per block. Lo and behold, blocks are about 1200 kb on average today — 1240 kb if you exclude empty blocks. This chart is somewhat unsatisfying because it doesn’t get us to 4mb with full SegWit and blocks consisting of pure signature data, which it should. Naively assuming full bech32 usage gets us the pure (albeit less presently realistic) result:
[Chart no longer available]
This lets you reason about block size in a meaningful way. As stated, typical blocks consist of roughly two thirds signature data. It’s virtually impossible to create a block consisting of only signature data, so the 4 mb block is mostly theoretical. That said, certain kinds of blocks do use more signature data. Take block 545501, mined on October 12th of this year. It consists of a large number of 200 input/1 output transactions: it’s a consolidation block. Inputs have a larger share of signature data, giving it a higher-than-usual signature fraction. This is what enables it to get to 2.32 mb. So while the norm is much lower, individual blocks can be highly idiosyncratic and can push the limits of the system.
Despite the claims by some that SegWit is “just an accounting hack,” it genuinely does provide a capacity increase and a boost to the actual throughput of Bitcoin. If SegWit is widely adopted (95% usage), and native addresses replace p2sh as the dominant mode of using SegWit, we can realistically expect blocks to average 1.9 mb. In fact, this isn’t a coincidence — a rough doubling of total capacity was what the Core developers were after.
If p2sh stays more popular, this will look more like 1.7 mb. Outliers will range up to about 3 mb. Even at 75 percent SegWit adoption, your default block will be about 1.6 mb. Blocks can theoretically reach 4 mb but we are not expecting to see any of those any time soon — there is no situation where regular usage of Bitcoin would yield a block that size.
When we started this exercise, we didn’t realize that forecasting the size of blocks under various usage patterns would be so complex. The introduction of block weight definitely complicates the process. To conclude: the upper bound of the system is theoretical and that normal usage will leave us in the 1.6–2 mb range, with outliers up to ~3 mb, as adoption grows to 75 percent and beyond.
We’d like to thank Jochen Hoenicke for his assistance with the block size formula.
