The Bitcoin block size limit is a parameter in the Bitcoin protocol that limits the size of Bitcoin blocks, and, therefore, the number of transactions that can be confirmed on the network approximately every 10 minutes. Although Bitcoin launched without this parameter, Satoshi Nakamoto added a 1 megabyte block size limit back when he was still the lead developer of the project. This translated into about three to seven transactions per second, depending on the size of transactions.

In 2017, Bitcoin’s block size limit was replaced by a block weight limit of 4 million “weight units.” This changed how data in blocks is “counted”: some data weighs more than other data. Perhaps more importantly, it also represented an effective block size limit increase: Bitcoin blocks now have a theoretical maximum size of 4 megabytes and a more realistic maximum size of 2 megabytes. The exact size depends on the types of transactions included.


The block size limit is controversial because there is disagreement over whether or not such a limit “should be” part of the Bitcoin protocol, and if it should, how big it should be.

Satoshi Nakamoto never publicly specified why he added a block size limit to the Bitcoin protocol. It has been speculated that he intended it to be an anti-spam measure, to prevent an attacker from overloading the Bitcoin network with artificially large Bitcoin blocks full of bogus transactions. Some have also been speculated that he intended for it to be a temporary measure, but it is unclear how temporary or under what conditions he foresaw the block size limit being increased or lifted. The code itself that enforces the block size limit certainly wasn’t temporary.

A couple years after Satoshi Nakamoto left the project, developers and users started to disagree on the temporality and necessity of the block size limit. As Bitcoin’s user base grew, some believed it was time to increase or lift the block size limit entirely, specifically before Bitcoin blocks would start filling up with transactions. Others came to believe that the block size limit represents a vital security parameter of the protocol and believed it should not be lifted — or at least, it should be lifted more conservatively. Yet others think that the 1 megabyte put in place by Satoshi Nakamoto was actually too large and advocated for a block size limit decrease

.Adding more complications, since Bitcoin is decentralized, no particular group or person is in charge of decisions like increasing or decreasing the block size. Disagreements on how such decisions should be made, by whom, or if they should be made at all, has probably led to at least as much controversy as the block size limit itself — but this aspect of the debate is outside the scope of this article.

Further Reading: What Is Bitcoin?


Note: Almost anything about Bitcoin’s block size limit and the risks of it being too big or too small is contested, but these are some of the more general arguments.

If Bitcoin blocks are too small, not many transactions can be processed by the Bitcoin network. Broadly speaking, proponents of a block size limit increase (“big blockers”) argue this can have two negative consequences.


Firstly, smaller bitcoin blocks would mean that there isn’t enough space to include everyone’s transactions in these blocks, and the transaction fee “bidding war” to get transactions confirmed would price most people out of using bitcoin at all. Instead, it could lead to a future where only bank-like institutions make transactions with one another, while regular users hold accounts with these institutions. This would, in turn, open the door to fractional reserve banking, transaction censorship and more of the problems with traditional finance that many bitcoiners hoped to get away from.


Secondly — and this is probably what many “big blockers” consider to be a more pressing concern — users would simply give up on Bitcoin altogether because blocks are too small. Perhaps users would switch to a competing cryptocurrency or they would give up on this type of technology altogether.


Note: Almost anything about Bitcoin’s block size limit and the risks of it being too big or too small is contested, but these are some of the more general arguments.

Opponents of a block size limit increase (“small blockers”) argue there are, roughly speaking, three risks if blocks are too big, each of which have several “sub-risks” as well as nuances.


The first of these risks is that bigger blocks increase the cost of operating a Bitcoin node. It increases this cost in four ways:

  • It increases the cost of storing the blockchain, as the blockchain would grow faster.
  • It increases bandwidth costs to download (and upload) all transactions and blocks.
  • It increases CPU costs required to validate all transactions and blocks.
  • The bigger the total blockchain is, the longer it takes to bootstrap a new node on the network: It has to download and validate all past transactions and blocks.

If the cost to operate a Bitcoin node becomes too high, and users have to (or choose to) use lightweight clients instead, they can no longer verify that the transactions they receive are valid. They could, for example, receive a transaction from an attacker that created coins out of thin air; without knowing the entire history of the Bitcoin blockchain, there is no way to tell the difference. In that case, users would only find out that their coins are fake once they try to spend them later on. Even if users do validate that the block that includes the transaction was mined sufficiently (which is common), miners could be colluding with the attacker.

Perhaps an even bigger risk could arise if, over time, so few users choose to run Bitcoin nodes that the fraudulent coins are noticed too late or not at all. In that case, the Bitcoin protocol itself effectively becomes subject to changes imposed by miners. Miners could go as far as to increase the coin supply or spend coins they do not own. Only a healthy ecosystem with a significant share of users validating their own transactions prevents this.

In the Bitcoin white paper, Satoshi Nakamoto acknowledged the above mentioned problems and suggested that light clients could be made secure through a technical solution called “fraud proofs.” Unfortunately, however, he did not detail what these fraud proofs would look like exactly, and so far no one has been able to figure it out. (In fact, some of today’s Bitcoin developers do not believe fraud proofs are viable.)


The second risk of bigger blocks is that they could lead to mining centralization. Whenever a miner finds a new block, it sends this block to the rest of the network, and, in normal circumstances, bigger blocks take longer to find their way to all other miners. While the block is finding its way, however, the miner that found it can immediately start mining on top of the new block himself, giving him a head start on finding the next block. Bigger miners (or pools) find more blocks than smaller miners, thereby gaining more head starts. This means that smaller miners will be less profitable and will eventually be outcompeted, leading to a more centralized mining ecosystem. If mining becomes too centralized, some miners could end up in a position where they can 51 attack the network.

That said, this is probably the most complex and nuanced argument against smaller blocks. For one, even big miners have an incentive against creating blocks that are too big: While they can benefit from a head start, too much delay can work to their detriment as a competing block may find its way through the network faster, and other miners will mine on that block instead. There are also technical solutions to speed up block relay, as well as technical solutions to limit the damage from mining centralization itself, but these solutions come with trade-offs of their own.


The third and final risk of big blocks is that they could disincentivize users from adding fees to their transactions. As long as block space is limited, users must outbid each other to have their transactions included in blocks, and as Bitcoin’s block subsidy diminishes, this will have to become a more significant part of the block reward to support Bitcoin’s security model. Without a block size limit, this incentive is taken away. (While individual miners can still choose to only include fees with a minimum fee, other miners would still have an incentive to include transactions below that threshold — thereby diminishing the fee incentive after all.)

Attentive readers will have noticed that this last argument in particular works both ways. While “big blockers” see high fees as a problem as it would make Bitcoin less attractive, “small blockers” see high fees as a positive as it would benefit Bitcoin’s security.


Bitcoin Core is the predominant — though not only — Bitcoin implementation in use on the Bitcoin network today. Therefore, many “big blockers” have been looking at Bitcoin Core developers to implement an increase. 

Bitcoin Core developers did indeed increase the block size limit, through the Segregated Witness (SegWit) protocol upgrade. By replacing it for a block weight limit, blocks now have a theoretical limit of 4 megabytes and a more realistic limit of 2 megabytes. Cleverly, this was a backwards-compatible soft fork protocol upgrade, which meant that users could opt into the change without splitting the network. However, exactly because this was a soft fork, and not a hard fork as many “big blockers” preferred, they sometimes do not “count” this increase as a block size limit increase at all.

Indeed, Bitcoin Core developers have not deployed a block size limit increase through a hard fork, which is a backwards-incompatible protocol upgrade. This would either require consensus from all of Bitcoin’s users or possibly split the Bitcoin network in two: a version of Bitcoin with the current block weight limit and a version of Bitcoin with the increased block size/weight limit. Users of the version of Bitcoin with the current block weight limit would probably not even consider the hard-forked version of Bitcoin to be “Bitcoin” at all; they might refer to it as “Bitcoin Core coin” or something along these lines.

Perhaps more importantly, the current group of Bitcoin Core contributors seem to have no desire to dictate Bitcoin’s protocol rules, nor do they want to split the network. Therefore, they are unlikely to deploy a hard fork (for the block size limit or otherwise) without broad consensus throughout Bitcoin’s user base for such a protocol upgrade. Given the controversial nature of the block size/weight parameter, it’s unlikely that such consensus will form anytime soon, but it could happen down the road.


There are some alternative solutions to increase Bitcoin’s block size limit, like Extension Blocks, as well as solutions that could achieve something similar, such as “big block” sidechains. It’s not clear that any of these solutions will see the light of day anytime soon either, however; current focus seems more directed toward “layer two” scaling solutions like the Lightning Network.


The short answer is no.

As for a slightly longer answer…

During the heat of the block size limit debate, one of the most popular Bitcoin discussion platforms on the internet, the Bitcoin-focused subreddit r/bitcoin, imposed heavy-handed moderation. This moderation was intended to stop forum users from promoting consensus-breaking software before the greater user base had actually come to a consensus on the best way forward. 

At the time, it was not obvious to everyone that using such software could lead to a split (a non-backwards-compatible hard fork) of the network, and it was often advertised as if it couldn’t. Arguing in favor of a block size limit increase and/or hard fork without directly promoting consensus-breaking software was always allowed.

Whether this constituted a form of “censorship” is perhaps in the eye of the beholder, but what’s certain is that anyone who disagreed with this policy was free to start or contribute to competing Bitcoin subreddits, and this is exactly what happened. The r/btc subreddit in particular become a popular discussion platform for those who favored a block size limit increase hard fork.

Furthermore, Reddit is only a relatively small part of the internet and an even smaller part of the entire world. While there are some other platforms that have been accused of similar censorship (such as the Bitcointalk forum and the Bitcoin-development mailing list), it is hard to deny that the debate took place loud and clear across social media, news sites, conferences, chat groups and far beyond. Anyone interested in hearing about the different arguments had every chance to inform themselves and even those who didn’t care had a hard time escaping the fallout from the debate.

In the end, those who favored a block size limit increase hard fork were unable to convince enough people of their case, and it seems as if some of them have channeled their frustration about this disappointment into anger toward a particular subreddit and its moderators.

(Or maybe, by writing this, Bitcoin Magazine is just part of a great cover-up conspiracy. Spooky!)


When it became clear that Bitcoin would increase its block size limit (among other things) through the SegWit soft fork protocol upgrade, some “big blockers” decided to move forward with a block size limit increase hard fork, even knowing that they would be in a minority and split off into their own network to become a new cryptocurrency. This new network and the resulting cryptocurrency is called Bitcoin Cash.

Since Bitcoin Cash split off from Bitcoin, it has itself implemented several more hard fork upgrades, some of which, in turn, led to even more splits in the network and new cryptocurrencies. The most notable of these is Bitcoin SV, loosely centered around Craig Wright, one of the men who (almost certainly fraudulently) claims to have been behind the pseudonym Satoshi Nakamoto. It has an even bigger block size limit than Bitcoin Cash does.

Reset password

Enter your email address and we will send you a link to change your password.

Get started with your account

to save your favourite homes and more

Sign up with email

Get started with your account

to save your favourite homes and more

By clicking the «SIGN UP» button you agree to the Terms of Use and Privacy Policy
Powered by Estatik