Author: Matt Corallo 2021-02-21 14:30:45
Published on: 2021-02-21T14:30:45+00:00
In a discussion on the bitcoin-dev mailing list, Matt Corallo expressed his belief that "some vocal users" threatening to fork themselves off is not a good justification for technical decisions. He emphasized the need for communication and agreement that a failed BIP 8/9 activation does not mean the end of the story for Taproot activation. If there is broad consensus for Taproot but some miners fail to upgrade in time, he believes a flag day activation would be merited. However, he warns against forced-signaling via a UASF/BIP8-style fork due to the material additional risk it carries.Ariel Lorenzo-Luaces asked about the tradeoffs of a BIP8(false, ∞) option, which would remove some of the concerns of coordinating a UASF with an approaching deadline. ZmnSCPxj responded by suggesting a workaround involving maintaining two datadirs and running two clients, with one external client running an LOT=X and an internal client running at most 0.21.0 and using the connect= directive to connect locally to the external client. The user can select LOT=C or LOT=!C on the external client based on their preferences.Matt Corallo reiterated Bitcoin Core's long-standing policy of not shipping options that shoot oneself in the foot and expressed disappointment if that were to change. He believes that people are welcome to run such software themselves, but the loud minority on Twitter and other platforms likely do not have enough financial weight behind their decision to do anything but switch back if they find themselves on a chain with no blocks. He stresses the importance of recommending courses of action that have reasonable levels of consensus and are technically sound.Adam Back asked whether releasing LOT=false would be considered as "developers forcing their views on users." He believes that having a LOT=true option would be minimally friendly and useful to avoid assumptive control via defaults.
Updated on: 2023-05-21T00:47:53.852315+00:00