Blockchain technology is a brand new technology whose first application is Bitcoin. Like all software, it is not perfect. Bitcoin has proven to be resilient in terms of security and as a store of value, but one major roadblock that we are running into is scalability.

As you may know, Bitcoin currently has a 1MB block size limit. A block is found on average every 10 minutes meaning that as a network Bitcoin is only able to process 1MB of transaction data every 10 minutes. Doing the math yields a limit of 7 transactions per second. That may sound like a lot, but compared to the giant credit card VISA which processed on average 2,000 transactions per second puts the limit in perspective. There are several proposals to increase the blocksize, some want a temporary 1MB blocksize increase in order to solve the temporary scalability problem, another proposal aims for a gradual blocksize increase starting from 8MB and doubling every 2 years for 20 years, last but not least another similar proposal exists which also gradually raises the blocksize limit but which allows miners to vote on future blocksizes.

Bitcoin core developer Jeff Garzik has proposed an increase to bitcoin’s block size limit to 2MB [BIP 102]. The proposal is intended to buy more time to reach a consensus on a more durable solution before the maximum amount of transactions per second on the Bitcoin network is reached. We saw first hand what happens when the amount of transactions exceed the size of the block – it caused a massive delay in confirmations. While an easy solution is to increase fees, many bitcoin services still use a 100 satoshi fee which is vulnerable to a dust transaction spam attack. Thus, if we raise the blocksize by 100% from 1mb to 2mb, the amount of work an attacker needs to perform in order to create a backlog of spam transactions doubles.

Garzik wrote:

“This [BIP 102] is an alternative to BIP 100, as a fallback if other consensus is not reached. It allows for limited experimentation to explore a size increase without going overboard. But it’s not flexible, probably requires another hard fork, and still is an arbitrary [economic] policy not informed by the market, so inferior to BIP 100. However, having a minimum-agreed backup plan is better than no plan at all.”

The major downside to BIP102 and other proposals to the blocksize debate is that a hard fork is needed in order to deploy any blocksize changes. A hard fork should be avoided at all costs as Bitcoin is still in the mass adoption stage and a hard fork will create confusion and chaos in the community, ultimately weakening bitcoin itself. However, in this case we might need a hard fork regardless and now would be a better time to do that than later.

Raising the block-size limit has been a controversial issue for several years. Satoshi Nakamoto originally intended it to be a temporary measure in 2011 to prevent spam, but several developers and other prominent Bitcoiners now believe a limit on the block size may actually be much needed. They believe such a limit safeguards the decentralized nature of Bitcoin and provides a long-term incentive for miners to secure the network.

Competing BIPs

It seems that the current competing blocksize increase proposals are Jeff Garzik’s BIP 100 and Gavin Andresen’s BIP-101. Both BIP 100 and BIP 101 are similar in the sense that both offer a gradual blocksize increase. The main difference is the frequency of the blocksize increase interval and the fact that Jeff Garzik’s proposal allows for miners to vote for future blocksizes.

BIP-100

Jeff Garzik proposes to remove the 1MB limit and let miners decide on future blocksizes. The fork would occur on January 2016 followed by blocksize upgrades every 3 months. Because the voting system might be easily rigged if large pools decide to play dirty the consensus must reach 90% instead of the usual 51% majority. Here is a short summary of the proposal:

1. Hard fork, to
2. Remove static 1MB block size limit.
3. *Simultaneously*, add a new floating block size limit, set to 1MB.
4. The historical 32MB limit remains.
5. Schedule the hard fork on testnet for September 1, 2015.
6. Schedule the hard fork on bitcoin main chain for January 11, 2016.
7. Changing the 1MB limit is accomplished in a manner similar to BIP 34, a one­way lock­in upgrade with a 12,000 block (3 month) threshold by 90% of the blocks.
8. Limit increase or decrease may not exceed 2x in any one step.
9. Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig, e.g. “/BV8000000/” to vote for 8M. Votes are evaluated by dropping bottom 20% and top 20%, and then the most common floor (minimum) is chosen.

BIP-101

Gavin Andresen proposes to increase the blocksize limit to 8MB starting January of 2016 and gradually increase it over time in intervals of 2 years, doubling each time.. Just to be clear, once the 8Mb limit goes into effect the doubling of the size every 2 years will NOT cause a hard fork because the rules are going to be put into the network in the first hard fork.

Here are the proposed parameters:

Unit test and code for a bigger-block hard fork.
Parameters are:
  8MB cap
  ... doubling every two years (so 16MB in 2018)
  ... for twenty years
  ... earliest possible chain fork: 11 Jan 2016
  ... after miner supermajority (code in the next patch)
  ... and grace period once miner supermajority achieved (code in next patch)

Which solution do you find more appealing? Vote in the poll below!

[poll id=”2″]

If you liked this article follow us on twitter @themerklenews and make sure to subscribe to our newsletter to receive the latest updates from bitcoinland and market analysis to help you make the most out of your trades!