BIP: ? Layer: Consensus (hard fork) Title: Safer and growing block size limit Author: Luke Dashjr <luke+bip@dashjr.org> Comments-Summary: No comments yet. Comments-URI: FIXME Status: Draft Type: Standards Track Created: 2017-01-19 License: BSD-2-Clause
The block size limit is reduced to a reasonably safe value (optional), and gradually increased over time, eventually expanding beyond the current limits.
This BIP is licensed under the BSD 2-clause license.
Upon activation, the block size limitation is replaced by the function below, applied to the median of the timestamps of the previous 11 blocks, or in code terms: the block size limit for pindexBlock is GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()).
It implements a series of block size steps, one every ~97 days, and ending at just under 31 MB in 2045 April, with each step increasing the maximum block size by 4.4%, allowing an overall growth of 17.7% per year. The initial size limit upon activation depends on when it is activated: for example, if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.
uint32_t GetMaxBlockSize(int64_t nMedianTimePast) {
// In case we activate early on regtest.
if (nMedianTimePast < 1483246800) {
return 300000;
}
// The first step is on January 1st 2017.
// After that, one step happens every 2^23 seconds.
int64_t step = (nMedianTimePast - 1483246800) >> 23;
// Don't do more than 107 steps, to stay under 32 MB.
step = std::min<int64_t>(step, 107);
// Every step is a 2^(1/16) factor.
static const uint32_t bases[16] = {
// bases[i] == round(300000 * pow(2.0, i / 16.0))
300000, 313282, 327152, 341637,
356762, 372557, 389052, 406277,
424264, 443048, 462663, 483147,
504538, 526876, 550202, 574562
};
return bases[step & 15] << (step / 16);
}
The concept of block weight is introduced or modified: all witness data, including both scriptSig (pre-segwit transactions) and segwit witness data (if applicable), is measured as 1 weight-unit (WU), while all other data in the block is measured as 4 WU. The weight of a block may not exceed double the size limit in bytes.
The maximum size of a transaction stripped of witness data is limited to 1 MB.
This BIP is to be deployed in two stages:
The first stage is deploying in full node software deactivated. This requires consensus from the entire Bitcoin community, and ought to be evaluated by the release manager of each full node implementation before release. All full node implementations must deploy this change before 2024, or the proposal is deemed to have failed.
Since this stage only implies growth of the block size limit (not reduction), far in advance of its effective date, and should not in any way impede the efforts of others to increase (or decrease) it faster/sooner (eg, BIPs 10x) or even substantially alter the very concept of decentralised consensus (eg, BU), it is hoped this proposal will be uncontroversial and thus able to attain consensus from the entire community at the very least as a better failure scenario than the current "1 MB forever" (or "2-3 MB forever" with segwit).
After consensus is established (but not necessarily before all nodes have deployed compatible software, so long as this still occurs before 2024), the BIP may be activated using BIP 9 using the name TBD and bit TBD.
For Bitcoin mainnet, the BIP9 starttime will be TBD (Epoch timestamp TBD) and BIP9 timeout will be 2024 September TBD (Epoch timestamp TBD).
For Bitcoin testnet, the BIP9 starttime will be TBD (Epoch timestamp TBD) and BIP9 timeout will be TBD (Epoch timestamp TBD).
Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally.
However, at the same time, the current rate of blockchain growth is demonstratably too high for many users: full node count and percentage continue to drop (with the most-cited reason being blockchain-size related); miners are de-facto skipping validity checking of blocks before mining on top of them; and the total cost to sync a new node for the first time is growing significantly faster than technology improvements to reduce such costs. It is a regular occurrence to see new users complain about the time to setup a node, and established members of the community recommending downgrading to non-full wallet software, which results in the new user gaining bitcoin as a currency, but not the security of Bitcoin itself, and compromises the integrity of the network as a whole by widespread usage.
Currently, there is a consensus rule in place that limits the size of blocks to 1000000 bytes. Changing this presently requires a hard-forking change: one that will require every full node in the network to implement the new rules. The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem. This BIP places the expansion of the block size limit several years out, so as to avoid controversy and give plenty of time to upgrade. Upgrading can be done even if this BIP does not activate for several years due to potential controversy over the short-term reductions, and as such consensus for its deployment should be determined only by the long-term block size increase.
Won't sudden increases in the block size limit upset market forces?
- Because every increase (including the first) is only 4.4%, risk from large market or technological changes is minimized.
- Currently, the blockchain size is approximately 100 GB. If we assume a 17.7% rate of technological improvement, maintaining the current cost allows the growth of 17.7 GB over the next year. Across the expected 52596 blocks in a year, this leaves each block 337 kB to work with. Because we will be increasing the block size limit over time, this is rounded down to 300 kB. (Note that the block weight limit is also rounded up.)
- 300k is only used for the block size limit should the proposal be activated prior to 2017 April. If it is deemed too small, activation can simply be delayed until the desired limit is reached, retaining the current block size/weight limits until that time (or even an additional softfork used to create a temporary limit at the desired level).
- The growth rate of 17.7% growth per year is consistent with the average growth rate of bandwidth the last years, which seems to be an important bottleneck. If over time, the 17.7% annual block size growth factor is beyond what actual technology improvements offer, the intention should be to soft fork to a smaller block size limit.
- This growth rate leads to the new block size limit exceeding the current limit only after seven years, by which time existing nodes using BIP-FIXME:hfprep will relax their own block size rules, making this BIP a softfork rather than a hardfork.
- Using the "median time past" guarantees monotonic behaviour, as this median is required to be increasing, according to Bitcoin's existing consensus rules. Using the "median time past" of the block before means we know in advance what the limit of each block will be, without depending on the actual block's timestamp.
- Miners should be advised to soft-limit their blocks down to the current proposed limit, perhaps gradually, before this softfork is activated. This will allow the market time to adapt, and make it possible to back out of this softfork should serious problems arise.
- With a typical 2-of-2 multisig spend with 2 inputs and 2 outputs, the weight is approximately 80% higher than the size.
- Concerns exist that only a weight limit increases the resource requirements to handle spam blocks, while legitimate blocks only get to use a subset of the maximum block size for legitimate capacity. Enforcing a block size limit keeps the worst-case scenario closer to legitimate real-world usage.
With this algorithm, the block size may exceed the current limits during 2024 June. Several years is sufficient time for all nodes to update so long as this proposal's extension beyond current limits has consensus by then.