Depending on how connected you are to the Bitcoin world, you may or may not be aware that there has been an intense discussion regarding the current Bitcoin block size limit over the last few years. This discussion has recently grown in scale and veracity beginning a couple of months ago with Bitcoin Core Dev Gavin Andresen's appeal to the community to support his proposal for an increase to the limit.
The basics of the debate are as follows:
1) Currently a Bitcoin block is mined roughly every 10 minutes.
2) Each block is currently limited to a size of 1MB worth of data.
3) This limit is built in to the Bitcoin Core software rather than being the actual max potential capacity of the network.
4) With a 1MB block size, you can fit roughly 1500 transactions into each block, coming to a transaction rate of roughly 2.5 transactions per second.
Up until recently, blocks had never been full, and the limit was essentially treated as nonexistent by market participants. However, as adoption increases, so does the number of transactions, and as a result blocks have grown larger and larger over time. On Friday, some members of the community ran a “stress test” on the network by spamming the block chain with large amounts of small transactions resulting in roughly eight hours of full 1MB blocks and a huge backlog of unconfirmed transactions that were sitting in line waiting to be included in a block. It's worth noting that all the transactions confirmed eventually and at any time users could include an above average miner fee and be confirmed within two blocks (roughly 20 minutes). However, this is far from an ideal situation, and will be one that will occur more and more as adoption and usage of Bitcoin increases. Integral to Bitcoin's value proposition is fast and relatively cheap transactions; the 1MB block size limit will eventually lead to a Bitcoin network where neither is true.
In 2010, Bitcoin was featured on popular technology website 'Slashdot.org', bringing the fledgling network many new users and a lot of new attention. Along with the good attention, came the bad, and Bitcoin began experiencing a large number of new attacks. Satoshi and the rest of the developer community responded quickly, and instituted a number of quick changes to the Bitcoin protocol to make it more robust, one of which was the creation of the block size limit of 1MB.
“Back in 2010, after Bitcoin was mentioned on Slashdot for the first time and bitcoin prices started rising, Satoshi rolled out several quick-fix solutions to various denial-of-service attacks. One of those fixes was to drop the maximum block size from infinite to one megabyte (the practical limit before the change was 32 megabytes– the maximum size of a message in the p2p protocol). The intent has always been to raise that limit when transaction volume justified larger blocks.” -Bitcoin Core Dev Gavin Andresen
Up until that point, Bitcoin had no block size limit, and this change was meant as purely a stop-gap measure to prevent a malicious entity from creating intentionally large blocks to bring down the young network. (This type of attack is still possible today, which is why a limit of some amount is still required, but now that the network is more mature the attack is a lot less effective.) At that point in time, transaction volume was small, and 1MB was thought to be a high enough limit to both protect the network and allow room for growth until being scaled up in the future. However, to this day it has never been scaled up thanks to a developer community that is reluctant to change, usually a good trait for those in charge of financial software but in this instance it is holding Bitcoin's potential back.
Core Dev Mike Hearn posted an email he received from Satoshi on the subject of the then recently instituted block size limit back in late 2010:
“A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK.
Eventually when we have client-only implementations, the block chain size won’t matter much. Until then, while all users still have to download the entire block chain to start, it’s nice if we can keep it down to a reasonable size.” - Satoshi, 2010
First off, a change to the core Bitcoin protocol of this magnitude requires a hard fork. You can learn more about the implications of a hard fork in more detail here, but to be put simply, it's not an easy change. This specific change has been debated for over 3 years by the Core Dev team mainly due to their uneasiness about creating a hard fork, and as time goes on and the network grows larger, hard forks will become more and more difficult to successfully implement. For this reason, it is imperative that the solution chosen doesn't require another hard fork in the near future.
Originally, Core Dev Gavin Andresen proposed a solution that would only require a hard fork once, with automatic increases to block size occurring at predetermined intervals. However, that proposal received heavy push back from the other developers on the Core Dev team, and Gavin has since changed his stance to a compromise stop-gap solution. He now proposes a one-time increase of the block size to 20MB as a stopgap solution to give developers more time to come up with a permanent solution. However, this compromise has also received push back from other developers, but someseem to be in favor of a smaller increase, possibly around 8MB rather than 20MB.
It is worth noting that the limit is merely the max size a block can be, transaction volume and miner strategies will determine how large the blocks will be at any given time. Even with a block size increase, blocks won't immediately be larger than they currently are, just like blocks aren't automatically 1MB under the current protocol. Keep in mind that miners have an incentive to produce smaller blocks because they tend to propagate faster across the network, giving them a better chance of earning the mining reward. If a block doesn't propagate fast enough, another miner whose block does, will earn the reward instead. For this reason, even with a block size max limit increase, miners will most likely impose their own limits on block size based on their own chosen level of risk vs reward.
We feel that a block size increase of some size will be necessary within the next year for Bitcoin to scale properly as adoption increases. We are watching the debate closely to determine exactly what that block size increase should look like, whether a built in scaling model or a more conservative fixed block size increase to 8MB. We will update you as more tests are run and we learn more, but right now we are leaning towards a model that supports dynamic scaling so that the block size can grow in the future without the need for more hard forks. That being said, it is definitely a much simpler upgrade to move forward with a fixed increase. Last but not least, there is no need to worry too much over the impact of a potential hard fork, as they are Bitcoin's way of using the free market to roll out upgrades. The fact that the community is taking part in such intense debate is a vital aspect of any successful open source project and one way or another, a choice will be made by everyone participating in the network.
A Scalability Roadmap
Looking before the Scaling Up Leap
Twenty Megabytes testing results
Time to roll out bigger blocks Why increasing the max block size is urgent
It must be done… but is not a panacea
Block size and miner fees… again |
Will a 20MB max increase centralization?
Big blocks and Tor
The myth of “not full” blocks
Are bigger blocks better for bigger miners?
Bigger blocks another way?
For a Block Size Increase:
Coinbase CEO Brian Armstrong https://twitter.com/coinbase/status/595741967759335426 https://twitter.com/brian_armstrong/status/595453245884997634
Blockchain.info Co-founder Nic Cary CEO Peter Smith https://twitter.com/niccary/status/595707211994763264 https://twitter.com/OneMorePeter/status/595676380320407553
BitPay CEO Stephen Pair
Xapo CEO Wences Casares
Third Key Solutions CTO Andreas Antonopoulos https://twitter.com/aantonop/status/595601619581964289
Armory CEO Alan Reiner
Bittiraha.fi CEO Henry Brade
Kryptoradio creator Joel Lehtonen
Jameson Lopp, BitGo engineer
Breadwallet CEO Aaron Voisine
BTC Guild founder, Eleuthria https://www.reddit.com/r/Bitcoin/comments/370rko/21incengineereveryoneassumeshumanswill_be/crjfnpg
Against a Block Size Increase:
Bitrated founder Nadav Ivgi https://twitter.com/shesek/status/605005384026177537
David Francois, CTO of Paymium http://fr.anco.is/2015/gavineries/