Hi all,
I think it's important for us to consider what is actually being considered for
activation here.
The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
that script version today. This is something I think that we can easily check by digging through the UTXO set or
history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
can't switch to a script version that no one is actually using.
If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
because there is simply no block that contains a transaction that only some of the network will accept.
Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
(which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
meet. I can't imagine a less intrusive change.
On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
missing something please say so. But from my point of view, we can't treat all soft forks as equal.
Keagan
On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>> 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
_______________________________________________
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>
