Author: Anthony Towns 2022-10-02 04:06:54
Published on: 2022-10-02T04:06:54+00:00
A recent suggestion was made on the Bitcoin-dev mailing list regarding the testing of future soft fork proposals. The proposal suggested that these soft forks should be tested on separate testnets, such as Segnet, to avoid unintended side effects impacting mainnet operation. The history of past soft fork testing was also discussed, including p2sh, cltv and csv, segwit, taproot, CTV, and Drivechains.Segnet was mostly used for the development of segwit itself, while Signet is seen as a good option for testing soft forks outside of core since it does not require community consensus. However, signet mining is a closed set, meaning signet soft forks always have gatekeepers.The Bitcoin Core developers are discussing enabling taproot on the default signet to make it easier to develop and test new and improved bitcoin applications. However, there are concerns about potential disruption to users who may not be interested in testing soft fork proposals. To address this issue, a specific approach has been proposed involving running both a core and an inquisition bitcoind but only using the inquisition bitcoind for generating blocks. This ensures that blocks satisfy core's consensus rules and prevents any potential disruption.Another concern is that changes to a soft fork proposal or a buggy soft fork proposal pushed to the default signet makes previous valid/invalid transactions invalid/valid. To prevent any bugs affecting real money, the solution is to have it happen on the global signet first before mainnet. Opting-in to potential disruption from future soft forks that are anywhere near the deployment phase is considered a good idea as it allows for fixing any potential issues before risking the loss of real money.
Updated on: 2023-05-22T21:13:47.972339+00:00