On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
Right, that is one option. Personally I would prefer a Bitcoin Core release
sets LOT=false (based on what I have
heard from Bitcoin Core contributors) and a community effort releases a
version with LOT=true. I don't think users
should be forced to choose something they may have no context on before
they are allowed to use Bitcoin Core.
My current understanding is that roasbeef is planning to set LOT=false on
btcd (an alternative protocol
implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on
Bitcoin Knots.
On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <zmnsc...@protonmail.com
<mailto:zmnsc...@protonmail.com>> wrote:
Good morning all,
> "An activation mechanism is a consensus change like any other change,
can be contentious like any other
change, and we must resolve it like any other change. Otherwise we risk
arriving at the darkest timeline."
>
> Who's we here?
>
> Release both and let the network decide.
A thing that could be done, without mandating either LOT=true or
LOT=false, would be to have a release that
requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the
parameter is not set.
This assures everyone that neither choice is being forced on users, and
instead what is being forced on users,
is for users to make that choice themselves.
Regards,
ZmnSCPxj
>
> On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> > Thanks for your response Ariel. It would be useful if you responded
to specific points I have made in the
mailing list post or at least quote these ephemeral "people" you speak
of. I don't know if you're responding
to conversation on the IRC channel or on social media etc.
> >
> > > The argument comes from a naive assumption that users MUST
upgrade to the choice that is submitted into
code. But in fact this isn't true and some voices in this discussion
need to be more humble about what users
must or must not run.
> >
> > I personally have never made this assumption. Of course users
aren't forced to run any particular software
version, quite the opposite. Defaults set in software versions matter
though as many users won't change them.
> >
> > > Does no one realize that it is a very possible outcome that if
LOT=true is released there may be only a
handful of people that begin running it while everyone else delays
their upgrade (with the very good reason of
not getting involved in politics) and a year later those handful of
people just become stuck at the moment of
MUST_SIGNAL, unable to mine new blocks?
> >
> > It is a possible outcome but the likely outcome is that miners
activate Taproot before LOT is even
relevant. I think it is prudent to prepare for the unlikely but
possible outcome that miners fail to activate
and hence have this discussion now rather than be unprepared for that
eventuality. If LOT is set to false in a
software release there is the possibility (T2 in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>)
of individuals or a
proportion of the community changing LOT to true. In that sense setting
LOT=false in a software release
appears to be no more safe than LOT=true.
> >
> > > The result: a wasted year of waiting and a minority of people who
didn't want to be lenient with miners
by default.
> >
> > There is the (unlikely but possible) possibility of a wasted year
if LOT is set to false and miners fail
to activate. I'm not convinced by this perception that LOT=true is
antagonistic to miners. I actually think it
offers them clarity on what will happen over a year time period and
removes the need for coordinated or
uncoordinated community UASF efforts on top of LOT=false.
> >
> > > An activation mechanism is a consensus change like any other
change, can be contentious like any other
change, and we must resolve it like any other change. Otherwise we risk
arriving at the darkest timeline.
> >
> > I don't know what you are recommending here to avoid "this darkest
timeline". Open discussions have
occurred and are continuing and in my mailing list post that you
responded to **I recommended we propose
LOT=false be set in protocol implementations such as Bitcoin Core**. I
do think this apocalyptic language
isn't particularly helpful. In an open consensus system discussion is
healthy, we should prepare for bad or
worst case scenarios in advance and doing so is not antagonistic or
destructive. Mining pools have pledged
support for Taproot but we don't build secure systems based on pledges
of support, we build them to minimize
trust in any human actors. We can be grateful that people like
Alejandro have worked hard on
taprootactivation.com <http://taprootactivation.com> (and this effort
has informed the discussion) without
taking pledges of support as cast iron guarantees.
> >
> > TL;DR It sounds like you agree with my recommendation to set
LOT=false in protocol implementations in my
email :)
> >
> > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces
<ariellua...@gmail.com
<mailto:ariellua...@gmail.com>> wrote:
> >
> > > Something what strikes me about the conversation is the emotion
surrounding the letters UASF.
> > > It appears as if people discuss UASF as if it's a massive tidal
wave of support that is inevitable, like
we saw during segwit activation. But the actual definition is "any
activation that is not a MASF".
> > > A UASF can consist of a single node, ten nodes, a thousand, half
of all nodes, all business' nodes, or
even all the non mining nodes. On another dimension it can have zero
mining support, 51% support, 49% support,
or any support right up against a miner activation threshold.
> > > Hell a UASF doesn't even need code or even a single node running
as long as it exists as a possibility
in people's minds.
> > > The only thing a UASF doesn't have is miner support above an
agreed activation threshold (some number
above %51).
> > > I say this because it strikes me when people say that they are
for LOT=true with the logic that since a
UASF is guaranteed to happen then it's better to just make it default
from the beginning. Words like
coordination and safety are sometimes sprinkled into the argument.
> > > The argument comes from a naive assumption that users MUST
upgrade to the choice that is submitted into
code. But in fact this isn't true and some voices in this discussion
need to be more humble about what users
must or must not run.
> > > Does no one realize that it is a very possible outcome that if
LOT=true is released there may be only a
handful of people that begin running it while everyone else delays
their upgrade (with the very good reason of
not getting involved in politics) and a year later those handful of
people just become stuck at the moment of
MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of
miners, activating, and forking off into a
minority fork. Then a lot=false could be started that ends up
activating the feature now that the stubborn
option has ran its course.
> > > The result: a wasted year of waiting and a minority of people who
didn't want to be lenient with miners
by default. The chains could be called BitcoinLenient and
BitcoinStubborn.
> > > How is that strictly safer or more coordinated?
> > > I may be in the minority, or maybe a silent majority, or maybe a
majority that just hasn't considered
this as a choice but honestly if there is contention about whether
we're going to be stubborn or lenient with
miners for Taproot and in the future then I prefer to just not activate
anything at all. I'm fine for calling
bitcoin ossified, accepting that segwit is Bitcoin's last network
upgrade. Taproot is amazing but no new
feature is worth a network split down the middle.
> > > Maybe in 10 or 20 years, when other blockchains implement
features like Taproot and many more, we will
become envious enough to put aside our differences on how to behave
towards miners and finally activate Taproot.
> > > An activation mechanism is a consensus change like any other
change, can be contentious like any other
change, and we must resolve it like any other change. Otherwise we risk
arriving at the darkest timeline.
> > > Cheers
> > > Ariel Lorenzo-Luaces
> > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> > >
> > > > Yesterday (February 16th) we held a second meeting on Taproot
> > > > activation on IRC which again was open to all. Despite what
appeared
> > > > to be majority support for LOT=false over LOT=true in the first
> > > > meeting I (and others) thought the arguments had not been
explored in
> > > > depth and that we should have a follow up meeting almost
entirely
> > > > focused on whether LOT (lockinontimeout) should be set to true
or
> > > > false.
> > > >
> > > > The meeting was announced here:
> > > >
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>
> > > >
> > > > In that mailing list post I outlined the arguments for LOT=true
(T1 to
> > > > T6) and arguments for LOT=false (F1 to F6) in their strongest
form I
> > > > could. David Harding responded with an additional argument for
> > > > LOT=false (F7) here:
> > > >
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>
> > > >
> > > > These meetings are very challenging given they are open to all,
you
> > > > don’t know who will attend and you don’t know most people’s
views in
> > > > advance. I tried to give time for both the LOT=true arguments
and the
> > > > LOT=false arguments to be discussed as I knew there was support
for
> > > > both. We only tried evaluating which had more support and which
had
> > > > more strong opposition towards the end of the meeting.
> > > >
> > > > The conversation log is here:
> > > > http://gnusha.org/taproot-activation/2021-02-16.log
<http://gnusha.org/taproot-activation/2021-02-16.log>
> > > >
> > > > (If you are so inclined you can watch a video of the meeting
here.
> > > > Thanks to the YouTube account “Bitcoin” for setting up the
livestream:
> > > > https://www.youtube.com/watch?v=vpl5q1ovMLM
<https://www.youtube.com/watch?v=vpl5q1ovMLM>)
> > > >
> > > > A summary of the meeting was provided by Luke Dashjr on
Mastodon here:
> > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
<https://bitcoinhackers.org/@lukedashjr/105742918779234566>
> > > >
> > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive,
but we
> > > > did manage to come to consensus on everything but
LockinOnTimeout.
> > > >
> > > > Activation height range: 693504-745920
> > > >
> > > > MASF threshold: 1815/2016 blocks (90%)
> > > >
> > > > Keep in mind only ~100 people showed for the meetings, hardly
> > > > representative of the entire community.
> > > >
> > > > So, these details remain JUST a proposal for now.
> > > >
> > > > It seems inevitable that there won't be consensus on LOT.
> > > >
> > > > Everyone will have to choose for himself. :/
> > > >
> > > > Personally I agree with most of this. I agree that there wasn’t
> > > > overwhelming consensus for either LOT=true or LOT=false.
However, from
> > > > my perspective there was clearly more strong opposition (what
would
> > > > usually be deemed a NACK in Bitcoin Core review terminology)
from
> > > > Bitcoin Core contributors, Lightning developers and other
community
> > > > members against LOT=true than there was for LOT=false. Andrew
Chow
> > > > tried to summarize views from the meeting in this analysis:
> > > >
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
<https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>
> > > >
> > > > I am also aware of other current and previous Bitcoin Core
> > > > contributors and Lightning developers who didn’t attend the
meeting in
> > > > person who are opposed to LOT=true. I don’t want to put them in
the
> > > > spotlight for no reason but if you go through the conversation
logs of
> > > > not only the meeting but the weeks of discussion prior to this
meeting
> > > > you will see their views evaluated on the ##taproot-activation
> > > > channel. In addition, on taprootactivation.com
<http://taprootactivation.com> some mining pools
> > > > expressed a preference for lot=false though I don’t know how
strong
> > > > that preference was.
> > > >
> > > > I am only one voice but it is my 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.
> > > > Any further delay appears to me counterproductive in our
collective
> > > > aim to get the Taproot soft fork activated as early as possible.
> > > >
> > > > Obviously others are free to disagree with that assessment and
> > > > continue discussions but personally I will be attempting to
avoid
> > > > those discussions unless prominent new information comes to
light or
> > > > various specific individuals change their minds.
> > > >
> > > > Next week we are planning a code review of the Bitcoin Core PR
#19573
> > > > which was initially delayed because of this LOT discussion. As
I’ve
> > > > said previously that will be loosely following the format of the
> > > > Bitcoin Core PR review club and will be lower level and more
> > > > technical. That is planned for Tuesday February 23rd at 19:00
UTC on
> > > > the IRC channel ##taproot-activation.
> > > >
> > > > Thanks to the meeting participants (and those who joined the
> > > > discussion on the channel prior and post the meeting) for
engaging
> > > > productively and in good faith.
> >
> > --
> > Michael Folkson
> > Email: michaelfolk...@gmail.com <mailto:michaelfolk...@gmail.com>
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Michael Folkson
Email: michaelfolk...@gmail.com <mailto:michaelfolk...@gmail.com>
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
