Author: Wang Chun 2017-03-28 16:59:32
Published on: 2017-03-28T16:59:32+00:00
The author of the proposal had suggested a hard fork approach last year in Hong Kong Consensus, which was instantly rejected by coredevs at the meeting. However, the author has now posted the proposal again for comments. The basic idea is that hard forks are risky and should be well prepared, and thus we need a long time to deploy it. The block capacity is approaching its limit, and we must think ahead.The author suggests coding a patch right away to remove the block size limit of 1MB but not activating it until spring 2020. The author proposes to remove the 1MB limit at the next block halving in Spring 2020, only limiting the block size to 32MiB, which is the maximum size the current p2p protocol allows. This patch must be in the immediate next release of Bitcoin Core.With this patch in Core's next release, Bitcoin will work just as before, no fork will ever occur until Spring 2020. But everyone knows there will be a fork scheduled. Third-party services, libraries, wallets, and exchanges will have enough time to prepare for it over the next three years.There have been many proposals over the past years on how to increase the block size limit, such as BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so on. These hard fork proposals, with the proposed patch already in Core's release, would all become soft forks. We'll have enough time to discuss all these proposals and decide which one to go with. For example, if we choose to fork to only 2MB, since 32MiB is already scheduled, reducing it from 32MiB to 2MB will be a soft fork.In conclusion, the author believes that something needs to be coded right now before it becomes too late.
Updated on: 2023-06-11T22:53:15.502139+00:00