Author: Keagan McClelland 2021-02-18 15:04:53
Published on: 2021-02-18T15:04:53+00:00
In a Bitcoin development mailing list, Keagan urges the community to consider the actual effects of Taproot activation. While the designation of "soft fork" is accurate, he thinks it does not adequately convey how non-intrusive a change like this is. He argues that all that Taproot does is imbue a previously undefined script version with actual semantics. In his view, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what he estimates to be 1% of bitcoin users can effectively block any change from here on forward.Matt Corallo responds by saying that several soft forks in the past had a several-block reorg and that we need to very carefully consider activation to ensure we reduce the risk of that as much as possible. Keagan thinks that allowing developers who rely on "undefined behavior" to exert tremendous influence over what code does or does not get run will have a negative impact on Bitcoin's longevity. On the other hand, choosing L=F might give miners control of network consensus in ways they haven't been up until now.Michael Folkson argues that Bitcoin greatly benefits from upgrades such as Taproot and suggests that even if they chose not to do future soft fork upgrades, someone else will attempt it in the future. However, Matt warns that if different implementations ship different consensus rules, we should stop there and not activate Taproot because the worst outcome possible is to have Bitcoin fall out of consensus.ZmnSCPxj suggests having a release that requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set, assuring everyone that neither choice is being forced on users, and instead what is being forced on users is for them to make that choice themselves.On February 16th, there was a second meeting on Taproot activation with majority support for LOT=false over LOT=true from the first meeting. Arguments were explored in depth and the conversation log can be found at gnusha.org/taproot-activation/2021-02-16.log. Activation height range proposed is 693504-745920 with MASF threshold of 1815/2016 blocks (90%). However, only ~100 people showed up for the meetings which are open to all and hardly representative of the entire community.The meeting was challenging as it's difficult to know who will attend and most people’s views in advance. There are arguments for both LOT=true and LOT=false, but there was clearly more strong opposition from Bitcoin Core contributors, Lightning developers, and other community members against LOT=true than there was for LOT=false. Some mining pools also expressed a preference for lot=false though the strength of that preference is unclear.It is the current assessment that if we are to attempt to finalize Taproot activation parameters and propose them to the community at this time, our only option is to propose LOT=false. Delaying further could be counterproductive in our collective aim to get the Taproot soft fork activated as early as possible. A code review of the Bitcoin Core PR #19573 is planned for Tuesday February 23rd at 19:00 UTC on the IRC channel ##taproot-activation.The email thread provided is a thank you message from Michael Folkson to the participants who joined the discussion on the channel before and after the meeting. He thanked them for engaging productively and in good faith. The email also includes his contact details such as email, Keybase, and PGP. The email is a part of the Bitcoin-dev mailing list, which can be subscribed through the link provided in the email.
Updated on: 2023-06-14T17:53:26.288160+00:00