A simple, adaptive way to scale Bitcoin blocks

This is the last of four articles outlining BitPay’s current thinking and plans regarding the Bitcoin block size issue. The previous article: Scalability, Hard Forks, and Markets, interested readers can visit the link to view the original article.

The block size limit is a consensus rule. If a block is larger than the limit, miners will not include it in the blockchain they are building. If a miner produces a block that is rejected by a majority of miners, the block will be orphaned and the miner will not receive any compensation for their work. Bitcoin could function without a preset fixed limit, but this would create a lot of uncertainty for miners. By letting miners know that there is an upper limit that is observed by the majority of mining power, we have a clear and simple consensus rule that is useful.

A fixed block size limit, such as Bitcoin’s current 1MB, cannot scale to meet the transaction throughput demands of users. Today, we see transactions occurring on the Bitcoin network that are hitting this artificial limit. Simply increasing the block size limit would be a straightforward approach, but we have seen a debate simmer over the past few months over increasing the block size limit. This debate is harmful, and if it drags on for a year or two, it could be devastating for Bitcoin.

An increasing, but fixed, block size cap is problematic. What if technological advances fail to keep pace with the increasing limit? We might find ourselves in a situation where the block size cap is much higher than the market block size, which is actually unreasonable. Alternatively, the limit might be much lower than the market and technology constraints, and a debate about raising the cap would rage.

There are already some proposals. For example, BIP101, according to its rules, the Bitcoin block size will steadily increase at a fixed rate over time, but it has been opposed by most miners because miners feel that this plan is too radical. If the technology cannot keep up with the pace of BIP101, this limit will cause a lot of uncertainty for miners. BIP100 is considered to be a more miner-friendly solution, but the code changes it requires are more complex. It also requires miners to actively communicate their preferences for block size limits. Conceptually, it is a good idea to use the blockchain to establish consensus about the block size limit (as BIP100 does). After all, this is an established adaptive control method for mining difficulty.

To determine the upper limit of block size, miners need a simple, but adaptive consensus rule.

Of all the ideas we've reviewed, the one that seems most appealing is a simple adaptive cap based on the median block size of recent blocks. To determine the block size limit, you take the median size of a recent sample of blocks and multiply it by a factor. For example, you might set the block size limit to 2 times the median size of the last 2016 blocks. It's worth noting that Ethereum uses a similar approach (although it uses an exponentially weighted moving average instead of a simple median). There is also a proposal called "flexcap", but we think it is overly complex and unnecessary.

In addition to a hard limit, there will be a configurable soft limit that will be controlled by the size of the blocks produced by miners. This soft limit is also the median value of the most recent sampled blocks multiplied by a multiple. The soft limit is easily configurable, so miners can exert some influence on the future development of block sizes. A reasonable default multiple value will be chosen (i.e. 1.5).

The formula is summarized as follows: (where n is the number of recent blocks used to calculate the median value)

 limit = m * median(n) // (block limit = m * median (n blocks))

 soft_limit = sm * median(n) // (soft limit = sm * median (n blocks)

The values ​​of m and n need to follow consensus rules, and the value of sm is a reasonable default configuration value. Algorithm details such as rounding behavior, or whether to adjust the limit every block, or every n blocks, will also be a consensus issue. The current 1MB block limit will become a lower limit of the hard limit.

The reason for choosing to use the median instead of the average is to prevent miners from artificially raising the block size limit through transactions. Or, conversely, producing some empty blocks. Under the median rule, you need to have more than 50% of the mining power to control the entire rule. Of course, if someone controls more than 50% of the computing power, the problem faced by Bitcoin is far more serious than the block size limit problem.

With this adaptive block size limit rule, the transaction throughput of the Bitcoin network can be increased to meet user demand while still being constrained by current scaling limits. When miners produce larger blocks, a higher orphan rate occurs. When the orphan rate increases, miners will moderate their block sizes and more carefully select transactions in blocks.

At BitPay, we will try this approach. We will run tests to analyze the impact different settings might have on the block history. We will also analyze the behavior in extreme cases and comment on it from a game theory perspective. You can join us in the experiment on a forked Bitcoin client: https://github.com/bitpay/bitcoin. If our results show that this is the best way to scale Bitcoin, we will work hard to convince others (most importantly, miners).

During this time, you can spend these coins at any BitPay merchant if miners reach consensus on a temporary fixed block size cap.

The author, Stephen Pair, is the CEO of BitPay.

Original article: https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.8qhuimumq
By Stephen Pair
Compiled by: Satuoxi
Source (translation): Babbitt Information (http://www.8btc.com/a-simple-adapt…ock-size-limit)