Author: Martin Lízner 2017-03-29 07:49:31
Published on: 2017-03-29T07:49:31+00:00
In a recent discussion on the bitcoin-dev mailing list, there was a proposal for a conservative approach to a hard fork. The proposal included fixing historical bitcoin issues and improving code, planning the hard fork activation date well ahead (12 months+), allowing an increase in block size on a year-to-year basis as suggested by Luke, compromising with miners on initial block size bump (e.g. 2MB), and implementing SegWit. The thread also included a proposal by Wang Chun that had been previously rejected by coredevs at a Hong Kong Consensus meeting. The proposal suggested coding a patch to remove the block size limit of 1MB but not activating it until the next block halving in spring 2020. This would give everyone enough time to prepare for the fork over the next three years. Third-party services, libraries, wallets, and exchanges will have ample time to get ready. Chun’s proposal would make all hard fork proposals become soft forks. There would be enough time to discuss all the proposals and decide which one to go for. For example, if they choose to fork only to 2MB, since 32MiB is already scheduled, reducing it from 32MiB to 2MB will be a soft fork. The proposal aims to code something before it becomes too late.
Updated on: 2023-06-11T22:45:40.816533+00:00