Author: Keagan McClelland 2021-12-31 03:10:48
Published on: 2021-12-31T03:10:48+00:00
The issue of treating SoftForks as a single monolithic idea and the need for better terminology to be specific about each fork is discussed in this context. The author argues that soft forks that are non-invasive should be treated differently and can be tested thoroughly on testnet, signet, custom signets, sidechains, etc., on a standalone basis and a bundled basis. However, consensus changes should not be bundled, especially when it comes to activation parameters, as it amplifies the community resources needed to do review. The mandatory signaling period exists in BIP8/9 so that clients that intend to reject the soft fork change have an easy means of doing so in a clean break where consensus is clearly divergent. The author believes that bundling changes reduces the number of people who are qualified to review a particular proposal and intimidates people who may be willing and able to review logically distinct portions of the proposal. This will result in lower amounts of review overall, which will likely have the opposite effect of what is desired.Michael Folkson argues that security-critical software, such as decentralized consensus changes, cannot be treated like any other software project. Decentralized security-critical consensus changes are an emerging field that requires caution and proper testing before deployment. Anthony Towns, on the other hand, believes that bundling proposals together can be beneficial if they have synergies or are easier to think about as a set. Overall, while it may be a basic principle of general software engineering to put many features together in one shot, this approach may not be suitable for security-critical software like Bitcoin. Instead, caution, proper testing, and community consensus are necessary before activating any new features.
Updated on: 2023-05-22T16:00:29.482689+00:00