Over the years, Bitcoin has undergone numerous centralizing attacks. The idea of increasing the block size to enable more transactions at lower costs has been around since the project’s infancy.
In October 2010, Core developer Jeff Garzik wrote a “patch” which aimed to “match PayPal’s average transaction rate”. He published it on the Bitcoin Talk forum, where moderator Theymos and Satoshi quickly warned everyone that the code is incompatible with the existing consensus rules of the network – running it would cause users to operate on a parallel chain which is no longer Bitcoin.
However, Satoshi did make a statement which led some into thinking that increasing the block size for scalability purposes is only a matter of time: “We can phase in a change later if we get closer to needing it”. But in the context of requiring this upgrade, he said “if” instead of “when”.
In practice, Satoshi created a consensus rule which fixed Bitcoin’s maximum block size at 1 MB. This limitation became an inconvenience to some business owners who wanted to build their infrastructure or at least settle some of their transactions on the Bitcoin blockchain.
By virtue of the liquidity they were bringing, some business owners considered that the Bitcoin network should upgrade to accommodate their needs – regardless of the centralization concerns which most likely were also convenient to them despite being against the purpose of the Bitcoin project. So instead of figuring out how to make Bitcoin work for their particular use cases with optimizations (such as internal ledgers, transaction batching, and sidechains), they wanted the network itself to change according to their needs.
In the coming years, a pretty dramatic scaling debate took place. Between 2014 and 2017, four major proposals have been made:
- Bitcoin XT (later integrated in BIP 101, which sought to double the block size every 2 years until the year 2036, when the maximum block size would have been 8 gigabytes);
- Bitcoin Classic, which aimed for a more conservative one-time block size doubling to 2 megabytes;
- Bitcoin Unlimited, which allowed the miners to decide the block size;
- SegWit2X, which increases the block size to 2 megabytes and also activates SegWit (the scaling proposal that Bitcoin Core developers proposed as an upgrade which mainly fixes the transaction malleability issue);
These proposals sound really good, except that they effectively make the network more centralized due to the increasing requirements for storage, internet speed, and processing power. Broadcasting one megabyte across the network at an average rate of 10 minutes, while having sovereign nodes store a few hundred megabytes worth of mempool data is feasible even on a Raspberry Pi that gets paired with a poor internet connection.
Arbitrarily increasing this number comes with greater hardware requirements – and according to what we’ve learned from other projects, eventually Amazon Web Services (AWS), Google and Microsoft Azure ultimately become the optimal solutions for handling all on-chain operations. The switch from sovereign self-validation to trust in industrial-level computers is against the spirit of the Bitcoin project and effectively exposes the network to government attacks.
Then there’s also the fee market argument: as the block reward gets reduced in half every 210.000 blocks (approximately four years), the transaction fees must pay the miners enough money to cover their equipment and electricity costs. So to maintain the security of Bitcoin, block space needs to become expensive. Deciding that it should be cheap threatens to compromise network incentives.
Some argued that by increasing the block size, the amount of transactions in a block would also increase. Therefore, Bitcoin’s security budget should get covered. But this is not a certainty – with smaller blocks, there is constant demand regardless of market phases which keeps the miners going; if the blocks are big and there isn’t much activity, then the miners take a financial loss and will switch off.
The block size debate wasn’t only technical, as it also acquired a political dimension. As Chris DeRose argued during season 10 of the Bitcoin Takeover podcast, it’s likely that some people were angry at the Core development and wanted to put themselves in a higher position of power.
Regardless of the intentions, a hard fork (changing the consensus rules in a way which pushes everyone to update their client) was problematic because it would effectively divide the community. No proposal got enough traction from the community – so after three years of debates and Scaling Bitcoin conferences, no solution received enough support.
Some thought that the change was irreversible and premature. Others were concerned about a political takeover that would centralize Bitcoin. Meanwhile, the big blockers camp started implying that not changing Bitcoin is financially beneficial to companies like Blockstream (which develops the Liquid sidechain and the c-lightning client for Lightning network) and encourages short-term use of altcoins.
Unfortunately, a hard fork did happen on August 1st 2017. The big block crowd (consisting of XT, Classic, and Unlimited developers and supporters) has embraced the new Bitcoin Cash chain, whereas the users backing the real and decentralized Bitcoin have activated SegWit via UASF (user-activated soft fork).
A soft fork is a network upgrade which doesn’t break consensus. Activating it is completely optional, but at some point in the future it’s expected to become the norm. At scale, it accomplishes the same goals of a hard fork – as all users eventually update their node software to include the changes. But those who don’t want to run the new code are free to opt out while remaining on the same network as everyone else.
From a technical point of view, SegWit is a masterpiece of elegant design. It’s exactly the kind of code that should be expected from the people who spend the entirety of their day working with Bitcoin code. Theoretically, it can make blocks extend up to 4 megabytes during times of high demand. But practically speaking, 2 megabytes is more common.
To date, the biggest Bitcoin block ever mined is number 682482, which Poolin discovered on the 8th of May 2021. It has a size of 2.42 megabytes and still exceeds the average size of a BCH block (as the Bitcoin Cash network, despite enabling big blocks, didn’t get traction and has very little demand for block space). This situation enabled the rather funny question “Which Bitcoin has the big blocks, after all?”.
Bitcoin didn’t really eat popcorn during this dramatic phase of its existence. But it did remain decentralized and accessible to anyone around the world. Second layers like the Lightning network and sidechains like Liquid, RSK, Statechains and Drivechains play the scalability role just fine. They settle transactions faster and at lower costs, but lack the security of the base layer – which is a tradeoff that everyone must consider depending on the amount that they’re sending.
But for Bitcoin’s resistance against centralizing hard forks, we must thank the conservative and stubborn Core developers (especially Greg Maxwell, Pieter Wuille, Johnson Lau, Eric Lombrozo, and Luke Dashjr), as well as every user who supported SegWit, Lightning, Liquid, RSK, Counterparty, Omni, Statechains, Drivechains, and every other proposal which helps Bitcoin scale and/or acquire more functionalities. This comic is for all of you.