It’s no secret that the biggest issue in Bitcoin right now is the block size debate. The integration of BIP 101 into Bitcoin XT has reinvigorated the conversation, but there are also a variety of other proposals out there that could eventually find their way into Bitcoin Core. Every past contributor to Bitcoin Core seems to have their own, specific view on what should be done with the block size, which has made it seemingly impossible to reach consensus on this issue.
What is the Block Size Debate?
The block size debate is really a discussion on scalability. Right now, there is a 1MB limit on how many transactions can be included in a single block. When blocks start to become full, Bitcoin users are then forced to outbid each other for the right for their transactions to be included in an upcoming block. The fear is that this bidding process will make Bitcoin far too expensive as a digital payment mechanism in the near future. One of the simplest solutions here would seem to be simply increasing the block size limit, but that comes with its own issues. As the block size is raised, it also becomes more difficult and expensive to run a full node on the Bitcoin network. The lower number of nodes on the network could increase the risk of centralization in Bitcoin, which would make the peer-to-peer digital cash system much easier to attack. Essentially, the debate comes down to finding a way to help Bitcoin scale while not compromising on decentralization (security).
Some of the most well-received proposals for increasing the Bitcoin block size can be seen below. Some of these proposals are official BIPs (Bitcoin Improvement Proposal), while others are less formal.
1. BIP 100
Jeff Garzik’s BIP 100 currently enjoys roughly 60% support from the miners on the network. Instead of raising the block size limit to a fixed number, Garzik’s proposal allows miners to vote on increases and decreases to the block size on a continual basis. There is no initial increase to the block size limit once the BIP has been implemented, and a 32MB limit remains intact. In other words, miners will have the ability to move the block size limit anywhere between 1-32MB. Votes are tabulated every 2016 blocks, which is the same time interval as difficulty adjustments. Votes are limited to 20 percent higher or lower than the block size limit at the time of the vote. The method of deployment for this BIP is undecided at this point. A hard-fork is required to implement this BIP, but all future changes in the block size from miner votes would be soft-forks.
2. BIP 101 (Bitcoin XT)
BIP 101 is Gavin Andresen’s proposal for increasing the block size limit, and it is currently operational in an alternative implementation of Bitcoin, known as Bitcoin XT. Unlike BIP 100, the block size limit grows at a predictable rate with this proposal. The block size limit is initially raised to 8MB on January 11, 2016 in BIP 101. It would then double every two years for 20 years. It should be noted that changes to the block size limit over this twenty year period are linear -- the limit is not simply doubled every two years. This change requires a hard-fork, and the code only becomes active if 750 of the previous 1000 blocks are found by miners running Bitcoin software that has implemented BIP 101.
3. BIP 102
BIP 102 is another proposal from Jeff Garzik that should be viewed as a fallback measure more than anything else. The proposal simply increases the block size limit from 1MB to 2MB on November 11, 2015. The idea is that the relatively-small (compared to other proposals) increase in the block size limit will give developers time to come to consensus on a more comprehensive solution. This change requires a hard-fork.
4. Pieter Wuille’s Proposal for Following Technological Growth
One of the main concerns with increasing the block size rapidly is that not everyone has access to the hardware or bandwidth necessary to keep up with such a change. Taking this argument to the extreme -- if the block size were quickly increased at a massive rate, there could potentially be just a few nodes on the network who are processing transactions, which doesn’t look too different from PayPal.
Bitcoin Core Developer Pieter Wuille’s proposal is to simply increase the block size limit by 4.4 percent about every 97 days. This would lead to an annual block size limit increase of 17.7 percent, and the increases would not begin until January 1, 2017. According to Blockstream Co-Founder and President Adam Back, the proposal is based on public numbers made available by Cisco on an annual basis. Back discussed Wuille’s proposal on a recent episode of the a16z Podcast:
“There’s BIP 103 by Peter Wuille, which is referencing the Cisco numbers. So, one of the questions is if you want to build, you know scale, Bitcoin in line with technology advancements, the question is what is technology advancement? What is the rate of bandwidth increase? Pieter Wuille looked at the Cisco -- Cisco publishes some numbers based on retroactive information -- and so he used their annual increases to model that.”
This change would require a hard-fork. Wuille also thanked Bitcoin Core Developers Gregory Maxwell and Wladimir J. van der Laan for their suggestions in this BIP, which does not have a number at this time.
5. BIP 105
When compared to other proposals on this list, BtcDrak’s BIP 105 is most similar to Jeff Garzik’s BIP 100. There are a few differences between these two proposals, but the basic concept of allowing miners to vote on future changes block size limit is found in both. The rationale for BIP 105 is to add a cost for miners who wish to increase the block size limit. This concept is derived from past writings by Meni Rosenfeld and Gregory Maxwell. During his recent appearance on the a16z Podcast, Adam Back provided a brief summary of Greg Maxwell’s work on a supposed “flexcap,” which can be viewed as a partial inspiration for BIP 105:
“There are other proposals; there’s flexcap, which is quite interesting because it places some kind of economic constraints and allows for bursting. If there’s a sudden flurry of transactions that can’t be processed, it allows the block size to increase dynamically. How that works in a very loose outline is that miners can pay to increase the block size and do so to their profit. So if the blocks are too full and there are transactions not being processed, they can pay to increase the block size and, therefore, profit from the extra transactions they’re able to process. But at the same time it sort of deters or places an economic constraint on sort of ramping up the block size to gain an advantage in mining because miners are also sort of in a competition with each other.”
The idea is that the added cost of voting for a block size limit increase will force the mining community to collude on any attempted changes. After all, a single mining entity would not want to waste resources if they were unsure if others would join them in a vote for a change to the block size. The added cost for voting comes in the form of a mining difficulty 10% higher than the current network rate for the voter. This increased cost only applies on votes for increasing the block size limit. Votes to decrease the limit are free. Although BIP 100 allows miners to vote on a block size limit between 1-32 MB, BIP 105 currently only allows the limit to increase to a maximum of 8MB. This change also requires a hard-fork.
Image Source
6. Adam Back’s Compromise Proposal
Much like Jeff Garzik’s BIP 102, Adam Back also has his own compromise proposal that could be implemented in a pinch. He described his short-term fix during his recent a16z Podcast interview:
“A final proposal is I had proposed another kind of compromise proposal, which will be to change the time period. So, many of the other proposals stretch out for 20 or 35 years in the future, and I think it’s quite hard to predict where the technology will be in a couple of years out. The proposal I made was to increase to 2 megabytes immediately, as soon as we can roll [out] that change -- which, to be clear, any of them would take about six months to roll out. [Then], increase to 4 megabytes after two years and 8 megabytes after four years. And then reasses, so stay flat at 8 megabytes and reasses where the technology is.”
Although increasing the block size limit is not the only solution for Bitcoin’s scalability issue, it seems clear that the metric will be changed in the not-too-distant future. Many Bitcoin developers are hopeful that an increased block size limit will give other scalability proposals, such as the Lightning Network, the time they need to be implemented in full.
Editor - What do you think of the current Bitcoin block size debate? Which proposal will offer the best option for Bitcoin moving forward?
Kyle is a freelance writer who has been interested in bitcoin since 2011. His work has been featured on Business Insider, VICE Motherboard, Let's Talk Bitcoin, RT's Keiser Report, and many other media outlets. Follow the author on Twitter @kyletorpey
Or check it out in the app stores
