In 2015, a heated and important debate resulted in the first dispute involving the Bitcoin network. The disagreement became known as the Blocksize Wars and was about how big the emitted blocks should be, but it also left big lessons on how easy it should be to change the protocol's rules.
Before talking about the block size war I will explain what blocks are and what block size is.
Blocks are groups of transactions that are confirmed and transmitted to a blockchain.
The block size limit, or blocksize, is a security parameter that limits the amount of transactions that can be committed and recorded on the network.
In the case of Bitcoin, the limit introduced by Satoshi Nakamoto on Bitcoin was 1 MB and was intended to keep the blockchain small in its early days, possibly as an anti-spam measure, preventing bad actors from spamming the Bitcoin network with artificially huge blocks. , full of fake transactions.
As transaction volume increased with the widespread adoption of Bitcoin, raising the cap became the subject of intense debate in 2015. But this was not a simple change, as it would require a very invasive hard fork, which could bring risks to the net.
Without a block size limit, a rogue miner can create large blocks filled with microtransactions, forcing nodes to download, upload and store large amounts of data, leaving them unavailable to confirm legitimate transactions.
The Blocksize debate took place between August 2015 and November 2017. While one side argued that the block size would need to remain small to give end users the easy option to run a node and therefore have a more decentralized system; the other side wanted to have cheaper transactions and establish Bitcoin as a payment system through larger blocks, allowing Bitcoin to compete with payment processors such as Visa, Mastercard and Paypal.
There was near-universal consensus in the community that the 1 MB limit was too small. However, there was no consensus on what size it should be or how to change it.
However, at the heart of the Blocksize Wars were deep questions such as Bitcoin's consensus rules and the reason for Bitcoin's very existence according to Satoshi Nakamoto's Whitepaper.
THE DISPUTE WAS ESSENTIALLY ABOUT FOUR VERY INTER-RELATED ISSUES:
The block size level – Essentially, whether you really need to add excess capacity.
How to modify Bitcoin protocol rules – Whether the rules on the validity of Bitcoin blocks should change relatively easily, or should they be more robust and change only in exceptional circumstances and with broad support from all stakeholders.
The Meaning of Common User Nodes – What is the weight of common end-user validation nodes’ opinion in the application of Bitcoin protocol rules?
Time preferences – If Bitcoin was like a tech startup that should prioritize gaining marketshare among payment companies in the short term; or if it was a long-term project, new global money, and one should think decades ahead when making decisions.
THE ANSWERS TO THESE QUESTIONS DIVIDED THE BITCOIN COMMUNITY IN TWO GROUPS:
In favor of block increase: short-term prioritization, user experience, growth, business focus.
Against block augmentation: long-term prioritization, system resilience, scientific and theoretical sustainability.
As we have seen, a part of the community wanted to scale Bitcoin by increasing blocksize so that the blockchain could execute more transactions per second.
However, increasing the block size for this reason would mean that Bitcoin would have to switch from a decentralized network to a centralized network, because processing large blocks of data from millions of transactions on a decentralized network would create issues such as latency, which it would slow down the network.
The solution would be to upgrade the Bitcoin network to a more centralized infrastructure via a hard fork.
To achieve this, however, Bitcoin's consensus algorithm required the entire Bitcoin community, including miners, nodes, and users, to be persuaded of the desirability of this upgrade to a more centralized network.
However, this would compromise the essence of Bitcoin, as a form of scarce and decentralized digital money.
ARGUMENTS IN FAVOR OF INCREASE THE BLOCK SIZE:
More transactions per second;
Off-chain solutions are not yet ready to take the load off the main blockchain.
ARGUMENTS AGAINST THE INCREASE IN BLOCK SIZE:
A hard fork requires waiting for sufficient consensus;
Risk of catastrophic consensus failure;
Fast propagation of blocks is clearly not feasible as it creates centralized controls;
Larger blocks lead to larger blockchains, which make it harder for the average user to run a node, which means less decentralization.
Larger blocks lead to fewer hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin demand more trust and thus weakens Bitcoin's value proposition.
It's a protocol rule change. The robustness of existing rules is one of the most important elements of Bitcoin, if not the most.
The final solution deployed was that of Segregated Witness or SegWit, which increased the block size limit to 2-4 MB, without the need for a hard fork.
The update was intended to provide protection against transaction malleability and also to increase block capacity by separating less important data from the list of entries and retaining the information needed to determine transaction effects.
Despite some friction, the update turned out to be successful and took place on August 1, 2017, making it a big step for anyone who didn't want a hard fork to happen. Another advantage of the SegWit soft fork was that it enabled the Lightning Network.
It was a suggestion that I would increase the block size from 1MB to
8 MB and then would double every two years until 2036, bringing the block size to 8 GB.
This software update would be incompatible with existing nodes, which would mean the need for a hard fork, i.e. an extension of the existing protocol rules.
Most of the community agreed that the proposed increase in Bitcoin XT was too aggressive and that something more moderate was needed.
After Bitcoin XT was declared dead, a new proposal emerged, Bitcoin Classic, which was supported by some industry players, including Coinbase.
Bitcoin Classic was growing in popularity, but it had major weaknesses when its activation came, which was only understood by people with technical knowledge.
It was an attempt to increase Bitcoin's block size, which
had the sympathy of many miners as it would raise the overall miner fee for each block.
However, many developers were against the proposal, as they argued that the implementation would lead to small miners leaving the market, which in turn could lead to centralization by large mining corporations.
It was created on August 1, 2017 in a hard fork process of Bitcoin.
Block size is 8 MB and intended as a workaround to SegWit (Segregated Witness).
On May 22, 2017 there was a closed-door meeting in New York to propose an agreement on the sizing of the Bitcoin network.
The deal included 58 signatories, from exchange operators to miners in the Bitcoin community, and was intended to end the debate on increasing block capacity through the activation of Segregated Witness.
The Bitcoin Blocksize War at the end left an important lesson on how decentralized Bitcoin change decisions are.
It is good to remember that the purpose of Bitcoin is not to transfer money in the form of debt-based Fiat currency. Once this was understood, it meant that the true purpose of Bitcoin is to enable the debt-free transfer and storage of value outside the influence and control of a central authority.
For this reason, Blocksize Wars led to the rejection of the attempt to turn Bitcoin into a centralized payment processing system, as this would have defeated the reasons for Bitcoin's existence.
This will not be the last Bitcoin war. The next one will likely be about regulations, privacy, and censorship resistance.
However, the important thing for the future of Bitcoin is to remember that what makes it strong is precisely the fact that its rules are robust and that it only exists because it cannot be easily controlled and its rules easily changed.
