You say "short term PR", I say "risking millions of user dollars".

On 2/18/21 09:51, Michael Folkson wrote:
> getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an exchange losing millions would be worse than having Taproot is good.

We are at the point where an upgrade that confers significant long term benefits for the whole ecosystem is not as important as bad short term PR? That is a depressing outlook if that is what you believe.

Even in that worst case scenario exchanges should not lose money if they are 
competent and are able to manage that risk.

On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo <lf-li...@mattcorallo.com 
<mailto:lf-li...@mattcorallo.com>> wrote:

    We've had several softforks in Bitcoin which, through the course of their 
activation, had a several-block reorg. That
    should be indication enough that we need to very carefully consider 
activation to ensure we reduce the risk of that as
    much as absolutely possible. Again, while I think Taproot is a huge 
improvement and am looking forward to being able to
    use it, getting unlucky and hitting a 4-block reorg that happens to include 
a double-spend and some PR around an
    exchange losing millions would be worse than having Taproot is good.

    Matt

    On 2/18/21 09:26, Michael Folkson wrote:
     > Thanks for your response Matt. It is a fair challenge. There is always 
going to be an element of risk with soft
    forks,
     > all we can do is attempt to minimize that risk. I would argue that risk 
has been minimized for Taproot.
     >
     > You know (better than I do in fact) that Bitcoin (and layers built on 
top of it) greatly benefit from upgrades
    such as
     > Taproot. To say we shouldn't do Taproot or any future soft forks because 
there is a small but real risk of chain
    splits
     > I think is shortsighted. Indeed I think even if we collectively decided 
not to do any future soft fork upgrades ever
     > again on this mailing list that wouldn't stop soft fork attempts from 
other people in future.
     >
     > I don't think there is anything else we can do to minimize that risk for 
the Taproot soft fork at this point
    though I'm
     > open to ideas. To reiterate that risk will never be zero. I don't think 
I see Bitcoin as fragile as you seem to
    (though
     > admittedly you have a much better understanding than me of what happened 
in 2017).
     >
     > The likely scenario for the Taproot soft fork is LOT turns out to be 
entirely irrelevant and miners activate Taproot
     > before it becomes relevant. And even the unlikely worst case scenario 
would only cause short term disruption and
     > wouldn't kill Bitcoin long term.
     >
     > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-li...@mattcorallo.com 
<mailto:lf-li...@mattcorallo.com>
    <mailto:lf-li...@mattcorallo.com <mailto:lf-li...@mattcorallo.com>>> wrote:
     >
     >     If the eventual outcome is that different implementations (that have 
material *transaction processing* userbases,
     >     and I’m not sure to what extent that’s true with Knots) ship 
different consensus rules, we should stop here
    and not
     >     activate Taproot. Seriously.
     >
     >     Bitcoin is a consensus system. The absolute worst outcome at all 
possible is to have it fall out of consensus.
     >
     >     Matt
     >
     >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org
    <mailto:bitcoin-dev@lists.linuxfoundation.org>
     >>     <mailto: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>
    <mailto: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>
     >>         <mailto: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>
     >>         
<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> 
<http://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>
     >>         <mailto: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>
     >>         <mailto: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>
     >>         
<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>
     >>         
<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> 
<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>
    <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>
     >>         <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>
     >>         
<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>
    <http://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> <mailto: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>
    <mailto: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>
     >>         <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> 
<mailto: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>
    <mailto: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>
     >>     <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> 
<mailto:michaelfolk...@gmail.com
    <mailto:michaelfolk...@gmail.com>>
     > Keybase: michaelfolkson
     > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3



--
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to