Yesterday’s UASF (LOT=true) kick off meeting
3 messages, 3 to 4 Mar 2021. Started by Michael Folkson.
Michael Folkson (2), Ariel Lorenzo-Luaces
Yesterday we held a UASF (LOT=true) kick off meeting on the ##uasf IRC channel.
The conversation log is here: http://gnusha.org/uasf/2021-03-02.log
It was announced (at short notice admittedly) here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html
It is clear frustration is building but it is also clear that this isn’t a conducive environment for development and review. The high level activation discussion has been done to death. Barring a miracle the only thing Core will ship is BIP 8 (1 year, LOT=false). The alternative appears Core ships nothing.
At this point in time it also appears the greatest risk to Taproot dying a slow death is a small group of developers who think talking in conservative tones and talking about endless philosophy makes Bitcoin a conservative system. (It doesn’t, it just makes it a dying, decaying one).
We have a trillion dollar industry (all signed up to this upgrade) wasting time monitoring these arguments rather than preparing for an upgrade and preparing for the small but manageable risks that any such upgrade entails later in the year. Development projects on hold because there is no end in sight for Taproot activation.
We need to give miners and users the ability to activate this year (2021). If we fail to do that through whatever means (Core, UASF release) etc I personally will assume Taproot will never activate. I will also assume Bitcoin is not a project for the incredibly able people who have designed and shipped a complex upgrade (Taproot) that miraculously has overwhelming consensus amongst the entire community. Failing to ship activation code (a very small code change in comparison) is a joke.
We need to get this done this year. A UASF (LOT=true) project needs to be ready to assemble just like it was in 2017 to make sure a small group of individuals don’t block progress. But Core also needs to be given the opportunity to ship a BIP 8(1 year, LOT=false) activation that can be used to activate this year that is as well reviewed and well tested as any other Core consensus code change.
Once things have calmed down I think we should revisit what progress has been made and take it from there.
On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (6 lines)
> > At this point in time it also appears the greatest risk to Taproot > dying a slow death is a small group of developers who think talking in > conservative tones and talking about endless philosophy makes Bitcoin > a conservative system. (It doesn’t, it just makes it a dying, decaying > one).
The current risk to taproot and all future activations is a loud minority of users who are threatening to co-opt a LOT=false activation by switching the parameter and organizing a marketing blitz that could end in a fork if things don't go well. As long as that threat persists consensus won't be reached. Then an activation client probably won't be released because I don't expect many devs will have an appetite for writing code that either doesn't have consensus or code that will be manipulated into creating consensus conflicts. I think Bitcoin is fine staying as is until that minority forks off with their own alt-node. If the UASF minority is dead set on creating the alt-node then I only hope it's released quickly so the deadlock can break. A quick UASF fork allows for an early LOT=false activation.
Cheers Ariel Lorenzo-Luaces
Quoted text (9 lines)
> -- > Michael Folkson > Email: michaelfolkson@gmail•com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Hi Ariel
Quoted text (1 line)
> I think Bitcoin is fine staying as is until that minority forks off with
their own alt-node.... A quick UASF fork allows for an early LOT=false activation.
I think you misunderstand BIP 8 (LOT=true). Although no timetable has been finalized as of yet (and hence we are in the realm of speculation rather than facts), the earliest the MUST_SIGNAL period would kick in is around July 2022. That doesn't sound very quick to me if you seek a LOT=false release after a LOT=true release has failed to activate.
Quoted text (1 line)
> The current risk to taproot and all future activations is a loud minority
of users who are threatening to co-opt a LOT=false activation by switching the parameter
As I've said in previous emails to this list, some people are determined to ignore the discussion and (open to all) meetings of recent weeks and block progress until they find their philosopher's stone. They seek to ignore all the work people have done laying out the options, communicating those options to the community and narrowing them down. Instead they bring up alternative proposals which were discussed and rejected weeks or months ago. With this mindset we'll still be arguing about Taproot activation in 2030.
I get that there isn't overwhelming consensus on the LOT parameter, this is a fact. But there won't be overwhelming consensus on any activation mechanism, that has become clear. I am of the view that consensus on one parameter of an activation mechanism does not need to be as high as it is on the actual soft fork that is being activated (which does have overwhelming consensus). And of course if and when a LOT=true (UASF) version is released you are absolutely free not to run it. I hope (and suspect) you would reconsider if July 2022 (or later) was approaching and it was the only way to activate Taproot.
Thanks Michael
On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces <arielluaces@gmail•com> wrote:
Quoted text (36 lines)
> On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > > > At this point in time it also appears the greatest risk to Taproot > > dying a slow death is a small group of developers who think talking in > > conservative tones and talking about endless philosophy makes Bitcoin > > a conservative system. (It doesn’t, it just makes it a dying, decaying > > one). > > The current risk to taproot and all future activations is a loud > minority of users who are threatening to co-opt a LOT=false activation > by switching the parameter and organizing a marketing blitz that could > end in a fork if things don't go well. > As long as that threat persists consensus won't be reached. Then an > activation client probably won't be released because I don't expect > many devs will have an appetite for writing code that either doesn't > have consensus or code that will be manipulated into creating > consensus conflicts. > I think Bitcoin is fine staying as is until that minority forks off > with their own alt-node. If the UASF minority is dead set on creating > the alt-node then I only hope it's released quickly so the deadlock > can break. A quick UASF fork allows for an early LOT=false activation. > > Cheers > Ariel Lorenzo-Luaces > > > -- > > Michael Folkson > > Email: michaelfolkson@gmail•com > > Keybase: michaelfolkson > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >