Author: odinn 2015-07-01 22:49:12
Published on: 2015-07-01T22:49:12+00:00
In a recent email exchange between Tier Nolan and Adam Back, the latter suggested that having a hard cap on block size serves as a safety limit in case our understanding about the economics, incentives or game-theory is wrong worst case. Nolan agrees with this point. The two also discussed combining BIP 100 and BIP 101 to increase consensus. Nolan suggested that Jeff's BIP 100 is a better alternative to Gavin Andresen’s proposal(s). If the two BIPs were combined, the proposal would include a miner vote threshold, a waiting notice period until earliest start time, a default target set to 1 MB, a soft limit set to 1MB, a hard limit set to 8MB + double every 2 years, and a miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum). Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks. Miners could leave the 1MB limit in place initially, with the vote being to get the option to increase the block size. Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block. If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it. The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal.
Updated on: 2023-06-10T00:21:53.936288+00:00