Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

Hi Pieter,

Addressing your comments:

>> Thank you very much for all the clarifications; it’s good to have them 
>> sorted out and clearly structured. From what you wrote it follows that we 
>> still need to reserve a dedicated purpose (with new BIP) for BIP340 
>> signatures to avoid key reuse, am I right?
> 
> Maybe, but it would be for a particular way of using keys (presumably: 
> single-key pay-to-taproot), not just the signature scheme itself. If you go 
> down this path you'll also want dedicated branches for multisig 
> participation, and presumably several interesting new policies that become 
> possible with Taproot.

Yes, previously we had a dedicated standards (BIPs) for purpose fields on each 
variant: single-sig, multi-sig etc. With this proposal I simplify this: you 
will have a dedicated deterministically-derived *hardened* keys for each use 
case under single standard, which should simplify future wallet implementations.


> And as I said, dedicated branches only help for the simple case. For example, 
> it doesn't address the more general problem of preventing reuse of keys in 
> multiple distinct groups of multisig sets you participate in. If you want to 
> solve that you need to keep track of  index is for participating in what - 
> and once you have something like that you don't need dedicated purpose based 
> derivation at all anymore.

In the BIP proposal there is a part on how multisigs can be created in a simple 
and deterministic way without keys reuse.


> So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for 
> single-key P2TR (and probably many other useful ways of using taproot based 
> spending policies...). But perhaps it's useful to have.

My proposal is to have a new purpose field supporting all the above: hardened 
derivation that supports for multisigs, single-sigs etc.


Kind regards,
Maxim


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

[Dr Maxim Orlovsky via bitcoin-dev]

Hi Adam,

Commenting on your question:

> With segWit vs pre-SegWit didn't wallets just select and standardize
> on a different HD derivation path?
> 
> Is there something else needed than a Schnorr derivation path?

The general accepted practice (defined in BIP43) is to define a dedicated 
purpose field for each kind of key derivation and address encoding. There is a 
dedicated purpose for pre-SegWit, SegWit, multisigs — and now a purpose for 
Schnorr sigs/Taproot outputs is needed. That is why I brought forward this 
proposal, which addresses exactly this need - and also will support at the same 
time multisigs and pre-Taproot outputs, making all previously used purpose 
fields redundant, simplifying future wallets.

Kind regards,
Maxim
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson via bitcoin-dev]

> 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 
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  > 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
> >> > 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  > 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  >> > wrote:
> >> >
> >>

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Keagan McClelland via bitcoin-dev]

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> 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  > 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.
> >
> >   

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson via bitcoin-dev]

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 
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> 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  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> 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)
>> of individuals or a proportion 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo via bitcoin-dev]

This is absolutely the case, however note that the activation method itself is consensus code which executes as a part 
of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should 
be designed, this doesn't imply anything about the consensus code which represents the activation thereof.


Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one 
which almost certainly carries significantly more risk than Taproot.


Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have 
various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are 
OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority 
of Bitcoin users and is only not activating due to lagging miner upgrades.


Matt

On 2/18/21 10:04, Keagan McClelland wrote:

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 > 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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo via bitcoin-dev]

To ensure we're on the same page, here - I'm not advocating we give up on Taproot. Indeed, without having dug deep into 
the issue, my overall impression is that Knots has a tiny transaction-processing userbase and it likely isn't worth 
giving deep thought to whether it forks itself off from the network or not. My point is that, if it were the case that 
various implementations of Bitcoin's consensus that have material userbases were to release either a configurable 
consensus mechanism (without incredible care being given to it, not just a "we can't decide, whatever" argument) or a 
different consensus, we'd be much, much better off not having Taproot at all.


Matt

On 2/18/21 09:53, Matt Corallo via bitcoin-dev wrote:

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 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 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 
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, 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo via bitcoin-dev]

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 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 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 
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 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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo via bitcoin-dev]

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 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 
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 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 
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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo via bitcoin-dev]

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 
>  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  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 
>> >  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)
>> > >  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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Matt Corallo via bitcoin-dev]

Bitcoin is a consensus system. Please let’s not jump to (or even consider) 
options that discourage consensus. We all laughed at (and later academics 
researched showed severe deficiencies in) Bitcoin XT’s “emergent consensus” 
nonsense, why should we start doing things along that line in Bitcoin?

(Resent from the correct email)

Matt

> On Feb 18, 2021, at 06:52, ZmnSCPxj via bitcoin-dev 
>  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 
>>>  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)
>>>  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 (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 
  wrote:
>>> 
 Something 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson via bitcoin-dev]

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  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> 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)
> 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 (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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[ZmnSCPxj via bitcoin-dev]

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 
>  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)
> >  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 (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 
> >  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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Samson Mow via bitcoin-dev]

 "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.


On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <
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)
> 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 (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> 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 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Michael Folkson via bitcoin-dev]

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)
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 (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 
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
> 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces via bitcoin-dev]

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, 7:05 AM, at 7:05 AM, Michael Folkson via bitcoin-dev 
 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
>
>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
>
>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
>
>(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)
>
>A summary of the meeting was provided by Luke Dashjr on Mastodon here:
>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: