Up until that point, the daily volume of bitcoin transactions had increased 2.5 times leading to capacity issues on approximately 3% of transactions. An additional complication is the fact that bitcoin miners are not obliged to fill blocks to their maximum. They are able to set custom block size limits below the 1 MB threshold.
In the short term, transactional congestion along these lines is far from ideal. Bitcoin is touted partly for its reliably low transaction times. As such, the rate of Bitcoin adoption may be inhibited in proportion to the extent of the network’s congestion.
In the long term, transactional capacity is even more of an issue, insofar as Bitcoin is often imagined in the future as a ubiquitous global payment network such as VISA.
VISA handles on average around 2,000 transactions per second (tps). It has a peak capacity of around 56,000 tps. However, they never actually use more than about a third of this, even during peak shopping periods.
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps.
Today, the Bitcoin network is restricted to a sustained rate of 7 tps as per the 1 MB block size. Considering the imminent wave of machine-to-machine transactions that Bitcoin has newly enabled, the ideal number of transactions per second bitcoin would need to be able to accommodate is perhaps two or three orders of magnitude greater than VISA’s 56,000 tps.
To accomplish many of Bitcoin’s major applications and longer-term visions, it will need to be able to scale far beyond its current state.
In Search of a Solution
Simply increasing the block size from 1 MB seems like easiest solution to implement, as it seemingly only requires changing a single value in the code. In actuality, this could result in unintended ramifications and require other changes of the codebase that may carry unintended ramifications themselves.
A seemingly simple increase like this would result in increasing the power required to run full nodes, which increases the cost of their upkeep. Recall that full nodes are primarily responsible for relaying and validating bitcoin transactions and blocks. As such, they are the bedrock of the network. The more people who use full nodes to process payments, the greater the Bitcoin network is decentralized — decentralization being the technology’s most valuable feature, enabling many of its benefits (censorship resistance, fungibility, trustlessness, etc.).
Increasing the cost of full node upkeep means less individuals can afford to host them. Less individual participation means greater concentration of network nodes, resulting in increases of systemic centralization risks. Basically, Bitcoin starts to look more and more like a traditional, centralized shared database, carrying more and more of the same risks of centralized databases while losing many, if not all, of the benefits of a distributed ledger.
To mitigate Bitcoin systemic risk, Bitcoin’s development policy is that any proposed changes require a “convincing, broad consensus” to be implemented (specific criteria varies based on the particular changes). This standard is purposefully vague at face to encourage the greatest amount of diligence in arriving to a consensus-backed solution. The issue of Bitcoin’s scalability is of sufficient controversy that the protocol’s developers are entertaining this greater amount of diligence before moving forward.
Although Bitcoin’s scalability has been discussed by the developers throughout the technology’s lifetime, only within the past year has the issue gained prominence and spurred controversy.
In short, several initial blog posts and articles bringing the scalability issue forefront generated some fear, uncertainty, and doubt about the adoption rate/future of Bitcoin. These, by and large, exaggerated the trend of an increasing number of transactions filling up blocks (a consequence of Bitcoin’s hard earned success).
Inappropriately, developers of the XT scalability proposal banked on this uncertainty about Bitcoin’s scalability to garner support for changes they and a minority of others wanted to see made to Bitcoin, while other major Bitcoin developers maintained that the only true scalability solutions which preserve Bitcoin’s decentralized nature were still a ways out. Namely these solutions include the “Lightning Network” proposal and other ‘off-chain’ scalability solutions. These best preserve the critical properties of bitcoin (fungibility, trustlessness, etc.).
The mental need to relieve uncertainty and insecurity, in addition to the promotion of the XT proposal, resulted in some significant XT adoption and unwarranted animosity towards some developers.
Proposals: Core, Classic, XT, and Others
The controversy over Bitcoin’s scalability has resulted in several sects forming over particular proposals. Each individual sect includes a diversity of ecosystem participants, including: developers maintaining Bitcoin’s code, miners, merchants, businesses building on top of Blockchain, casual users, and other interested parties.
Only three proposals have gained any significant traction, but following XT developer Mike Hearn’s exit from the Bitcoin project, now only two major scalability proposals remain viable: Bitcoin Core and Bitcoin Classic.
Bitcoin Core proponents seek to minimize systemic risk to Bitcoin, even if this means Bitcoin businesses must work to tweak the way they interact with Bitcoin, potentially inhibiting the rate of Bitcoin adoption.
However, lower-/no-risk scalability solutions, such as Segregated Witness (a proposal that shrinks the average size of transactions, thus creating more space transactions), continue to be developed and deployed. Their approach to Bitcoin development also puts preserving the protocol’s decentralized nature and censorship resistance before all else. Part of this decentralization preservation entails maintaining the highest level of backwards compatibility for Bitcoin software — which hard forking (a change to the system which is not backwards compatible; everyone needs to upgrade or things can go wrong) changes inherently prohibit. Backwards compatible software maximizes the number of full nodes able to participate in the network, preserving/maximizing decentralization of the network.
Read more about Bitcoin Core’s development philosophy and scalability roadmap here: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/.
Other Scalability Proposals
Most, if not all, of the alternative scalability proposals relative to Core (including the now infamous Bitcoin XT) require some sort of hard fork for implementation. A hard fork is a change to the system which is not backwards compatible, effectively splitting the blockchain into at least two incompatible blockchains, which may or may not reconvene into a single blockchain at a future point.
In the case of one alternative scalability proposal, Bitcoin Classic: in theory, implementing an immediate 2MB change would immediately alleviate block congestion but would require a hard fork. Hard forking carries with it certain systemic risks:
- Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double-spend risk.
- Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.
In essence, if a hard fork goes bad, it will likely cause large-scale confusion and make Bitcoin incredibly difficult to use until the situation is resolved. There’s also a very real chance of total system failure if a hard fork’s deployment is not well-coordinated across the entire network.
For the past year, discussion and research about the risk-reward of hard forking the network in its current state has taken place. The technical consensus is that hard forks as prescribed by alternative scalability proposals should only be considered if absolutely necessary. This same consensus of Bitcoin developers has determined that this absolute necessity is not the case now. Yet, human short-sightedness and drives to resolve uncertainty continue to fuel support of the quick fixes which may put the long-term future of the project at major and truly needless risk.
Mike Hearn & “The Resolution of the Bitcoin Project”
Mike Hearn was a long-time Bitcoin developer and one of the chief developers of the XT scalability proposal. Ultimately, his proposal did not gain enough traction in the ecosystem — in fact, before his “Bitcoin is a failure” media campaign, it was facing greater dissent. Frustrated, he then launch the media campaign.
In his Medium post, Mike has some valid points of concern on the need for a scalability solution, but general ecosystem consensus never disputed a need to scale. The denial-of-service attacks that afflicted nodes running the XT solution were no more than an unfortunate coincidence. We think Mike over-exaggerates his statements about Blockstream and the Scaling Bitcoin initiatives.
Most of all, his assertion that “Bitcoin has failed” is incorrect. There is only a need for scalability because of rapid transaction growth and other non-financial use cases of blockchain emerging — a nice problem to have. As evidence of Bitcoin’s continuing success, emergent companies building privatized blockchains (“bankchains”) have begun poaching developer talent from the Bitcoin project — Mike, himself, is an example.
Metrics of the ecosystem tell us one thing and one thing only — Bitcoin is thriving: