A future-proofed BIP 100

[amincd]

Motivation

BIP 100 proposes a limit determined by super-majority miner vote, up to a maximum explicit limit of 32 MB. Specifically, the preferred block size limit of a miner is expressed in the Coinbase transaction, and the minimum block size limit value of the middle 60 percent of the values of the last 12,000 blocks becomes the new limit, with a maximum change of 2x in either direction.

The original draft of BIP 100 did not contain the explicit 32 MB limit, but this restriction was added due to concern about the potential for the mining network to decide to increase the limit to levels detrimental to network decentralization.

While eliminating one risk, the addition of the 32 MB limit introduced a new one: a future hard fork to raise the 32 MB limit. As has been witnessed over the last year in the debate over replacing the 1 MB limit, hard forks that deal with the block size limit are highly contentious, due to their far-reaching consequences. This contention makes such hard forks risky, as it increases the risk of a hard fork without full consensus occurring, which would carry with it a significant risk of Bitcoin splitting into two distinct and non-interoperable networks and blockchains.

The Bitcoin userbase and development community will undoubtedly be significantly larger, with more diversity of views, and less cohesion amongst the various stakeholders in the Bitcoin economy, when conditions require executing a hard fork to raise the 32 MB limit, and therefore the risks associated with the hard fork will likely be much greater than the already considerable risks associated with the hard fork to replace the static 1 MB limit.

For these reasons, it would be preferable to modify BIP 100 to remove the explicit 32 MB limit, and find an alternate means of mitigating the risks to network decentralization from allowing miner preference to set the block size limit.


Proposal

The proposed solution is to create a predefined schedule of growing upper and lower bounds for the block size limit value, within which miner preference determines the exact value using the same mechanism as proposed in BIP 100, but which cannot be escaped through miner vote.


Specifications

Two variations of the bounded solution are offered, a 'simple bounded hash power mediated limit', and an 'enhanced bounded hashpower mediated limit'.

Simple bounded hash power mediated limit (SBHML):

The 'minimum block size limit' increases by 10 percent a year, and the 'maximum block size limit' increases by 40 percent a year, for 30 years. After 30 years, the minimum block size limit increases by 0 percent a year, and the maximum block size limit is increased by 30 percent a year.

Enhanced bounded hash power mediated limit (EBHML):

At every block, a base block size limit, B, is calculated from the central moving average of the block size limit 262500 blocks (approx 5 years) in the past, with the mean calculated from the 52,500 blocks on each side of the central block, plus the central block.

The minimum block size limit of a given block is 1.61051 (10 percent annual growth for five years) times B, for 30 years.

The maximum block size limit of a given block is 5.37824 (40 percent annual growth for five years) times B, for 30 years.

The annual growth factor changes to 0 and 30 percent, for the minimum and maximum block size limit, respectively, after 30 years.


Comparison between EBHML and SBHML

At the cost of greater complexity, the EBHML proposal reduces the range of possible block size limit values over nearer-term time-scales, thus increasing the predictability of the block size limit, and reducing, in proportion to how near-term the time frame, the maximum size of swings in the block size limit.

The difference between the minimum and maximum block size limit, and by extension, the maximum potential size of the swings in the miner defined block size limit, grows with time in the SBHML proposal, increasing the risks posed by irresponsible stewardship of the block size limit by the mining majority, while the EBHML lacks this negative quality.

EBHML is therefore recommended over SBHML.


Rationale

By having an automatically increasing upper and lower bound for the block size limit, the risk that BIP 100 contains that another hard fork will be needed in the future to accommodate the need for larger blocks is significantly reduced. The dynamic limit also provides the same function as the explicit 32 MB limit in the BIP 100 proposal, in limiting the potential damage done to decentralization from the mining network choosing a too-high limit.

The choice of 10 and 40 percent per year growth for the minimum and maximum block size limit, respectively, for the first 30 years is premised on projected minimum and maximum growth in broadband cost-performance. These figures are reduced to 0 and 30 percent per year after 30 years because of the assumed likelihood of investments in broadband growth eventually seeing diminishing returns as low hanging fruit for cost-performance gains become increasingly scarce.

[mmeijeri]

As has been witnessed over the last year in the debate over replacing the 1 MB limit, hard forks that deal with the block size limit are highly contentious, due to their far-reaching consequences.

Then we should have multiple much smaller increases. Start with BIP102, then commit to yearly evaluations of whether it is technically safe and economically necessary to increase the block size limit. Each year the limit could be doubled or kept the same.

[amincd]

1. There is no guarantee one of these 'uncontroversial' hard forks won't become controversial, especially as the community gets larger and there are more voices. What was once a consensus position can become contentious due to new information or ideas. This makes the market (people involved in the Bitcoin space) uneasy.

2. Hard forks centralize the community, because in practice, they require the community to coalesce around a small ad-hoc governing structure for the hard fork to have consensus. This makes frequent hard forks antithetical to the decentralized quality of Bitcoin.

[Was]

What does this look like in code?

[Voltarius]

1. There is no guarantee one of these 'uncontroversial' hard forks won't become controversial, especially as the community gets larger and there are more voices. What was once a consensus position can become contentious due to new information or ideas. This makes the market (people involved in the Bitcoin space) uneasy.

2. Hard forks centralize the community, because in practice, they require the community to coalesce around a small ad-hoc governing structure for the hard fork to have consensus. This makes frequent hard forks antithetical to the decentralized quality of Bitcoin.

But the nature of bitcoin is also innovation, it can't just remain static if a problem surges, technologies of this kind need to be on continuous change otherwise they become obsolete.

[amincd]

Not really. A protocol can remain static while overlay protocols are built on top of it, and technology is created to interact with it. A decentralized consensus protocol needs to be unchangeable for the sake of stability, immutability, and censorship resistance, IMHO.

[GingerAle]

1. There is no guarantee one of these 'uncontroversial' hard forks won't become controversial, especially as the community gets larger and there are more voices. What was once a consensus position can become contentious due to new information or ideas. This makes the market (people involved in the Bitcoin space) uneasy.

2. Hard forks centralize the community, because in practice, they require the community to coalesce around a small ad-hoc governing structure for the hard fork to have consensus. This makes frequent hard forks antithetical to the decentralized quality of Bitcoin.

Thats an evolving quality, IMO. And there is nuance. The theoretical / idealized architecture of bitcoin has a decentralized quality, but in practice, it does not. Mining is centralized by pools. Consensus is centralized (by which chain the fiat -> bitcoin onramps decide to use.)

The original design mentioned nothing of how the code would be maintained, save for the concluding line of the whitepaper "Any needed rules and incentives can be enforced with this consensus mechanism." And of course the consensus mechanism described is "They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them..." My point being that while the network architecture was designed to be decentralized, the human component was not addressed. The human-code-management component.

As the OP states, a dynamic block size seems the most logical way forward. The goal of cryptocurrencies is to remove humans from as much of the equation as possible. An ideal cryptocurrency will continue functioning as long as people mine it (and the internet works).

Not really. A protocol can remain static while overlay protocols are built on top of it, and technology is created to interact with it. A decentralized consensus protocol needs to be unchangeable for the sake of stability, immutability, and censorship resistance, IMHO.

Indeed, it can remain static, and it will eventually become locked in. At some point it will be locked in, and we'll be stuck with whatever was last agreed upon.

[amincd]

The goal of cryptocurrencies is to remove humans from as much of the equation as possible. An ideal cryptocurrency will continue functioning as long as people mine it (and the internet works).

Yes exactly. And I'll add that when humans are involved, it should be through as few centralised intermediaries as possible. Here BIP 100's hash power mediated block size limit change mechanism is superior to the hard fork block size limit change mechanism, which is highly dependent on a small number of influential developers.

One might argue that pools are analogous to centralised intermediaries that will control the limit under a BIP-100-like regime, but hash power generators can point their machines at any pool they want, which transparently provides feedback to pool operators on whether they're serving their hash power generator well and provides them with a powerful incentive to do so, so it's really hash power generators - broad class of people for which there is no political barrier to entry to join - that have the power. And unlike the hard fork process for changing a consensus rule, pool operators don't need to download new software to express their will to change the limit.

Indeed, it can remain static, and it will eventually become locked in. At some point it will be locked in, and we'll be stuck with whatever was last agreed upon.

Yes, and the danger is that when the Bitcoin protocol gets locked into a particular state, it also locks in a block size limit that is too low or too high. BIP 100 or some variation of it solves that. The protocol can reach a final state, and still have its limit fine-tuned, in response to changing market and technological conditions, by the community.