Jeff Garzik Proposes New BIP100 Solution To Bitcoin Block Size Debate

Bitcoin core developer Jeff Garzik has recently proposed a consensus based solution to the bitcoin block size debate and the proposal is drawing attention from some heavy hitters in the bitcoin ecosystem.

The block size debate began back in October 2014 when Gavin Andresen announced a proposal through the Bitcoin Foundation blog entitled “A Scalability Roadmap”. Since then ex-google developer Mike Hearn partnered up with Gavin and both have pushed for a significant increase in block size from 1mb to 20mb and failure to do so would be catastrophic if this increase was not implemented immediately and that this change would take place with or without the consensus of the bitcoin community, this approach was seen by the community as an act of totalitarianism which turned the debate into more of a civil war of sorts with both sides of the issue slinging mud…

Bitcoin XT has offered to reduce the initial increase from 20mb to 8mb with an annual gradual increase however it seems the community is not buying into the protocol with accusations that the XT version contains back doors to allow for 3rd party interference an on and on…

Enter Jeff Garzik and the BIP100 solution who argues that an increase is definitely needed but should be increased through a framework where the network increases block size by consensus which would be a lower risk technically and politically than a hard fork. Block sizes exceeding 1mb may be selected without flag day network upgrade. Small size increments limit the potential for unexpected harm to bitcoin network security and allow the network time for testing, preparing and adjusting to overall behavior. More complex solutions such as extension blocks are rejected in favor of a one time simple change that will greatly reduce the need  for future hard forks in this area.

Protocol changes proposed:

  • Hard fork, to
  • Remove static 1MB block size limit.
  • Simultaneously, add a new floating block size limit, set to 1MB.
  • The historical 32MB limit remains.
  • Schedule the hard fork on testnet for September 1, 2015.
  • Schedule the hard fork on bitcoin main chain for January 11, 2016.
  • 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.
  • Limit increase or decrease may not exceed 2x in any one step.
  • 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.

BIP100 accomplishes several goals:

  • Demonstrates that change is possible and that the Bitcoin protocol can be upgraded
  • Eliminates 1MB limit as impediment to adoption
  • Removes hard fork risks
  • A “Keep It Simple Stupid” solution in terms of code changes
  • An upgraded path yet restrained until problems and solutions are better understood

This approach introduces friction into the block size increase process making it scalable but giving participants in the system sufficient time to observe system behavior and change course moving to a system where the market decides block size optimization.

Some of the more notable names that have taken a stand for BIP100 include F2Pool, AntPool, BitFury, BTCChina, BW Pool, Eligius, KnCMiner, Slush, 21Inc, Telco 214 and to name a few.

This debate has now been out of control for the past 6+ months and has seen it’s share of in-fighting between core developers but it is way too ridiculous at this point and something has to click in order for bitcoin to survive… The bitcoin community has been divided and is primed to be conquered if a solution is not found, a solution for the good of all not just the few! BIP100 seems to be the solution that may achieve this goal.

For more information and to educate yourself on BIP100 visit:


Subscribe to our newsletter

Jeff Garzik, known for significant code contributions to the Bitcoin reference client (Bitcoin QT / Core) and his Bitsat project, which aims to put Bitcoin nodes into orbit, recently submitted Bitcoin Improvement Proposal (BIP) 102 to address the blockchain debate over block size.

Jeff Garzik image
Jeff Garzik

As you probably know, Bitcoin transactions broadcast over the network are compiled by miners into a distinct block about every 10 minutes. In Satoshi’s original implementation, the number of transactions per block was unlimited but this was later patched to a 1 megabyte ceiling to prevent spam attacks. BIP 102 seeks to double this limit to 2 megabytes, effective on the 11th of November, 2015.

Why the Debate

While it may sound like a “miner” change, this would necessitate a hardfork of the Bitcoin network. Old and new versions of Bitcoin software will therefore become incompatible, meaning that without consensus on the switch, the Bitcoin network may become divided with potentially destructive consequences.

Proponents of the change insist that the benefit outweighs the risk as, without such a block size boost, Bitcoin will be unable to scale to incorporate an influx of new users and/or certain blockchain-dependent services. Advocates of the status quo argue that the current limit promotes decentralisation and stimulates the emergence of a market for transaction fees; transactions which don’t pay a sufficient fee to miners will take longer to process or fail altogether.

Jeff Garzik’s previous proposal to address this contentious issue, BIP 100, seeks to implement a shifting limit determined by miners, who would vote on the limit every 3 months. As it allows for market feedback, this option is likely preferable to any arbitrary size increase and, at least until the historical cap of 32 MB is reached, should prevent this divisive issue from arising again in the near future.


Gavin Andresen, Mike Hearn and others have also put forward suggestions but as of yet none has reached a clear consensus among developers, miners, businesses or the community. Garzik’s BIP 102 is thus a stopgap measure, aimed at keeping blocks from becoming full without making too radical a change, until a permanent solution meets with more unanimamous support. Despite being a relatively modest proposal, BIP 102 has not met with anything like universal support, not least because it implies enduring two hard forks rather than one.