Bitcoin has a challenge: how do you get diverse groups of miners, users and developers to agree on the right way to solve a complex technical and economic challenge?
So far the answer has yet to be found, however there has been no shortage of proposals and debate about how to address the issue of scaling Bitcoin. The core challenge is fairly simple. Bitcoin has a block size limit of 1mb, which equates to a theoretical limit of about 7 transactions per second, though that number is less in real-world scenarios. As Bitcoin adoption has grown, so have the number of transactions (both legitimate and spam) and the importance of addressing the block size, both now and in the future. This challenge has become the primary topic of focus for the community with a number of notable members putting forth bitcoin improvement proposals or BIPs. In this article we look at the most notable and discussed of the current batch of proposals.
This proposal was put forth by the Bitcoin core developer Jeff Garzik. This proposal would be a hard fork (requiring users to update in order to participate in the network) triggered when 90% of the network has adopted the update, and is targeted for January 2016. BIP 100 approaches the issue of scaling by introducing a floating value that can be updated by miner votes every 12,000 blocks (roughly 3 months). The way this work is that miners all sign blocks with a specific string registering their vote and at the time of evaluation the top 20% and bottom 20% are discarded while the resulting most common floor is used. This new value cannot be more than twice the current block size, not less than half the current block size, and cannot exceed a hard cap of 32mb.
- Miner vote-based system
- New blocksize chosen every 3 months
- Increase limited to a doubling of size (32mb hard cap)
- Decrease limited to halving of size
BIP 100 has seen its share of debate due to the power that it gives miners. A move to a BIP 100 vote-based system would give the miners even more power than they already have and has lead to speculation around ways in which miners could game the voting system. In additional to potential concerns around collusion, vote-buying and lobbying of miners to modify the block size, there’s also the concern that miners will vote for a block size that benefits them (e.g. votes for larger blocks by miners with the best network connections). There have also been concerns about a so-called “21%” attack, which refers to the fact that with 21% of the mining power, an entity could cycle the size of the network down in an attempt to disrupt or destroy it. The debate is far from over and various elements of this proposal, including the challenges presented by a voting system, are still actively under discussion by the community.
The BIP 100 proposal can be found here.
This proposal was put forth by Gavin Andersen, another Bitcoin core developer. This proposal would also be a hard fork targeted for roughly the same period in January. However unlike BIP 100 this proposal has a simpler mechanism where the block size gradually increases though a doubling process that takes place every two years for 20 years. Additionally this proposal includes an immediate increase of the blocksize to 8mb.
- Immediate update to 8mb
- Doubles every two years for 20 years
BIP 101 has its own challengers, mostly in the form of concerns about the rate and size of the increases. Bitcoin has suffered from the issues of deceasing numbers of full nodes, and there are concerns that such a large increase, followed by a series of doubling events, could further reduce the number of participants in the network willing to run a full node. As we’ve recently covered there’s also a fair bit of resistance from Chinese miners to BIP 101 due to the latency challenge created by the Great Firewall. These concerns are compounded by the fact that it’s hard to predict exactly what kind of bandwidth, storage and computational resources will be standard or widely available to users and miners two, four, or twenty years from now. Moreover, committing to such large blocks could cause problems if network requirements outpace available technology.
The BIP 101 proposal can be found here.