Author: Greg Sanders 2022-05-12 22:56:22
Published on: 2022-05-12T22:56:22+00:00
The email thread discusses the implementation of BIP8 and the necessity of a MUST_SIGNAL state. The purpose of the mandatory signaling was to ensure all existing clients waiting for segwit signaling would be activated together with any BIP8 clients. However, if there are no other clients, the MUST_SIGNAL state no longer accomplishes its purpose. Some people would like some signal on the chain that indicates a soft-fork activation in order to allow people who object to the fork to make an "anti-fork" that rejects blocks containing the soft-fork signal. The email suggests that using version bits and signaling over multiple blocks risks losing mining power if miners do not conform, or are unable to conform, to the version bits signal. The proposal removes lockinontimeout flag, and activation never fails although MUST_SIGNAL can be longer if miners signaling does not reach the threshold. A soft-fork signal to enable an "anti-fork" only needs to be on a single block and it can be almost anything. Solutions are suggested to these problems such as developers plan and ship the binaries with activation code in time and mining pools pay attention, participate in soft fork discussions, hire competent developers and reach out to developers in community if require help.
Updated on: 2023-06-15T20:45:40.006454+00:00