“What is the right maximum blocksize?”
This question is impossible to answer. There is no “right” blocksize, and everyone will have to lobby for their vision of the network.
However, in order to actually persuade anyone of your position, you need to enumerate your end goals and take a critical look at what this will mean for the decentralized nature of the network. This post delves into why this is such a tough problem, and why naive scaling is not a silver bullet even under optimistic conditions. Scaling Bitcoin in this way is a game of getting things “just right”: not too cold, and not too hot.
Bitcoin Today (Too cold!)
There is no argument that the 1MB block size was arbitrarily chosen and painfully small. Originally this was instituted to prevent DoS attacks against the network. The roughly 3.5 transactions per second this allows means that we have a total capacity of 110 million transactions per year, with a blockchain growth cap of 52.56GB a year.
This means that if we only count on-chain transactions as “Bitcoin”, 1.6% of people on planet earth could make a single transaction a year. If we stick to a Lightning Network-style payment channel setup, this means that 0.8% of humanity could get hub-and-spoke payment channels each year in today’s blocks. Even this relegates the Bitcoin network as a settlement network for banks and large financial players.
On the other hand, running a full node today is utterly trivial with a modern computer and internet connection, and SPV nodes appear to be well provisioned on less than 6,500 listening full nodes. Anyone who chooses to do so can run a full node and enjoy the full security of the network. As computing technology advances, it is quite likely that a 1MB cap could be trivially run on a budget smartphone. If you are an interested banker at least.
C’mon, Just Scale It! (Too hot!)
To most, 1MB forever is too small to really hit any sort of network effect they desire. If we want to improve this, why don’t we just increase the blocksize and scale it up until we really make an impact?
Let’s say we just want all people on planet earth to be able to make two transactions a year on-chain. That would require roughly 126MB blocks, with a theoretical maximum blockchain growth of 6.7TB a year. Scaling it even further, it gets apparent that running a full node will become a serious affair. If we want all humans to be able to make two transactions a day on-chain for paying bills, groceries, and coffee, we come to the massive blocksize of nearly 46GB. Running a full archive node will take 2.4PB of storage per year.
Even if we trimmed the low-hanging fruit to improve node performance and stuck with the first scaling scenario, no longer would running a node be a trivial exercise, but one that would take a serious amount of effort and resources maintain. There is clearly a trade-off on ability to interact directly with the blockchain via transactions and the ability to participate in the validation of the network itself. Most importantly, growing the block size too fast could result in catastrophic centralization of the network, resulting in a few stakeholders counterfeiting and controlling policy at will.
Network Health Today
Bitcoin the network is not as decentralized as we would like.
More worryingly, Bitcoin businesses that need wallet services are being publicly encouraged by unauthenticated blockchain indexing services to not run a full node. If we can’t even convince organizations that need the security protection the most to run full nodes when the blockchain is quite small, this casts doubt on the viability of expansive changes to the protocol.
The mining industry seems equally as dire. A vast majority of pooled miners hand over their entire hashing “vote” to the control of the pool itself, or simply throw their bits to cloud mining operators who are more likely than not some form of Ponzi.
Changing these behaviors will mostly require education and time rather than with the blocksize cap, but it’s important to note that it is not very conservative to stress the network’s security assumptions when all other measurements are pointing to centralization issues.
Stakeholders and Blocksize Caps
Much of the urgency in this debate seems to be over the natural state of the network in the long-term. There appear to be 3 factions, with slight overlap in membership between adjacent groups.
Catastrophic Coalition: This group contends that once max block size is hit consistently, it will essentially be viewed as a Denial of Service attack, blocking out cheap transactions, making transactions time out of the network’s collective mempool, and inherently damage Bitcoin’s reputation. The public will point and laugh at the puny 3.5 transactions per second rate, and people will either flock to altcoins who have not hit such a cap, or simply traditional payment systems. Bitcoin will have permanently missed the opportunity to replace VISA. This event is to be avoided at all costs.
Experimenters: This group is really quite curious what is going to happen when the 1MB blocksize cap is hit. They view Bitcoin as an experiment, and are partial to the idea that “hitting the max block size will have to happen eventually, so why not now?” Many of these are also interested in finding out how many business models and security assumptions were being made in the absence of block inclusion competition. Often these folks are looking forward to some type of replace-by-fee to be rolled out to create a real functioning fee market in contrast to today’s relatively ham-fisted software that just fails if you shoot too low in fee. Hitting the block limit would spur development of such software.
Scarce Resourcists: This group believes that Bitcoin, in it’s natural state, will be up against the block size limit. They argue a limit will be necessary to both fund the network security by auctioning a scarce resource(paper), and will be a consequence of the desire to keep the network decentralized. They believe that simply “scaling up” is a dangerous exercise, and in their heart of hearts an ultimately futile attempt to displace traditional payment systems. Instead development should be focused on tackling problems that they believe Bitcoin can actually solve using solutions such as payment channels and off-chain crypto-audited banks.
After looking at these groups, we can now see why pre-emptively forking for the future is probably not going to gain consensus any time soon. This pragmatic and ideological divide is not going to be gapped by an excited blog post, but through time, experimentation, experience, politicking, and a dash of humility. Proposing block increases based off of future technological advancement are dead on arrival; increases, if and when they happen, will be reactionary events. Failure to take the time to gain consensus before making bold, imminent-sounding pronouncements will only further delay changes that are deemed necessary by the factions.
The blockchain, much like democracy, is a MAD-style suicide pact; a never-ending game of chicken. Each user that derives some utility from the current network wants the thing they like amplified even if that is to the detriment of some other users. Each user can vote for their opinion in various ways, with a permanent blockchain forking being most likely the wrong solution.
With this in mind, we can look for common ground while looking forward. Building layers on top of Bitcoin such as hub-and-spoke payment channels, and audit-able crypto-banks can be started today to relieve a lot of this pressure. Some type of replace-by-fee has to be developed to make fee adjustments easier and safer than now. These enhancements will be required at whatever blocksize is deemed safe in the future. Perhaps someday we can scale Bitcoin enough that everyone can have at least some access to the blockchain through naive scaling or newer ideas such as treechains. Until then we should focus on what is probable and safe today, and less on guesses about tomorrow’s technical advances.
Gregory Sanders, Bitcoin enthusiast – email@example.com
Previous Post: http://blog.greenaddress.it/2014/06/13/sidechains-treechains-the-tldr/