* [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting
@ 2021-03-03 12:15 Michael Folkson
2021-03-04 2:18 ` Ariel Luaces
0 siblings, 1 reply; 3+ messages in thread
From: Michael Folkson @ 2021-03-03 12:15 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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.
--
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting
2021-03-03 12:15 [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting Michael Folkson
@ 2021-03-04 2:18 ` Ariel Luaces
2021-03-04 10:54 ` Michael Folkson
0 siblings, 1 reply; 3+ messages in thread
From: Ariel Luaces @ 2021-03-04 2:18 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting
2021-03-04 2:18 ` Ariel Luaces
@ 2021-03-04 10:54 ` Michael Folkson
0 siblings, 0 replies; 3+ messages in thread
From: Michael Folkson @ 2021-03-04 10:54 UTC (permalink / raw)
To: Ariel Luaces; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3779 bytes --]
Hi Ariel
> 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.
> 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:
> 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
>
--
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
[-- Attachment #2: Type: text/html, Size: 5242 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-03-04 11:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-03 12:15 [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting Michael Folkson
2021-03-04 2:18 ` Ariel Luaces
2021-03-04 10:54 ` Michael Folkson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox