The purpose of the hard transaction limit

[Steve Sokolowski]

As I stated in Forbes last week, I plan to soon request a pull into litecoin to implement the BIP101/4 solution that we proposed last month. The purpose of this post is to explain why I believe that this modified version of BIP101 is the correct one, and why the other proposals for resolving the blocksize problem in any coin do not solve the issue at hand.

Nakamoto himself said that the purpose of the "hard" 1MB blocksize limit limit was to prevent denial of service attacks. Denial-of-service attacks, in theory, can be solved simply by increasing the amount of bandwidth available to the victim. The attacks are only effective because technology has limited the amount of bandwidth a normal user can purchase. As technology improves, price of bandwidth declines and now the same cost can be used to defend against attacks of a larger size. There are other resources like CPU power that play a role in these attacks, but the result is similar - as time goes on, it is possible to defend against larger and larger attacks for the same price.

There is another, different, soft limit - the number of transactions that are actually included in blocks. This second limit is determined mostly by how much demand there is, which in turn dictates what the fees are. It is also affected by what the actual network conditions are for a single miner, and so on. Until recently, bitcoin never reached the hard blocksize limit because miners limited the size of their blocks because usage wasn't high enough. Litecoin has yet to reach the hard limit but some miners still limit the size of their blocks for various reasons, like reducing their orphan rates.

In all the chaos in bitcoin, many commentators appear to confuse the two limits. The "hard limit" that is currently set to 1MB was designed to be limited by technology, and should be the maximum number of transactions that a reasonable computer can process at any time. The "soft limit" that, for litecoin, is below 1MB, is limited by usage. This soft limit is the number of transactions that have a reasonable fee and which miners can make money on by including them in blocks. As technology improves, the hard limit should increase. As usage increases, the soft limit increases as transactions become more profitable to include. Because the network can never exceed the constraints of current technology, the soft limit can't ever surpass some high limit, even if the defined hard limit were set higher than its natural value.

With this understanding, a few conclusions can be drawn. First, in an ideal world the soft limit should remain far below the hard limit. When I purchase a computer, I don't buy a system that is always running at 90% of capacity. I buy one where CPU usage is usually around 5-10%. When CPU load or free disk space gets to 50%, this is a sign that it's time to upgrade, because we know that technology increases exponentially, not linearly. Another problem with a computer that is always at 50% or 90% load is that if I wanted to start a new program, it would take a very long time to load. A computer with low average usage has the capability to handle surges such as loading a new application like Microsoft Word, and then returns to the normal state afterward.

Modeling the network as a large computer that has a technological limit and a usage limit allows me to answer many of the questions one might ask about the proposal. "Why upgrade the network now?" can be answered by pointing out that the 1MB limit has fallen below what is technologically possible at this time, even in China - and the hard limit is designed to follow what is possible for a reasonable computer. "Litecoin usage isn't high enough to raise the limit" misses the distinction between the two limits - the purpose of the hard limit has nothing to do with usage. "The limit would be many times higher than usage" is resolved by simply asking whether, if it were possible today to handle 100MB blocks with minimal cost, why not allow the network to process them? We want usage to approach the hard limit, because that means that people are so bullish on using the network that we simply can't handle any more transactions until technology improves. We should not be concerned about processing every block at the size of the hard limit. If we were concerned, then the limit was incorrectly set too high, as it would be if we chose to allow 100MB blocks today.

Other proposals, like the "adaptive blocksize" proposal, confuse the purpose of the limits. Bitpay's adaptive blocksize ties the hard limit to the soft limit. It is dangerous not because it keeps the network too small, but because it can also allow the size of blocks to grow far above what is technologically possible. It allows miners, who don't need or want to be informed about usage trends and future technology, to grow or restrict the hard limit so that it falls out of line with technology. Consider a scenario where there is a surge of usage and block sizes increase dramatically, forcing nodes to upgrade equipment. But it's more likely than not that the surge will be temporarly, and all the equipment just purchased by people who can actually afford to do so will then be wasted, sitting idle in basements.

The hard technological limit doesn't change with usage. A better scenario than an unpredictable adaptive limit is one where if the static technological limit is reached, solutions like the Lightning Network or Segregated Witness would then be preferred. But that would be true only in the case that the network has actually reached technological capacity, which even Gregory Maxwell doesn't claim is the case currently. Creating complex code in the absence of true network limitation is both risky and wasteful. It is possible that the complex solutions like the Lightning Network will never be needed, because computing power will always stay ahead of usage and it's almost always cheaper to buy faster computers than it is to upgrade and test software. Let's find out whether the technological limit will ever be hit before spending time on those things. If the reasonable cost of running a node as defined by the hard limit is ever reached, then the additional costs above what we have decided is reasonable can be pushed off to these top-layer networks.

An important concept in business is "capacity planning" - the ability to reasonably predict what will happen in the future and have resources available at the times they are needed. Capacity planning reduces waste and provides confidence, giving an expanded BIP101/4 litecoin a significant advantage over networks that choose adaptive limits or miner voting. Exactly what power of computer should be targeted should be is an important topic for discussion - but once it is decided, it should not be changed. Charlie Lee said that he thinks that 8MB blocks are beyond the technological limit, so that's why I divided the size in our proposal by 4. Litecoin has the ability to take the best of both worlds by not requiring miners to validate huge blocks all at once, while at the same time pushing through as much data as 8MB BIP101 on bitcoin could every 10 minutes.

In conclusion, the hard limit represents a technological cap, while the soft limit represents a usage cap, and they should not be confused. The simplest possible solution should be preferred, which is that the hard limit should be set to the technological limit, and only in the case that litecoin is limited by technology should more complex solutions be tried. The hard limit should never be changed to be higher or lower than the technological limit.

Since Saturday afternoon, I've spent 16 hours on this task. Over the weekend, I set up a development environment, worked with my brother to get litecoin to compile correctly, found the best implementation of BIP101 (there are several), spent time understanding how it works and what was not needed, and started to implement the simplest changeset possible in litecoin. Yesterday evening, I finished writing the code, and I'm now resolving compilation errors. I hope to move on to testing by tomorrow, have cleared my entire schedule for both days this weekend, and plan to spend as many more weekends as necessary to get the pull request finished as soon as possible. Once finished, we look forward to working with the community to come to a consensus on this or a different proposal to position litecoin as a ready alternative to bitcoin.