mrb's blog

The case for increasing Bitcoin's block weight limit

Keywords: bitcoin blockchain blocksize scalability debate

March 2017 was a significant moment for Bitcoin: the average block size bumped into the 1MB limit, stunting the growth of the transaction rate ever since. Many arguments are made about how to increase capacity (changing the limit, developing off-chain solutions, etc.) However very rarely are discussions centered around facts and data such as estimating the impact of the stunted growth so far and the urgency of the situation. Also troubling is the widespread misconception that the activation of segwit on August 24th has given Bitcoin short-term relief.

In reality, I estimate Bitcoin missed the opportunity to process over $20 billion of transactions. Low segwit adoption keeps the network seriously congested to this day: over 90% of blocks are over 90% full. And given the current rate of increase of segwit adoption, the network will likely remain congested for the foreseeable future.

This post is not about segwit2x, a grassroots change initially proposed by Sergio Demian Lerner on bitcoin-dev to double the block weight, and which is supported by signatories of the New York Agreement. Although I support it myself, segwit2x is a complex topic that deserves its own blog post. Rather, the goal of this post is only to demonstrate the impact of congestion and the urgent need to increase the block weight limit in one way or another (not necessarily segwit2x.)

Average block size

Let’s start with a chart showing the average block size over the last 3 years:

Stunted growth

Up until March 2017 the transaction rate growth was predictible. Had there not been a 1MB limit, it seems the market demand for transaction capacity would have been for approximately 1.2MB blocks today. By failing to capture an extra 0 to 0.2MB of transactions, that is 0 to 20% extra transactions through the period March to October (daily transaction volume of $300-1000 million) Bitcoin failed to capture $20 billion worth of transactions over the last 7 months.


I have to touch the subject of the mempool because the human—not technical—dynamics that affect its functioning are often misunderstood.

It is a mistake to think that “if the mempool is not growing, then Bitcoin is not congested.” When congestion begins, the mempool starts growing, some transactions in it are delayed 1 day, 2 days, 4 days… eventually some users lose patience and avoid sending transactions (Bitcoin fails to capture them), hence reducing pressure on the mempool, which starts shrinking until it is back to normal or even empty. And the cycle repeats immediately: users send more transactions, the mempool grows, they lose patience, and avoid Bitcoin, etc.

Under perpetual congestion conditions the mempool will never grow indefinitely.


I hear you say “but segwit allows up to 4MB blocks, so the problem is solved, right?

No! Segwit replaced the size limit of 1MB with a weight limit of 4 million weight units (“4M”). Therefore the size of blocks in bytes is no longer relevant to estimate the level of congestion. Instead we need to look at the weight of blocks in weight units. For example average blocks of 1MB/4M would indicate congestion, while larger blocks of smaller weight such as 1.5MB/3M would indicate no congestion.

The weight of blocks is a crucial metric, yet I am not aware of any Bitcoin statistics site that charts it. Not even (even though weight data is present in their JSON file.) It is almost as if segwit proponents who believe segwit will solve scalability wanted to hide how congested the network really is…

So I charted the data for the last 1000 blocks as I am typing this (blocks 490698 through 491697, roughly October 19th-25th):

Over 90% of blocks are over 90% full

913 out of the last 1000 blocks have a weight greater than 3.6M (90% of 4M), in other words over 90% of blocks are over 90% full. This is a clear sign that congestion is still seriously impacting Bitcoin. And the direct cause of this congestion is low segwit adoption which sits at only 8% two months after activation:

Segwit adoption rate

(Opinions abound as to why it peaked at 17% and fell to 8%. Some claim a group was faking segwit adoption by spamming the network.)

An argument I sometimes hear is that “there is no severe congestion, because if there was, segwit adoption would increase more sharply.” This is flawed reasoning because other factors—independent of congestion—slow down segwit adoption: wallet software and services are not upgraded to use segwit by default, users are unaware of how to use segwit or why they need it, etc.

As a result, the average block size was only able to grow by a paltry few percents from 1MB to 1.02-1.04MB in two months, significantly undersupplying the market demand (which seems to be for approximately for 1.2MB blocks, see above.)

Market share

So Bitcoin blocks have been full since March. What else happened in March?

Bitcoin market dominance

Bitcoin lost market share, from 85% down to 55%. In my humble opinion, the coincidence of the drop starting exactly in March is a sign that the congested network was the direct cause of Bitcoin’s loss.

This could be explained by one theory: users being fed up with the congested network and high transaction fees, and moving to altcoins with less congestion and lower fees.


Interestingly, data points seem to support this theory. The transaction rate of Ethereum, Litecoin, and Dash (and maybe others) also started increasing in or around March 2017:

Ethereum transaction rate

Litecoin transaction rate

Dash transaction rate

If anything, this is more evidence potentially validating the theory that some users are abandoning Bitcoin for altcoins due to congestion.

Another explanation about why Ethereum’s transaction rate went up so sharply is because of the ICO boom. However ICOs are hardly responsible for all of it, and they do not explain the rise in Litecoin and Dash which are much less often used to fund ICOs.

Notice that Ethereum already processes 450k transactions daily, which is 70% more than the 260k processed by Bitcoin… This might be a slightly unfair comparison because unlike Ethereum, some Bitcoin transactions are batched. To be more correct we should compare the number of Ethereum transactions to the number of Bitcoin transaction outputs (and for transactions with 2 or more outputs, subtract 1 because one of them is likely the change output.) However batching is not that common so the comparison between the number of Ethereum and Bitcoin transactions is mostly valid.

Pragmatism vs. idealism

How do we resolve Bitcoin’s congestion? Instead of increasing the block weight limit, I think we all agree more ideal solutions would be the Lightning Network, Mimblewimble, transaction batching, etc.

However these solutions are either not ready or not practically usable at scale today.

In essence this is the root cause of the scaling debate: the community is divided between big blockers who want a pragmatic quick fix, and small blockers who are more idealistic.


Will increasing the block weight limit hamper decentralization? I do not believe so.

Firstly, the amortized cost of running a full node is only $5 per month, an amount small enough that running one is within reach of enough individuals to protect decentralization.

Fun comparison: the average transaction fee right now is over $3, therefore running a full node costs less than the fees for sending 2 Bitcoin transactions a month.

Secondly, history shows that as blocks have grown over the last 2 years from 0.5 MB to 1.0 MB the number of full nodes has in fact increased, helping decentralization. That is because bigger blocks = more Bitcoin adoption = more individuals interested to and able to run full nodes. Generally speaking we can expect the number of full nodes to increase as blocks become bigger (up to a certain point.)

Increased node count


It is easy to get distracted by all the good news Bitcoin has been receiving lately: all-time-high price around $6000, a lot of venture capital injected into Bitcoin companies, etc. However this rapid success could disappear just as quickly if Bitcoin fails to increase its capacity soon.

Segwit is too little too late: some users not adopting it are causing congestion for all users. We needed solutions to scale in March 2017. We needed segwit activated a year ago so adoption would be at 50%+ today. We needed all this before Bitcoin already failed to capture $20 billion worth of transactions, lost 30% of market share, and lost hundreds of thousands of transactions daily to altcoins…

Bitcoin needs a pragmatic fix, a one-time reasonable increase of the block weight in order to relieve congestion right away and give us some breathing room. We can do this while keeping the costs to run a full node low ($5/month) and the network decentralized.


mugen wrote: Well-written and supported with hard data. Thank you for sharing. 26 Oct 2017 23:26 UTC

fresheneesz wrote: This article has good points, but its analysis of decentralization is woefully unthoughtful. It completely ignores the primary argument of block propagation time. I wrote about that here: 27 Oct 2017 04:27 UTC

cryptohawk wrote: Great write-up. Dumped BTC for BCH a while ago... 27 Oct 2017 11:12 UTC

mrb wrote: fresheneesz: Block propagation is a non-issue. Most discussions about it (including yours) ignore or predate Compact Blocks which pretty much solved the problem. A nominal 1 MB block is propagated in a compact block as small as 15 kB. See BIP 152 27 Oct 2017 15:17 UTC

nucino wrote: As you say real cause is low segwit adoption, and many major exchanges didn't even implemented segwit, also current mempool statistics doesn't seem to fit this narrative. 29 Oct 2017 22:33 UTC

mrb wrote: nucino: the point is we can't artificially increase segwit adoption, so some users not adopting it are causing congestion for all... Also your exact mempool argument is already refuted, read the Mempool section. 30 Oct 2017 17:51 UTC

fmarcosh wrote: Is the best article I've read in bitcoin scaling issues. Thank you for sharing. 02 Nov 2017 18:39 UTC

reggz wrote: Salut! Great blog and great article, thank you.

I'm not at all enthusiastic about this battle of egos and agendas that's become the scaling debate. I think the lack of consensus and deployed means towards adopting Segwit is actually a little sad.
You're one of the rare person I read who presents a sound set of arguments for the larger-blocks side of the debate (props for that). I also agree that a "one-time pragmatic fix" would help, but I don't think it can happen because each side has become so infatuated with their own ego and ideologies, that the bias seems to me now irreversible. It comes down to deciding which developers you want to trust the most, and which community do your thoughts align with the most. For me, the answer to that is evident.

What is your position?
Is it that picking a side on this debate is dumb, and that we should only go for the most pragmatic options?
Or are you firmly positioned in one end of the debate?
Or are you being a contrarian for the sake of argumentation?
Or do you have an issue with particular devs?

Je suis curieux :)

Anyways, je vis a bernal heights a SF et en californie depuis des années. Pti' bonjour d'un autre geek francais du coin :) (PS: Si tu joues du jazz/funk, fais signe!).

05 Jan 2018 18:19 UTC

mrb wrote: Yes the debate has become ideological instead of technical. My position is that I favor a block size increase for technical reasons. I wouldn't say my position is "firm", but I "tend" toward this side. I am not in a feud with particular devs. I am not being contrarian by principle. All the arguments I have seen for sticking with a 4M weight limit have simply failed to convince me (none of these arguments are based on measurable facts or data.)

Au revoir!
09 Jan 2018 17:31 UTC

Reggz wrote: Fair enough, thanks for answering. 12 Jan 2018 07:18 UTC

reggz wrote: And as far as plain ol' pragmatism goes, I completely agree. But that's about how far it goes. 12 Jan 2018 07:22 UTC

reb0rn wrote: You look it from tech level when evil ppl as roger ver and jihan fight it from political and control level, they wanted to use big block interest and ppl as you to take over bitcoin
That failed now their miss guided flock have BCH which is worthless
It never was tech side primary is was planed takeover which we now know, failed
You just can`t have decentralization if anyone can tweak as they like
17 Aug 2018 22:55 UTC