This blog is the fifth extract from our eBook, “A Short History of Bitcoin Myths”. You can download your copy here or read other extracts over here:
Part 1: A Short History of Bitcoin Myths
Part 2: The Genesis of Bitcoin
Part 3: Myth I - Crypto Anarchy
Part 5: Myth III - Bitcoin is Broken, Unable to Scale On-Chain
Part 9: The Rebirth of Bitcoin
In the early days of the Bitcoin project, the network’s evangelists promised it would make financial transactions instantaneous and cheap (to unleash unlimited creativity and applications), accessible (especially for the unbanked billions), and uncensorable (protecting your freedom of financial transaction).
By 2015, the development team who had gained hold of the reigns sang a different tune. The developers for Bitcoin Core, as Bitcoin (BTC) would become known, maintained that the Original Bitcoin protocol was broken and lacking the ability to deliver on any of these promises. Significant protocol and design changes would be needed to fix it. Or so they said.
Back in 2010 when Satoshi Nakamoto introduced the first version of the Bitcoin blockchain, there was no limit to the block size. Due to several attempted ‘abuses’ of the blockchain that occurred under a 1 MB limit Hal Finney, one of Bitcoin’s first developers proposed the implementation of a 1 MB block size limit. The intention was to prevent potential DoS attacks where someone could create huge ‘spam blocks’ to cripple the network.
Satoshi objected to a permanent cap on the block size as it would prevent scaling, but agreed to its temporary introduction until data storage capacity had reached a point where it could cope with giant blocks and simply ‘reorg’ (orphan) blocks that don’t meet the passing criteria.
Although data storage grew fast enough to allow for an increase in block size, the Bitcoin Core development community resisted lifting the block size limit, maintaining that it would introduce security risks. In the meantime, the Bitcoin network got backlogged with tens of thousands of unconfirmed transactions, causing significant delays and increased transaction fees.
Fees kept rising, reaching a peak in 2017 with transaction fees eclipsing the $10 mark to buy a cup of coffee. Nonetheless, Bitcoin Core (BTC) developers maintained that the original Bitcoin protocol does not allow for on-chain scaling. Instead, they introduced a supposed ‘software update’ called SegWit, marketing it as:
A patch for a coding vulnerability called transactional malleability and an update that would pave the way for a range of enhancements, such as the Lightning Network, to be deployed. This would mean that highly anticipated functionalities like smart contracts and micro-transactions become feasible. SegWit essentially allows Bitcoin the capacity to scale tremendously, and facilitates a faster network, ensuring transactions can be processed quicker and at a lower cost.
That’s what they said.
In July 2017, despite a longstanding and unresolved disagreement in the Bitcoin community about the proposal of adding SegWit onto the original Bitcoin protocol, the majority of miners voted in favour and subsequently implemented the changes.
For a short while, the implementation of SegWit coincided with a drop in transaction fees and a reduction in network congestion. Many sighed with relief. But it wasn’t to last long. As the Bitcoin price has started to recover from the 2017/2018 bear market and is embarking on another rise, transaction fees are following suit.
Chart by bitinfocharts.com, used with permission
Investigating the situation, Editor of the Financial Times’ Alphaville blog, Izabella Kaminska proposes the following theory:
“Looking at historical data, it's hard not to conclude bitcoin transaction fees are just as much influenced by bitcoin prices as network traffic. Which makes sense. The two influence each other. But many wallet services also offer default fee settings in terms of satoshis (i.e. the micro units of bitcoin). As the price of bitcoin rises so too does the fee, unless it's adapted to a percentage rate of the transaction price by the user, creating a self-enforcing feedback loop.
In that context, it's fair for us lay-people to ask, what did SegWit really achieve aside from buying time before transaction fees began to explode further?”
Instead of answering to criticism and questions about SegWit’s failure to improve Bitcoin’s transactional capacity, the Bitcoin Core community remain insistent that second-layer solutions, or side-chains, will resolve the issue of scaling on Bitcoin.
In March 2018, Lightning Labs gave the BTC community the second-layer solution they’ve waited for with the release of the first alpha version of its LN (Lighting Network) client for the main BTC network.
At the most basic, the Lightning Network is a network of nodes, or operators, that earn fees for transferring monetary value along payment channels that run independently from the Bitcoin blockchain. The only interaction with the blockchain occurs when a channel is initially funded or finally terminated. The idea is to route small Bitcoin transactions along this alternative route to ‘free’ the Bitcoin ledger from having to record every transaction in its immutable, transparent record.
The Lightning Network introduced a variety of technical, economic and legal problems to the Bitcoin network, but those will be tackled in a future chapter of this series on Bitcoin Myths. For today we are focussing on the belief that the Original Bitcoin Network was broken and unable to scale on-chain. So then, let’s look at the evidence.
While Bitcoin Core maintained that the Original Bitcoin protocol was broken and lacking, needing significant protocol changes to fix it, another group of developers decided to take a different fork in the road: Bitcoin Cash.
Although a 95% of Bitcoin miners agreed to the implementation of SegWit, a small group of miners, developers and users stuck to their guns, maintaining that SegWit was an unnecessary and hugely problematic addition to the Original Bitcoin protocol. To ensure the survival of the Original Bitcoin protocol, they announced a user activated hard fork (UAHF) called Bitcoin Cash and scheduled it to be implemented on 1 August 2017, pre-SegWit.
While the core network (BTC) diverged from the original Bitcoin protocol by implementing their ‘SegWit off-chain scaling solution’, the Bitcoin Cash project addressed the scaling issue by merely raising the block size limit to 2 MB, to enable faster and cheaper transactions instantly.
Image by BecauseBitcoin.com, used with permission
It didn’t take the Bitcoin Cash project long to prove that it was entirely possible to implement on-chain scaling without introducing any additional security risks. In an October 2017 experiment by a group of Bitcoin Unlimited developers and researchers from the University of British Columbia and nChain, the collaboration successfully mined a 1GB block on the Gigablock Testnet. The monumental experiment proved that a 1GB block size is entirely possible, long before the need for such colossal capacity has arisen.
“We are not going from 1MB to 1GB tomorrow. The purpose of going so high is to prove that it can be done — no 2nd layer is necessary.” - Andrew Stone, Lead Developer for Bitcoin Unlimited
When the Bitcoin SV project took over the relay in maintaining the Original Bitcoin protocol and design, on-chain scaling was made a priority. Early in 2019, Bitcoin SV mining pool, CoinGeek reported the latest successes:
At 11:35 pm UTC on March 28, a 113 MB block was mined by CoinGeek mining. That makes the biggest block sustained and mined outside of testing yet, and is another testament to the power of BSV.
Just the previous day, on March 27, BSV had seen its previous two biggest blocks mined in the wild, at 56 MB and 51 MB in size. In the time in-between these record-setting achievements, there’s also been a spree of consistently big blocks. Between 6:45 pm and 8:31 pm, the blockchain saw several big blocks mined, ranging in size from 22 MB to 57 MB. That makes for 9 blocks over 20 MB in two days time.
Not to beat a dead horse, but this continues to prove that with unlimited scaling, BSV has chosen the path that will lead to the most adoption, and the most possibilities for app developers. Any one of these big blocks would have choked another blockchain for hours with their transactions, but BSV was able to handle them quickly, efficiently, and at low cost.
Until this day, the Bitcoin Core development team frames on-chain scaling as ‘unproven’ therefore ‘risky’. Despite the tremendous technical and legal issues that threaten the Lightning Network’s survival, its advocates loudly promote LN as the scaling saviour of the Bitcoin network.
In the meantime, Bitcoin SV’s scaling tests and implementations have proven such notion a bald-faced lie: The Original Bitcoin Protocol clearly isn’t broken and doesn’t need fixing.