Author: Michael Folkson 2021-10-11 12:24:10
Published on: 2021-10-11T12:24:10+00:00
The author argues against frequent soft forks with a single or minimal set of features and instead advocates for infrequent soft forks with batches of features. The robustness, security, and ability to resist harmful or suboptimal changes to the system are the ultimate priority. Soft fork code should not be merged into a Bitcoin implementation until the entirety of that soft fork has sufficient community consensus. Miner signaling is a tool for signaling readiness and should not be facilitated until there is sufficient community consensus on the soft fork. In a world where there isn't overwhelming community consensus on the activation method, the activation parameters, and what to do if the first activation attempt fails, soft fork activations contain downside risk on top of the already acknowledged risks of bugs, consensus divergences, and botched implementations of soft fork features. This is an important additional argument for infrequent soft forks with batches of features rather than frequent soft forks with a single feature.
Updated on: 2023-06-15T02:38:44.122220+00:00