Author: Anthony Towns 2020-01-16 03:46:17
Published on: 2020-01-16T03:46:17+00:00
In a recent discussion regarding the activation of soft-forks on Bitcoin, Matt Corallo emphasized the importance of having an "out" to observe the response of the ecosystem once the change is presented. He proposed using a BIP 9 process to offer a compelling activation path and allow for observation and discussion time for any lingering minor objections prior to a BIP 8/flag day activation. However, concerns were raised about whether the proposal had enough time for observation. It was suggested that if something appears good to developers and miners but still has underlying problems, it could activate quickly because miners may upgrade quickly and not see a need to tweak the default signaling parameters. To address this concern, one approach suggested was to have the first point release that includes the soft-fork activation parameters not update getblocktemplate to signal the version bit by default, but only do so in a second point release later. This would give miners some extra time to manually enable signaling if they needed to rush things while still creating pressure to look at the changes. It was also pointed out that version bits are set via mining software rather than the node software that constructs blocks. Therefore, there is no strong link between signaling and having actually updated the software to properly enforce the new rules. It was suggested that moving signaling into the coinbase or similar could make that link tighter. However, this would mean miners using the version field as extra nonce space wouldn't be confused with upgrade signaling at least.
Updated on: 2023-05-20T21:27:08.888018+00:00