Author: Matt Corallo 2021-02-22 14:00:29
Published on: 2021-02-22T14:00:29+00:00
In an email thread between Anthony Towns and Matt Corallo, the potential risks of a UASF-style command line option allowing consensus rule changes in a node before a fork were discussed. Towns noted that if a lockinontimeout=true node requested compact blocks from a lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, it could result in a ban. Additionally, both sides of the fork need to find each other.Towns mentioned that a specific case of concern would be when a chain where taproot is impossible to activate temporarily has the most work. In this scenario, miners with lockinontimeout=true need to be well connected so they do not end up competing with each other while catching back up. Corallo acknowledged the technical complexity associated with a "change the consensus rules" option and stated that given it is not a critical feature, putting resources into fixing these issues is likely not worth it.
Updated on: 2023-05-21T00:58:33.782657+00:00