Big Blocks vs Small Blocks, On-Chain vs Off-Chain scaling, Bitcoin as digital cash vs Bitcoin as a store of value. These are only some of the opposing ideologies in the raging debate on the direction Bitcoin should take to scale, accommodate new users and achieve world dominance as a currency and medium of exchange. When the anonymous creator of Bitcoin, working under the alias Satoshi Nakamoto unveiled his creation to the world, the road ahead appeared simple, both from a governance and a technical standpoint.
In the original version of the Bitcoin protocol there was no hardcoded blocksize limit and with good reason: the network was still in its infancy and usage was orders of magnitudes lower than it is today; the blocks produced were tiny and transactions were few and far between(averaging at about 400 daily).
The forging of the One Ring
That changed on July 15th, 2010 when Satoshi introduced the Max_Block_Size “feature” artificially capping the maximum blocksize at 1 MB. It also included a patch to prevent a malicious actor from effectively stalling the network; one could produce exceptionally large blocks filled with junk transactions that couldn’t be propagated and validated in time by other nodes participating in securing it.
This is where the One True Ring was forged in the fiery abyss of Mount Doom, and 8 years later we are still carrying its burden. But Satoshi had a clear goal in mind with the introduction of the 1 MB blocksize. It was to mitigate a potential security vulnerability at a time where the network was not yet prepared for larger blocks.
In a series of email correspondence with notable bitcoin early adopter and developer Mike Hearn, Satoshi stated his reasoning for why the cap was needed in very simple terms and, here comes the important(and controversial) part, how to get rid of it in the future:
“A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK.
Eventually when we have client-only implementations, the block chain size won’t matter much. Until then, while all users still have to download the entire block chain to start, it’s nice if we can keep it down to a reasonable size.
With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
Whatever the current capacity of the software is, it automatically grows at the rate of Moore’s Law, about 60% per year.”
From this and other interactions Satoshi had with community in the early days of the projects it’s clear that he envisioned for Bitcoin to scale on-chain and to benefit from the increase in computing power postulated by Moore’s Law. He didn’t see it as a contentious point nor did he expect the massive amount of community infighting this simple security mechanism/placeholder code snippet would bring.
And yet the limit was never removed, on-chain scaling never happened.
As Satoshi stepped back from the limelight and slowly faded away in the mists of myth the one true ring remained dormant. It awakened when increased adoption of the Bitcoin protocol started to lead to rising fees and reduced usability.
BlockStream, a nebulous entity comprising the vast majority of the Bitcoin Core developers expressed the position that on-chain scaling was detrimental to the security and inclusiveness of the network. They argued that by constantly raising the block size we would eventually reach a point where most people would not be able to run a full node to validate blocks. The network would become centralized, with few nodes needing massive computing and bandwidth resources being run by a few corporate entities, therefore destroying the decentralization tenet on which Bitcoin is founded.
As the scaling debate raged on, various solutions and compromises where proposed with various factions arguing over the supremacy of their technical and ideological positions. In the end the rift grew too wide. After the introduction of the SegWit signature scheme championed by Blockstream and advertised as solution to the Transaction Malleability issue (and a first step in scaling the network) appeared to be close to activation, a group of big blockers set out to fork the bitcoin chain and create Bitcoin Cash.
Bitcoin Cash came to be on 1 August 2017 thanks to a hard fork spearheaded by various independent development teams and a ragtag cadre of miners and merchants operating in the Bitcoin space. This was an attempt to wrestle back control of Bitcoin’s future from the Core dev team by immediately increasing the block size limit form 1 MB to 8 MB. It was met with furor from the small blockers camp as they felt it appropriated and misused the Bitcoin name.
Fortunately some mining entities supported the project in this critical early phase, allowing the chain to progress and onboard merchants eager to take advantage of the small transactions fees made possible by the newly added capacity and the removal of the RBF scheme. The deletion of the contentious RBF code proved to be extremely popular with merchants who wanted to improve user experience by allowing payments with 0 confirmations to be considered valid due to the reduced risk of double spending.
Thanks to this exciting developments, namely the reduced fees and quick confirmations you could finally buy a coffee again with Bitcoin.
Bitcoin Cash, embracing innovation
The Bitcoin Cash developers have made it clear they don’t fear innovation with rapid and significant protocol changes to improve scalability, user experience and extend the feature set offered by BCH. Thanks to multiple development teams working in unison or tackling different challenges, Bitcoin Cash has a solution to the TX Malleability problem that is completely independent of SegWit, does not require an extensive refactoring of the codebase and doesn’t affect critical parts of the protocol. It’s called FlexTrans and it will come fairly soon, as a part of a future hard fork.
Another very promising advancement to tackle the scalability problems comes in the form of Graphene, a joint effort between researchers at UMass Amherst and Gavin Andresen. Graphene is an alternative method to propagate blocks inside the Bitcoin P2P network, allowing for a compression ratio greater than other competing protocols and speeding up significantly the time it takes for new blocks do be distributed and made available to all the peers in the network.
This new proposed specification could work in synergy with a higher block size, allowing greater on chain throughput without sacrificing decentralization, increasing hardware requirements for nodes and introducing higher latency. Another differentiating factor between Bitcoin Cash and Bitcoin is that the former is not afraid to conduct regular, planned hard forks to introduce new features and fix longstanding issues, adhering to a much more aggressive schedule.
The next planned hard fork for Bitcoin Cash will be on May 15th 2018 and it will represent another step in the quest for scaling. The most significant change that will be introduced is an increase of the maximum block size from the 8 Mb blocks we have today to a much higher 32Mb limit, a 4x increase!
That’s not all, however, as the May hard fork will also see the reintroduction of some Opcodes disabled during the Opcode Wars alongside some new ones. These changes will make it possible for several interesting functionalities such as such as timestamping, representative tokens, and more complex transaction scripting to take place natively on BCH.
Eventually Bitcoin Cash could acquire capabilities similar (albeit more primitive and not as full featured) to Ethereum and branch out to fill more advanced use cases other than being a single purpose cryptocurrency used as an exchange mechanism.
Only time will tell if on-chain scaling is viable but at least now the bitcoin community has Bitcoin Cash to experiment with and we all stand to benefit from a renewed push to introduce cutting edge technologies in the blockchain space and expand on Satoshi’s vision while adhering to the core principles that define Bitcoin.