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

[Ariel Lorenzo-Luaces via bitcoin-dev]

I agree.

Thank you Erik for proposing it. It's a pretty good idea.

P.S. I wouldn't want a chain split of a low percentage of users though. The 
minority will be at the mercy of massive PoW swings and the chain will lose 
friends so it's not good for anyone. I recommend changing the final percentage 
to %50 because that's the hurdle where non-upgraded users *must* activate to 
avoid the risk of being reorged. The number of running users will quickly jump 
to 90%+ if it ever gets near 50%.

Cheers
Ariel Lorenzo-Luaces



On Mar 1, 2021, 5:54 AM, at 5:54 AM, Erik Aronesty  wrote:
>> Today users should start cooperating again to continue using the
>> optimal strategy.
>
>the "gradual" method of reducing the % of miners required for lock-in
>as time goes on seems to encode this optimal strategy.
>
>On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
> wrote:
>>
>> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>>  wrote:
>> >
>> > If social consensus is what drives technical consensus and not the
>other way around it seems as if there cannot exist a valid (rational?)
>reason to oppose Taproot itself, and then by extension with the
>arguments laid out above, LOT=true seems to be the logical conclusion
>of all of this, even if Core ships LOT=false at the outset.
>> >
>> > Where am I wrong here?
>> >
>> > Keagan
>> >
>> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev
> wrote:
>> >>
>> >> Personally, I think with either plan the ultimate risk of forking
>is low given probability to activate before timeout, so we should just
>pick something and move on, accepting that we aren't setting a
>precedent by which all future forks should abide. Given my
>understanding of the tradeoffs, I believe that the safest choice is
>LOT=true, but I wouldn't move to hold back a plan of LOT=false (but
>would probably take mitigative steps on community advocacy if it looks
>like there is non majority but non negligible LOT=true uptake).
>> >>
>> >> Cheers,
>> >>
>> >> Jeremy
>> >>
>> >>
>> >> ___
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> > ___
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> To favor LOT=true because it seems like the inevitable result is like
>> playing the prisoner's dilemma and never cooperating instead of using
>> the most optimal strategy which is tit-for-tat (cooperating at first
>> and then cheating once for every time your counterparty cheats).
>>
>> During segwit users started by cooperating (BIP9, or "LOT=false"),
>> then a minority of
>> miners didn't cooperate (small veto but remember the majority of
>> miners cooperated), then users stopped cooperating in response
>(UASF),
>> then miners
>> reverted to cooperating (MASF while intolerant miners forked off).
>> Today users should start cooperating again to continue using the
>> optimal strategy.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
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)

[Erik Aronesty via bitcoin-dev]

> Today users should start cooperating again to continue using the
> optimal strategy.

the "gradual" method of reducing the % of miners required for lock-in
as time goes on seems to encode this optimal strategy.

On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
 wrote:
>
> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>  wrote:
> >
> > If social consensus is what drives technical consensus and not the other 
> > way around it seems as if there cannot exist a valid (rational?) reason to 
> > oppose Taproot itself, and then by extension with the arguments laid out 
> > above, LOT=true seems to be the logical conclusion of all of this, even if 
> > Core ships LOT=false at the outset.
> >
> > Where am I wrong here?
> >
> > Keagan
> >
> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev 
> >  wrote:
> >>
> >> Personally, I think with either plan the ultimate risk of forking is low 
> >> given probability to activate before timeout, so we should just pick 
> >> something and move on, accepting that we aren't setting a precedent by 
> >> which all future forks should abide. Given my understanding of the 
> >> tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't 
> >> move to hold back a plan of LOT=false (but would probably take mitigative 
> >> steps on community advocacy if it looks like there is non majority but non 
> >> negligible LOT=true uptake).
> >>
> >> Cheers,
> >>
> >> Jeremy
> >>
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> To favor LOT=true because it seems like the inevitable result is like
> playing the prisoner's dilemma and never cooperating instead of using
> the most optimal strategy which is tit-for-tat (cooperating at first
> and then cheating once for every time your counterparty cheats).
>
> During segwit users started by cooperating (BIP9, or "LOT=false"),
> then a minority of
> miners didn't cooperate (small veto but remember the majority of
> miners cooperated), then users stopped cooperating in response (UASF),
> then miners
> reverted to cooperating (MASF while intolerant miners forked off).
> Today users should start cooperating again to continue using the
> optimal strategy.
>
> Cheers
> Ariel Lorenzo-Luaces
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
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)

[Ariel Luaces via bitcoin-dev]

On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
 wrote:
>
> If social consensus is what drives technical consensus and not the other way 
> around it seems as if there cannot exist a valid (rational?) reason to oppose 
> Taproot itself, and then by extension with the arguments laid out above, 
> LOT=true seems to be the logical conclusion of all of this, even if Core 
> ships LOT=false at the outset.
>
> Where am I wrong here?
>
> Keagan
>
> On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev 
>  wrote:
>>
>> Personally, I think with either plan the ultimate risk of forking is low 
>> given probability to activate before timeout, so we should just pick 
>> something and move on, accepting that we aren't setting a precedent by which 
>> all future forks should abide. Given my understanding of the tradeoffs, I 
>> believe that the safest choice is LOT=true, but I wouldn't move to hold back 
>> a plan of LOT=false (but would probably take mitigative steps on community 
>> advocacy if it looks like there is non majority but non negligible LOT=true 
>> uptake).
>>
>> Cheers,
>>
>> Jeremy
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

To favor LOT=true because it seems like the inevitable result is like
playing the prisoner's dilemma and never cooperating instead of using
the most optimal strategy which is tit-for-tat (cooperating at first
and then cheating once for every time your counterparty cheats).

During segwit users started by cooperating (BIP9, or "LOT=false"),
then a minority of
miners didn't cooperate (small veto but remember the majority of
miners cooperated), then users stopped cooperating in response (UASF),
then miners
reverted to cooperating (MASF while intolerant miners forked off).
Today users should start cooperating again to continue using the
optimal strategy.

Cheers
Ariel Lorenzo-Luaces
___
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)

[Anthony Towns via bitcoin-dev]

On Mon, Feb 22, 2021 at 06:10:34PM -0800, Jeremy via bitcoin-dev wrote:
> Not responding to anyone in particular, but it strikes me that one can think
> about the case where a small minority (let's say H = 20%?) of nodes

I don't think that's a good way to try to look at things -- number of
nodes has some impacts, but they're relatively minor (pun deflected).

I think the things to look at are (from most to least important):

 (1) what the price indicates / what people buying/selling BTC want
 (2) what hashpower does
 (3) what nodes do

Here's a concrete example to help justify that ordering. Suppose
that for whatever reason nobody is particularly interested in running
lockinontimeout=true -- only 0.1% of nodes are doing it and they're not
the "economic majority" in any way. In addition, 15% of hashpower have
spent almost the entire signalling period not bothering to upgrade and
thus haven't been signalling and have been blocking activation.

Suppose further that there are futures/prediction markets setup so that
people can bet on taproot activation (eg the bitfinex chain split tokens,
or some sort of DeFi contracts), and the result is that there's some
decent profits to be made if it does activate, enough to tempt >55%
of hashpower into running with lockinontimeout=true. That way those
miners can be confident it will activate, take up contracts in the
futures/predictions markets, and be confident they'll win and get a
big payday. (Note that this means the people on the other side of those
contracts are betting that taproot *doesn't* activate)

Once a majority of hashpower is running lockinontimeout=true, it then
makes sense for the remaining hashpower to both signal for activation
and also run lockinontimeout=true -- otherwise they risk their blocks
being orphaned if too many blocks don't signal, and they build on top
of one.  Figuring out that a majority of hashpower is/will be running
lockinontimeout=true can be done either by a coinbase message or by
bip91-style signalling.

In that scenario, you end up with >90% of hashpower running with
lockinontimeout=true, even if only a token number of nodes in the wild
are doing the same.



It's possible to do estimates of what happens if a majority of miners
are using lockinontimeout=true, and the numbers end up pretty wild.

With 90% of miners signalling and running lockinontimeout=true, if the
remaining 10% don't signal, they can expect to lose around 3% of revenue
($2M) due to blocks getting orphaned. If the numbers are 85% running
lockinontimeout=true, and 15% not signalling, the non-signallers can
expect to lose about 37% of revenue ($38M) during the retarget period
prior to timeout. If 60% of miners are doing spy-mining for up to 90s,
they would expect to lose 0.9% of their spy-mining revenue ($2.5M). If
60% of hashpower is running lockinontimeout=true, while 40% don't
signal, the non-signallers will forego ~83% of revenue ($320M) due to
their blocks being orphaned, and if 60% of miners spy-mine for 90s, they
should expect to lose 5% of revenue ($10M) over the same period. Dollar
figures based on 6.25BTC/block at $50k per BTC.

https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-forced_signalling_chaos_cost_sim-py

Note that if miners simply accept those losses and don't take any
action to prevent it, very long reorgs are to be expected -- in the 15%
non-signalling scenario, you'd expect to see a 5-block reorg; in the 40%
non-signalling scenario, you'd get reorgs of 60+ blocks. (Only people
not running lockinontimeout=true would see the blocks being reorged out,
of course)


So I think focussing on how many nodes have a particular lockinontimeout
setting can be pretty misleading.

> # 80% on LOT=false, 20% LOT=True
> - Case 1: Activates ahead of time anyways

That's the case where >90% of hashpower is signalling, and everything
works fine.

> - Case 2: Fails to Activate before timeout...
> 20% *may* fork off with LOT=true.

Anyone running with lockinontimeout=true will refuse to follow a chain
where lockin hasn't been reached by the timeout height; so if the most
work chain meets that condition, lockinontimeout=true nodes will refuse
to follow it; either getting stuck with no confirmations at all, or
following a lower work chain that does (or can) reach lockin by timeout
height.

> Bitcoin hashrate reduced, chance of multi
> block reorgs at time of fork relatively high, especially if network does not
> partition.

If the most-work chain fails to activate, and only a minority of
hashrate is running lockinontimeout=true, the chance of multiblock
reorgs is actually pretty low. The way it would play out in detail,
with say 20% of hashpower not signalling and 40% of hashpower running
lockinontimeout=true:

  * the chain reaches the last retarget period; lockinontimeout=false
nodes stay in STARTED, lockinontimeout=true nodes switch to
MUST_SIGNAL

  * for the first ~1009 blocks, everyone stays in sync, but block ~1010
becomes the 

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

[Ben Woosley via bitcoin-dev]

Relative to your arguments, Keagan and Jeremy, and speaking in favor of
LOT=false, from my limited perspective:

> As Jeremy points out, the LOT=true possibility always exists here, and we
have multiple high profile people saying they will be running that
regardless of how things turn out. It seems to me that in this scenario,
LOT=false does less to prevent a chain split.
> So if the goal is to prevent a chain split, and the soft fork is benign
and essentially "annexing unoccupied territory" with respect to script
versions, and no one actually has opposed Taproot itself, then I fail to
see how LOT=false is safer in the presence of a grenade defense by the
LOT=true crowd.

I don't believe the goal is to avoid a chain split, nor to activate
Taproot. Over the long term it will not have been important when exactly
Taproot activated, or whether a minority forked off, but what culture and
norms we adopted in putting forward this change. A culture of deference to
the network makes Core worthy of remaining the reference implementation of
Bitcoin.

Given Core's special position in the client ecosystem, I see these outcomes
are asymmetric:
a) If an intolerant minority signals LOT=true in contradiction to core,
they are splitting consensus / forking off consensus, which is their right
to do in our open ecosystem.
b) If Core ships LOT=true, we are in fact imposing a change on the network.
This may be justified in the end, but it should be used with discretion.

If LOT=false fails to activate, then the failure will have revealed
information about sentiments and elements of the network, and we will have
an opportunity then to address that information before proceeding with
LOT=true.

To adopt b) as a pre-emptive defense against a) is to express will without
evidence of necessity or opportunity for justification.

Finally, as others have said, I think this option is likely to be moot -
let's not act defensively out of SEGWIT trauma, but with trust in the
network.

Best,
Ben

On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I wanted to follow up on what Jeremy and others are saying regards finding
> consensus on LOT. I've seen a few other opinions saying that finding
> consensus on the LOT value is far more important than what the LOT value
> actually is. This makes sense because if 100% of economic activity is
> running the same rule set, there is no divergence, regardless of which
> value is picked.
>
> It is my understanding that those who oppose LOT=true are mostly opposed
> on the grounds of it *appearing* "unnecessarily coercive" and that this
> lack of consensus can precipitate a chain split at the
> "brinksmanship period" as Jeremy refers to it. I don't think that we can
> say that LOT=true is coercive at all unless there is some opposition to
> Taproot itself. Opposition on the grounds that it *may* be opposed by
> others and Core does not want to assert control over the protocol is a
> conservative view but ultimately contingent upon opposition to Taproot for
> more fundamental reasons. If no one opposes it, then by definition you have
> consensus, and in that case I also don't think that the LOT=true (or false)
> in that regard sets meaningful precedent, as I would expect precedents to
> only be meaningful if they were established during a contentious scenario.
> As it stands we have precedents for both MASF's and UASF's to execute soft
> forks in Bitcoin.
>
> Of course it seems intractable to ascertain the views of ~100% of the
> Bitcoin constituency, and therefore it gives credibility to the argument
> that by coming to consensus on LOT=false among those who *are* speaking
> up is safer with the embedded assumptions that modifying consensus beyond
> what core ships is an active choice, presumably by those who know what they
> are doing. However, the simple act of Core choosing to ship an
> unconfigurable LOT=false value does not *prevent* the forking and
> creation of a UASF client. As Jeremy points out, the LOT=true possibility
> always exists here, and we have multiple high profile people saying they
> will be running that regardless of how things turn out. It seems to me that
> in this scenario, LOT=false does less to prevent a chain split.
>
> In regards to precedent, there may be good reasons to force that minority
> to fork themselves off the network, as would be the case if a hypothetical
> soft fork was a consensus action to blacklist some UTXO's or something else
> that weaponizes consensus against some subset of Bitcoin's user base, but I
> haven't heard a single person who advocates for LOT=false on the grounds
> that they *themselves* oppose the consensus change that is being proposed
> here. So if the goal is to prevent a chain split, and the soft fork is
> benign and essentially "annexing unoccupied territory" with respect to
> script versions, and no one actually has opposed Taproot itself, then I
> fail to see how LOT=false 

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

[Keagan McClelland via bitcoin-dev]

I wanted to follow up on what Jeremy and others are saying regards finding
consensus on LOT. I've seen a few other opinions saying that finding
consensus on the LOT value is far more important than what the LOT value
actually is. This makes sense because if 100% of economic activity is
running the same rule set, there is no divergence, regardless of which
value is picked.

It is my understanding that those who oppose LOT=true are mostly opposed on
the grounds of it *appearing* "unnecessarily coercive" and that this lack
of consensus can precipitate a chain split at the "brinksmanship period" as
Jeremy refers to it. I don't think that we can say that LOT=true is
coercive at all unless there is some opposition to Taproot itself.
Opposition on the grounds that it *may* be opposed by others and Core does
not want to assert control over the protocol is a conservative view but
ultimately contingent upon opposition to Taproot for more fundamental
reasons. If no one opposes it, then by definition you have consensus, and
in that case I also don't think that the LOT=true (or false) in that regard
sets meaningful precedent, as I would expect precedents to only be
meaningful if they were established during a contentious scenario. As it
stands we have precedents for both MASF's and UASF's to execute soft forks
in Bitcoin.

Of course it seems intractable to ascertain the views of ~100% of the
Bitcoin constituency, and therefore it gives credibility to the argument
that by coming to consensus on LOT=false among those who *are* speaking up
is safer with the embedded assumptions that modifying consensus beyond what
core ships is an active choice, presumably by those who know what they are
doing. However, the simple act of Core choosing to ship an unconfigurable
LOT=false value does not *prevent* the forking and creation of a UASF
client. As Jeremy points out, the LOT=true possibility always exists here,
and we have multiple high profile people saying they will be running that
regardless of how things turn out. It seems to me that in this scenario,
LOT=false does less to prevent a chain split.

In regards to precedent, there may be good reasons to force that minority
to fork themselves off the network, as would be the case if a hypothetical
soft fork was a consensus action to blacklist some UTXO's or something else
that weaponizes consensus against some subset of Bitcoin's user base, but I
haven't heard a single person who advocates for LOT=false on the grounds
that they *themselves* oppose the consensus change that is being proposed
here. So if the goal is to prevent a chain split, and the soft fork is
benign and essentially "annexing unoccupied territory" with respect to
script versions, and no one actually has opposed Taproot itself, then I
fail to see how LOT=false is safer in the presence of a grenade defense by
the LOT=true crowd.

I personally *prefer* LOT=true for these reasons, but I am NOT going to be
joining the ranks of the intolerant minority if Core ultimately ships
LOT=false. I think it is more important to stay in consensus, and as a
result I am able to be convinced that false is the right answer. My
question to everyone else (true AND false advocates) is this: what would
you have to observe, in order to change your mind or is it immutably made
up? If we have a significant portion of the community that is immutably
made up to go false, and another portion that is going to go true, the
asymmetry of the fork almost *requires* that those of us whose opinions are
malleable to break for true.

If social consensus is what drives technical consensus and not the other
way around it seems as if there cannot exist a valid (rational?) reason to
oppose Taproot itself, and then by extension with the arguments laid out
above, LOT=true seems to be the logical conclusion of all of this, even if
Core ships LOT=false at the outset.

Where am I wrong here?

Keagan

On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not responding to anyone in particular, but it strikes me that one can
> think about the case where a small minority (let's say H = 20%?) of nodes
> select the opposite of what Core releases (LOT=false, LOT=true). I'm
> ignoring the case where a critical bug is discovered in Taproot for reasons
> I could expand on if anyone is interested (I don't think LOT=true/false has
> much of a diff in that regard).
>
> You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes
> are clearly updated (or lying), LOT=false nodes may be un-upgraded (or
> however you want to interpret it).
>
>
> *# 80% on LOT=false, 20% LOT=True*
>
> - Case 1: Activates ahead of time anyways
>
> No issues.
>
> - Case 2: Fails to Activate before timeout...
>
> 20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of
> multi block reorgs at time of fork relatively high, especially if network
> does not partition.
>
> Implication is that activation % being 90%, then X% 

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

[Jeremy via bitcoin-dev]

Not responding to anyone in particular, but it strikes me that one can
think about the case where a small minority (let's say H = 20%?) of nodes
select the opposite of what Core releases (LOT=false, LOT=true). I'm
ignoring the case where a critical bug is discovered in Taproot for reasons
I could expand on if anyone is interested (I don't think LOT=true/false has
much of a diff in that regard).

You'll note an asymmetry with LOT=true / false analysis. LOT=true nodes are
clearly updated (or lying), LOT=false nodes may be un-upgraded (or however
you want to interpret it).


*# 80% on LOT=false, 20% LOT=True*

- Case 1: Activates ahead of time anyways

No issues.

- Case 2: Fails to Activate before timeout...

20% *may* fork off with LOT=true. Bitcoin hashrate reduced, chance of multi
block reorgs at time of fork relatively high, especially if network does
not partition.

Implication is that activation % being 90%, then X% fewer than 70% of
miners are signaling for Taproot at this time.  If X% is small the
increased orphan rate caused by the LOT=true miners will cause it to
activate anyways. If X% is larger, then there will be a consensus split.



*# 80% on LOT=true, 20% LOT=False*
- Case 1: Activates ahead of time Anyways

No issues.

- Case 2: Fails to Activate before timeout...

A% + B% + C% = 20%

A% (upgraded, signal activate) remain on majority chain with LOT=false,
blocks mined universally valid.

B% (upgraded, not signaling) succeeds in activating and maintaining
consensus, blocks are temporarily lost during the final period, but
consensus re-emerges.

C% (not upgraded/not signalling) both fail to activate (not upgraded) and
blocks are rejected (not signaling) during mandatory signalling.
Essentially becomes an SPV miner, should still not select transactions
improperly given mempool policy, but may mine a bad tip.

(I argue that group B is irrational entirely, as in this case the majority
has upgraded, inevitably winning, and is orphaning their blocks so B should
effectively be 0% or can be combined with group C as being somehow not
upgraded if they are unable to switch once it becomes clear after say the
first 100 blocks in the period that LOT > 50%. The only difference in
lumping B with C is that group C SPV mines after the fork and B should, in
theory, have full validation.).



Apologies if my base analysis is off -- happy to take corrections.


My overall summary is thus:

1) People care what Core releases because we assume the majority will
likely run it. If core were a minority project, we wouldn't really care
what core released.
2) People are upset with LOT=true being suggested as release parameters
because of the *narrative* that it puts devs in control.
3) LOT=true having a sizeable minority running it presents major issues to
majority LOT=false in terms of lost blocks during the final period and in
terms of a longer term fork.
4) Majority LOT=true has no long term instability on consensus (majority
LOT=true means the final period always activates, any instability is short
lived + irrational).
5) On the balance, the safer parameter to release *seems* to be LOT=true.
But because devs are sensitive to control narrative, LOT=false is preferred
by devs.
6) Almost paradoxically, choosing a *less safe* option for a narrative
reason is more of a show of dev control than choosing a more safe option
despite appearances.
7) This all comes down to if we think that a reasonable number of important
nodes will run LOT=true.
8) This all doesn't matter *that much* because taproot will have many
opportunities to activate before the brinksmanship period.

As a plan of action, I think that means that either:

A) Core should release LOT=true, as a less disruptive option given stated
community intentions to do LOT=true
B) Core  community should vehemently anti-advocate running LOT=true to
ensure the % is as small as possible
C) Do nothing
D) Core community should release LOT=false and vehemently advocate manually
changing to LOT=true to ensure the % is supermajority, but leaving it as a
user choice.


Overall, I worry that plan B has a mild Streissand effect and would result
in boosting LOT=true (which could be OK, so long as LOT=true +
LOT=false+signal yes becomes the large majority, but would be not fun for
anyone if LOT=true + LOT=false+signal yes are a small majority). Plan C
most likely ends up with some % doing LOT=true anyways. D feels a little
silly, but maybe a good tradeoff.

If I had to summarize the emotional dynamic among developers around
LOT=true, I think devs wish it didn't exist because it is clear LOT=true
*creates* the issues here. LOT=false would be fine if the LOT=true strategy
didn't exist at all. But unfortunately the cat is out of the bag and cannot
be put back in. To validate the emotions, I think it is fine to be angry
about LOT=true and not like it, but we should either accept that it is most
likely to create consensus OR we should find a new game theoretic
activation strategy with 

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

[Jorge Timón via bitcoin-dev]

Just to clarify, I'm not saying bitcoin core should maintain the
"oppose proposal" part of the software. presumably people opposing the
change don't want much of the recent software changes anyway.
But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
I don't expect anyone to want this, but if people want it I offer
myself to code it,
I mean, just imagine that a day after publishing a bitcoin core
release with activation software for taproot some one, let's say in
New York reach an Agreement to "just use the same activation
mechanism, but for our 32 mb hardfork, it's about time, now computers
are 64 bits anyway". How convenient would it be to just cancel that
with 2 lines in bitcoin core?
Not that I think it will be necessary, but perhaps we want it just in case.

On Mon, Feb 22, 2021 at 5:31 PM Jorge Timón  wrote:
>
> Sorry, I haven't read everything. I just want to say what I think is
> the best option and why.
> Let's say something like 2 years in which miners can signal activation
> after which, the MUST signal it for their blocks to be valid (I think
> this is LOT=true, but I don't remember what LOT stands for).
> Some may argue than it's easier to move from LOT=false to LOT=true
> than viceversa (I think I'm getting this right), but either way
> different clients could interpret things more differently more easily
> and, you know, that's really bad.
> If anyone is against the consensus change itself, what they should do
> is run a client in which the must is turned into a MUST NOT. Whenever
> miners signal activation, blocks aren't valid so that it doesn't
> happen.
> That way both sides can be cleanly separated and both communities
> (assuming there's a community of users opposing the change) can stick
> together with their own in the same chain. That is, having only 2
> chains in total if there are users opposing the change or only one if
> not, but never 2 chains for people who want the change or 2 chains for
> pople who don't want it.
>
> Just my two sats, please nobody ask me "why would anyone oppose
> taproot?" or anything similar. Because I'm trying to generalize here,
> if we're talking about activation, I think the specifics of the change
> are kind of irrelevant.
>
> Separately: thanks to everyone who worked on taproot.
>
>
> On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
>  wrote:
> >
> >
> >
> > On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
> >
> > If a lockinontimeout=true node is requesting compact blocks from a
> > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> > I think that could result in a ban.
> >
> > More importantly, nodes on both sides of the fork need to find each other.
> >
> >
> > (If there was going to be an ongoing fork there'd be bigger things to
> > worry about...)
> >
> >
> > I think it should be clear that a UASF-style command line option to allow 
> > consensus rule changes in the node in the short term, immediately before a 
> > fork carries some risk of a fork, even if I agree it may not persist over 
> > months. We can’t simply ignore that.
> >
> > I think the important specific case of this is something like "if a chain
> > where taproot is impossible to activate is temporarily the most work,
> > miners with lockinontimeout=true need to be well connected so they don't
> > end up competing with each other while they're catching back up".
> >
> >
> > Between this and your above point, I think we probably agree - there is 
> > material  technical complexity hiding behind a “change the consensus rules“ 
> > option. Given it’s not a critical feature by any means, putting resources 
> > into fixing these issues probably isn’t worth it.
> >
> > Matt
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
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)

[Jorge Timón via bitcoin-dev]

Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
Some may argue than it's easier to move from LOT=false to LOT=true
than viceversa (I think I'm getting this right), but either way
different clients could interpret things more differently more easily
and, you know, that's really bad.
If anyone is against the consensus change itself, what they should do
is run a client in which the must is turned into a MUST NOT. Whenever
miners signal activation, blocks aren't valid so that it doesn't
happen.
That way both sides can be cleanly separated and both communities
(assuming there's a community of users opposing the change) can stick
together with their own in the same chain. That is, having only 2
chains in total if there are users opposing the change or only one if
not, but never 2 chains for people who want the change or 2 chains for
pople who don't want it.

Just my two sats, please nobody ask me "why would anyone oppose
taproot?" or anything similar. Because I'm trying to generalize here,
if we're talking about activation, I think the specifics of the change
are kind of irrelevant.

Separately: thanks to everyone who worked on taproot.


On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
 wrote:
>
>
>
> On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
> More importantly, nodes on both sides of the fork need to find each other.
>
>
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)
>
>
> I think it should be clear that a UASF-style command line option to allow 
> consensus rule changes in the node in the short term, immediately before a 
> fork carries some risk of a fork, even if I agree it may not persist over 
> months. We can’t simply ignore that.
>
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
>
>
> Between this and your above point, I think we probably agree - there is 
> material  technical complexity hiding behind a “change the consensus rules“ 
> option. Given it’s not a critical feature by any means, putting resources 
> into fixing these issues probably isn’t worth it.
>
> Matt
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
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)

[Anthony Towns via bitcoin-dev]

On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote:
> I think it should be clear that a UASF-style command line option to allow
> consensus rule changes in the node in the short term, immediately before a 
> fork
> carries some risk of a fork, even if I agree it may not persist over months. 
> We
> can’t simply ignore that.

I don't think a "-set-bip8-lockinontimeout=taproot" option on its own
would be very safe -- if we were sure it was safe, because we were sure
that everyone would eventually set lockinontimeout=true, then we would
set lockinontimeout=true from day one and not need an option. I haven't
seen/had any good ideas on how to make the option safe, or at least make
it obvious that you shouldn't be setting it if you don't really
understand what you're getting yourself into. [0]

And that's even if you assume that the code was perfectly capable of
handling forks in some theoretically optimal way.

So at least for the time being, I don't think a config param / command
line option is a good idea for bip8. IMHO, YMMV, IANABDFL etc.

> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
> Between this and your above point, I think we probably agree - there is
> material  technical complexity hiding behind a “change the consensus rules“
> option. Given it’s not a critical feature by any means, putting resources into
> fixing these issues probably isn’t worth it.

For reference, the "preferentially peer with other UASF nodes" PR for
the BIP148 client was

  https://github.com/UASF/bitcoin/pull/24

List discussion was at

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html

I think I'll add playing around with that and reorgs on a signet to my
todo list to see how it goes in cases other than ones that are (hopefully)
vanishingly unlikely to ever happen in practice.

Cheers,
aj

[0] In some sense, this is exactly the opposite sentiment compared to
earonesty's comment:

https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-31712

I mean, I guess could solve the unsafe-now-but-maybe-safe-later
problem generally with a signature:

  -authorise-dangerous-options-key=
  -lockinontimeout=taproot:

where  is a signature of "dangerous:lockinontimeout=taproot" or
similar by the key , and  defaults to some (multisig?) key
controlled by some bitcoin people, who'll only sign that when
there's clear evidence that it will be reasonably safe, and maybe to
"cert-transparency" or something as well. So that allows having an
option become available by publishing a signature, without having
to recompile the code. And it could still be overriden by people who
know what they're doing if the default key owners are being weird. And
maybe the "dangerous" part is enough to prevent people from randomly
cut-and-pasting it from a website into their bitcoin.conf.

I dunno. No bad ideas when brainstorming...
___
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)

[Matt Corallo via bitcoin-dev]

> On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
> 
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
> 
>> More importantly, nodes on both sides of the fork need to find each other. 
> 
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)

I think it should be clear that a UASF-style command line option to allow 
consensus rule changes in the node in the short term, immediately before a fork 
carries some risk of a fork, even if I agree it may not persist over months. We 
can’t simply ignore that.

> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".

Between this and your above point, I think we probably agree - there is 
material  technical complexity hiding behind a “change the consensus rules“ 
option. Given it’s not a critical feature by any means, putting resources into 
fixing these issues probably isn’t worth it.

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

[Anthony Towns via bitcoin-dev]

On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote:
> A node feeding you invalid headers (used to be) cause for a ban [...]

Headers that are invalid due to MUST_SIGNAL rules are marked as
BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're
doing headers-first relay, I think that will also prevent hitting the
BLOCK_MISSING_PREV case, which would result in a ban.

If a lockinontimeout=true node is requesting compact blocks from a
lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
I think that could result in a ban.

> More importantly, nodes on both sides of the fork need to find each other. 

(If there was going to be an ongoing fork there'd be bigger things to
worry about...)

I think the important specific case of this is something like "if a chain
where taproot is impossible to activate is temporarily the most work,
miners with lockinontimeout=true need to be well connected so they don't
end up competing with each other while they're catching back up".

Actually, that same requirement might be more practically for a signet
feature we were thinking about -- namely having "optional reorgs", ie
every now and then we'd mine 1-6 blocks and then reorg them out; but
also flag the soon-to-be-stale blocks in some way so that if you didn't
want to have to deal with reorgs you could easily ignore them. Having
it be possible for the "I want to see reorgs!" nodes to be able to find
each other seems like it might be a similar problem (avoiding having the
"don't-want-reorgs" nodes ban the "want-reorgs" nodes too perhaps).

Cheers,
aj

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

[Prayank via bitcoin-dev]

Hello Everyone,

The below comment by Matt about different implementations and their opinion on 
`lockinontimeout` is from 18 Feb 2021 communication: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html

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

I don't agree to the part that 'we should stop and not activate taproot'. 
Instead it will be helpful if we can educate most of the people about 
trade-offs involved in both options with some tables, charts etc.

I think its time to use Bitcoin Knots for more projects and also maintain 
multiple forks of Bitcoin Core. This is not just limited to `LOT=True or False` 
but few other things and in general its good for decentralization of Bitcoin. 
Bitcoin Core is used by most of the nodes according to this pie chart: 
https://luke.dashjr.org/programs/bitcoin/files/charts/software.html however 
having multiple forks of Bitcoin Core with real usage, more maintainers in 
different parts of the world (some even anon), few different features, more 
reviewers, better communication channels etc. will help everyone involved in 
Bitcoin.

I am working on a project right now which involves multisig, discreet log 
contracts, liquid etc. Using bitcoin-s for it because I need DLC but still 
depending on Bitcoin Core in it. Would try Bitcoin Knots and other 
implementations soon and also have been looking for developers good with C++ 
and Python, living in India who are interested to maintain a fork of Bitcoin 
Core with few changes. I had shared about in replies to Amir Taaki's tweet few 
days back.

--
Prayank

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

[Matt Corallo via bitcoin-dev]

Hmm, indeed, I may have missed that you can skip the headers issues by not 
persisting them, though there are other follow-on effects that are concerning 
and I think still make my point valid.

A node feeding you invalid headers (used to be) cause for a ban - is that 
information still persisted? More importantly, nodes on both sides of the fork 
need to find each other. There’s not a great way to do that without forking the 
address database, DNS seeds and defining a new protocol magic.

Matt

> On Feb 22, 2021, at 00:16, Anthony Towns  wrote:
> 
> On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
>> It was pointed out to me that this discussion is largely moot as the
>> software complexity for Bitcoin Core to ship an option like this is likely
>> not practical/what people would wish to see.
>> Bitcoin Core does not have infrastructure to handle switching consensus
>> rules with the same datadir - after running with uasf=true for some time,
>> valid blocks will be marked as invalid, 
> 
> I don't think this is true? With the current proposed bip8 code,
> lockinontimeout=true will cause headers to be marked as invalid, and
> won't process the block further. If a node running lockinontimeout=true
> accepts the header, then it will apply the same consensus rules as a
> lockinontimeout=false node.
> 
> I don't think an invalid header will be added to the block index at all,
> so a node restart should always cleanly allow it to be reconsidered.
> 
> The test case in
> 
> https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8
> 
> tests that a node that had rejected a chain due to lockinontimeout=true
> will reorg to that chain after being restarted as a byproduct of the way
> it tests different cases (the nodes set a new startheight, but retain
> their lockinontimeout settings).
> 
> 
> (I think with the current bip8 code, if you switch from
> lockinontimeout=false to lockinontimeout=true and the tip of the current
> most work chain is after the timeoutheight and did not lockin, then you
> will continue following that chain until a taproot-invalid transaction
> is inclued, rather than immediately reorging to a shorter chain that
> complies with the lockinontimeout=true rules)
> 
> Cheers,
> aj
> 
___
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)

[Anthony Towns via bitcoin-dev]

On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:
> It was pointed out to me that this discussion is largely moot as the
> software complexity for Bitcoin Core to ship an option like this is likely
> not practical/what people would wish to see.
> Bitcoin Core does not have infrastructure to handle switching consensus
> rules with the same datadir - after running with uasf=true for some time,
> valid blocks will be marked as invalid, 

I don't think this is true? With the current proposed bip8 code,
lockinontimeout=true will cause headers to be marked as invalid, and
won't process the block further. If a node running lockinontimeout=true
accepts the header, then it will apply the same consensus rules as a
lockinontimeout=false node.

I don't think an invalid header will be added to the block index at all,
so a node restart should always cleanly allow it to be reconsidered.

The test case in

https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8

tests that a node that had rejected a chain due to lockinontimeout=true
will reorg to that chain after being restarted as a byproduct of the way
it tests different cases (the nodes set a new startheight, but retain
their lockinontimeout settings).


(I think with the current bip8 code, if you switch from
lockinontimeout=false to lockinontimeout=true and the tip of the current
most work chain is after the timeoutheight and did not lockin, then you
will continue following that chain until a taproot-invalid transaction
is inclued, rather than immediately reorging to a shorter chain that
complies with the lockinontimeout=true rules)

Cheers,
aj

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

[Erik Aronesty via bitcoin-dev]

I think the most important thing is that the configuration setting is
advertised if somebody were to query the node for its capabilities.

Is this the case?

That way the default value isn't really the important thing.

There are longstanding and well-known nodes, for example.  Community
support and visibility for a UASF is the most important aspect.

I looked over the threads and I don't think I saw the broadcast nature of
this setting clearly discussed.





On Wed, Feb 17, 2021, 10:10 AM Michael Folkson via bitcoin-dev <
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
>
> 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: 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
>
> 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 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 

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

[Matt Corallo via bitcoin-dev]

I don’t think “some vocal users are going to threaten to fork themselves off” 
is good justification for technical decisions. It’s important to communicate 
and for everyone to agree/understand that a failed BIP 8/9 activation, in the 
scenario people are worried about, is not the end of the story for Taproot 
activation. If it is clear that Taproot has broad consensus but some miners 
failed to upgrade in time (as it presumably would be), a flag day activation 
seems merited and I’m not sure anyone has argued against this. That said, 
forced-signaling via a UASF/BIP8(true)-style fork carries material additional 
risk that a classic flag-day activation does not, so let’s not optimize for 
something like that.

Matt

> On Feb 21, 2021, at 08:26, Ariel Lorenzo-Luaces via bitcoin-dev 
>  wrote:
> 
> 
> What would be the tradeoffs of a BIP8(false, ∞) option? That would remove 
> some of the concerns of having to coordinate a UASF with an approaching 
> deadline.
> 
> Cheers
> Ariel Lorenzo-Luaces
>> On Feb 19, 2021, at 6:55 PM, ZmnSCPxj via bitcoin-dev 
>>  wrote:
>> Good morning list,
>> 
>>>  It was pointed out to me that this discussion is largely moot as the 
>>> software complexity for Bitcoin Core to ship an
>>>  option like this is likely not practical/what people would wish to see.
>>> 
>>>  Bitcoin Core does not have infrastructure to handle switching consensus 
>>> rules with the same datadir - after running with
>>>  uasf=true for some time, valid blocks will be marked as invalid, and 
>>> additional development would need to occur to
>>>  enable switching back to uasf=false. This is complex, critical code to get 
>>> right, and the review and testing cycles
>>>  needed seem to be not worth it.
>> 
>> Without implying anything else, this can be worked around by a user 
>> maintaining two `datadir`s and running two clients.
>> This would have an "external" client running an LOT=X (where X is whatever 
>> the user prefers) and an "internal" client that is at most 0.21.0, which 
>> will not impose any LOT rules.
>> The internal client then uses `connect=` directive to connect locally to the 
>> external client and connects only to that client, using it as a firewall.
>> The external client can be run pruned in order to reduce diskspace resource 
>> usage (the internal client can remain unpruned if that is needed by the 
>> user, e.g. for LN implementation sthat need to look up arbitrary 
>> short-channel-ids).
>> Bandwidth usage should be same since the internal client only connects to 
>> the external client and the OS should optimize that case.
>> CPU usage is doubled, though.
>> 
>> (the general idea came from gmax, just to be clear, though the below use is 
>> from me)
>> 
>> Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core 
>> ultimately ships with) on the external client based on the user preferences.
>> 
>> If Taproot is not MASF-activated and LOT=!U is what dominates later (where U 
>> is whatever the user decided on), the user can decide to just destroy the 
>> external node and connect the internal node directly to the network 
>> (optionally upgrading the internal node to LOT=!U) as a way to "change their 
>> mind in view of the economy".
>> The internal node will then follow the dominant chain.
>> 
>> 
>> Regards,
>> ZmnSCPxj
>> 
>>> 
>>>  Instead, the only practical way to ship such an option would be to treat 
>>> it as a separate chain (the same way regtest,
>>>  testnet, and signet are treated), including its own separate datadir and 
>>> the like.
>>> 
>>>  Matt
>>> 
  On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
 
  (Also in response to ZMN...)
  Bitcoin Core has a long-standing policy of not shipping options which 
 shoot yourself in the foot. I’d be very disappointed if that changed now. 
 People are of course more than welcome to run such software themselves, 
 but I anticipate the loud minority on Twitter and here aren’t processing 
 enough transactions or throwing enough financial weight behind their 
 decision for them to do anything but just switch back if they find 
 themselves on a chain with no blocks.
  There’s nothing we can (or should) do to prevent people from threatening 
 to (and possibly) forking themselves off of bitcoin, but that doesn’t mean 
 we should encourage it either. The work Bitcoin Core maintainers and 
 developers do is to recommend courses of action which they believe have 
 reasonable levels of consensus and are technically sound. Luckily, there’s 
 strong historical precedent for people deciding to run other software 
 around forks, so misinterpretation is not very common (just like there’s 
 strong historical precedent for miners not unilaterally deciding forks in 
 the case of Segwit).
  Matt
 
>>  On Feb 19, 2021, at 07:08, Adam Back a...@cypherspace.org wrote:
>> 
>>  would dev consensus around releasing LOT=false be 

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

[Ariel Lorenzo-Luaces via bitcoin-dev]

What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some 
of the concerns of having to coordinate a UASF with an approaching deadline.

Cheers
Ariel Lorenzo-Luaces
⁣​

On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev 
 wrote:
>Good morning list,
>
>> It was pointed out to me that this discussion is largely moot as the
>software complexity for Bitcoin Core to ship an
>> option like this is likely not practical/what people would wish to
>see.
>>
>> Bitcoin Core does not have infrastructure to handle switching
>consensus rules with the same datadir - after running with
>> uasf=true for some time, valid blocks will be marked as invalid, and
>additional development would need to occur to
>> enable switching back to uasf=false. This is complex, critical code
>to get right, and the review and testing cycles
>> needed seem to be not worth it.
>
>Without implying anything else, this can be worked around by a user
>maintaining two `datadir`s and running two clients.
>This would have an "external" client running an LOT=X (where X is
>whatever the user prefers) and an "internal" client that is at most
>0.21.0, which will not impose any LOT rules.
>The internal client then uses `connect=` directive to connect locally
>to the external client and connects only to that client, using it as a
>firewall.
>The external client can be run pruned in order to reduce diskspace
>resource usage (the internal client can remain unpruned if that is
>needed by the user, e.g. for LN implementation sthat need to look up
>arbitrary short-channel-ids).
>Bandwidth usage should be same since the internal client only connects
>to the external client and the OS should optimize that case.
>CPU usage is doubled, though.
>
>(the general idea came from gmax, just to be clear, though the below
>use is from me)
>
>Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin
>Core ultimately ships with) on the external client based on the user
>preferences.
>
>If Taproot is not MASF-activated and LOT=!U is what dominates later
>(where U is whatever the user decided on), the user can decide to just
>destroy the external node and connect the internal node directly to the
>network (optionally upgrading the internal node to LOT=!U) as a way to
>"change their mind in view of the economy".
>The internal node will then follow the dominant chain.
>
>
>Regards,
>ZmnSCPxj
>
>>
>> Instead, the only practical way to ship such an option would be to
>treat it as a separate chain (the same way regtest,
>> testnet, and signet are treated), including its own separate datadir
>and the like.
>>
>> Matt
>>
>> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
>>
>> > (Also in response to ZMN...)
>> > Bitcoin Core has a long-standing policy of not shipping options
>which shoot yourself in the foot. I’d be very disappointed if that
>changed now. People are of course more than welcome to run such
>software themselves, but I anticipate the loud minority on Twitter and
>here aren’t processing enough transactions or throwing enough financial
>weight behind their decision for them to do anything but just switch
>back if they find themselves on a chain with no blocks.
>> > There’s nothing we can (or should) do to prevent people from
>threatening to (and possibly) forking themselves off of bitcoin, but
>that doesn’t mean we should encourage it either. The work Bitcoin Core
>maintainers and developers do is to recommend courses of action which
>they believe have reasonable levels of consensus and are technically
>sound. Luckily, there’s strong historical precedent for people deciding
>to run other software around forks, so misinterpretation is not very
>common (just like there’s strong historical precedent for miners not
>unilaterally deciding forks in the case of Segwit).
>> > Matt
>> >
>> > > On Feb 19, 2021, at 07:08, Adam Back a...@cypherspace.org wrote:
>> > >
>> > > > would dev consensus around releasing LOT=false be considered as
>"developers forcing their views on users"?
>> > >
>> > > given there are clearly people of both views, or for now don't
>care
>> > > but might later, it would minimally be friendly and useful if
>> > > bitcoin-core has a LOT=true option - and that IMO goes some way
>to
>> > > avoid the assumptive control via defaults.
>> >
>> > > Otherwise it could be read as saying "developers on average
>> > > disapprove, but if you, the market disagree, go figure it out for
>> > > yourself" which is not a good message for being defensive and
>avoiding
>> > > mis-interpretation of code repositories or shipped defaults as
>> > > "control".
>> >
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>___
>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)

[ZmnSCPxj via bitcoin-dev]

Good morning list,

> It was pointed out to me that this discussion is largely moot as the software 
> complexity for Bitcoin Core to ship an
> option like this is likely not practical/what people would wish to see.
>
> Bitcoin Core does not have infrastructure to handle switching consensus rules 
> with the same datadir - after running with
> uasf=true for some time, valid blocks will be marked as invalid, and 
> additional development would need to occur to
> enable switching back to uasf=false. This is complex, critical code to get 
> right, and the review and testing cycles
> needed seem to be not worth it.

Without implying anything else, this can be worked around by a user maintaining 
two `datadir`s and running two clients.
This would have an "external" client running an LOT=X (where X is whatever the 
user prefers) and an "internal" client that is at most 0.21.0, which will not 
impose any LOT rules.
The internal client then uses `connect=` directive to connect locally to the 
external client and connects only to that client, using it as a firewall.
The external client can be run pruned in order to reduce diskspace resource 
usage (the internal client can remain unpruned if that is needed by the user, 
e.g. for LN implementation sthat need to look up arbitrary short-channel-ids).
Bandwidth usage should be same since the internal client only connects to the 
external client and the OS should optimize that case.
CPU usage is doubled, though.

(the general idea came from gmax, just to be clear, though the below use is 
from me)

Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin Core 
ultimately ships with) on the external client based on the user preferences.

If Taproot is not MASF-activated and LOT=!U is what dominates later (where U is 
whatever the user decided on), the user can decide to just destroy the external 
node and connect the internal node directly to the network (optionally 
upgrading the internal node to LOT=!U) as a way to "change their mind in view 
of the economy".
The internal node will then follow the dominant chain.


Regards,
ZmnSCPxj

>
> Instead, the only practical way to ship such an option would be to treat it 
> as a separate chain (the same way regtest,
> testnet, and signet are treated), including its own separate datadir and the 
> like.
>
> Matt
>
> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
>
> > (Also in response to ZMN...)
> > Bitcoin Core has a long-standing policy of not shipping options which shoot 
> > yourself in the foot. I’d be very disappointed if that changed now. People 
> > are of course more than welcome to run such software themselves, but I 
> > anticipate the loud minority on Twitter and here aren’t processing enough 
> > transactions or throwing enough financial weight behind their decision for 
> > them to do anything but just switch back if they find themselves on a chain 
> > with no blocks.
> > There’s nothing we can (or should) do to prevent people from threatening to 
> > (and possibly) forking themselves off of bitcoin, but that doesn’t mean we 
> > should encourage it either. The work Bitcoin Core maintainers and 
> > developers do is to recommend courses of action which they believe have 
> > reasonable levels of consensus and are technically sound. Luckily, there’s 
> > strong historical precedent for people deciding to run other software 
> > around forks, so misinterpretation is not very common (just like there’s 
> > strong historical precedent for miners not unilaterally deciding forks in 
> > the case of Segwit).
> > Matt
> >
> > > On Feb 19, 2021, at 07:08, Adam Back a...@cypherspace.org wrote:
> > >
> > > > would dev consensus around releasing LOT=false be considered as 
> > > > "developers forcing their views on users"?
> > >
> > > given there are clearly people of both views, or for now don't care
> > > but might later, it would minimally be friendly and useful if
> > > bitcoin-core has a LOT=true option - and that IMO goes some way to
> > > avoid the assumptive control via defaults.
> >
> > > Otherwise it could be read as saying "developers on average
> > > disapprove, but if you, the market disagree, go figure it out for
> > > yourself" which is not a good message for being defensive and avoiding
> > > mis-interpretation of code repositories or shipped defaults as
> > > "control".
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

[Bryan Bishop via bitcoin-dev]

On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> (off-list)
>
> Your email client didn't thread correctly, so I'm not sure if you saw my
> responses to Adam's email, but note that there


That was not off-list; by the way, as a reminder, some users are digest
subscribed (or not subscribed at all) and they can only reply by making a
new email thread unless they want to forge the email headers to match the
thread (which is a lost art that not many people are familiar with anymore).

- Bryan
https://twitter.com/kanzure
___
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)

[Matt Corallo via bitcoin-dev]

(off-list)

Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there 
is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is 
a nontrivial undertaking in Bitcoin Core from a software perspective. The only practical way is to, just treat it as a 
different chain, which, in practice, it could be.


One group running LOT=true and one running LOT=false results in two Bitcoins, and the software would need to be able to 
handle that (and, presumably, allow users to switch between chains).


Matt

On 2/19/21 17:12, Matt Hill via bitcoin-dev wrote:

Good day all, this is my first post to this mailing list. Per Adam's comment 
below:

 > given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.

Both here and elsewhere, the debate taking place is around the manner of Taproot activation, not whether or not Taproot 
should be activated. The latter seems to have widespread support. Given this favorable environment, it seems to me this 
is an incredible opportunity for the developer contingency to "take the high road" while also minimizing time to Taproot 
activation using political incentives. By offering power on the left hand to miners and and power on the right to users, 
neither of whom is expressing disapproval of activation, but both of whom are able to activate without the consent of 
the other, both are incentivized to signal activation as quickly as possible to emerge as the "group that did it". All 
that must be done is to include a LOT=true option to Bitcoin Core that carries a default of LOT=false. Miners can 
activate at any time, users can signal their intent to activate should miners renege, and developers emerge as 
politically neutral in the eyes of both.


Extrapolating a bit, I contend this expanded agency of full node operatorship may result in more users running a full 
node, which is good and healthy. From a miner's point of view, more full nodes only increases the likelihood of future 
UASFs, and so they are even further incentivized to expedite Taproot activation. Perhaps this is a stretch, perhaps not.


To summarize: (1) this positions developers as neutral facilitators who deferred power to the other contingencies; (2) 
we may see a rise in the popularity of running a full node and the number of full node operators; (3) miners are 
incentivized to activate quickly to avoid being perceived as the "bad guys" and to avoid the spread of full nodes; and 
(4) even if miners do not activate, users can organize a UASF in a grass-roots way.


Matt Hill

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


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

[Matt Hill via bitcoin-dev]

Good day all, this is my first post to this mailing list. Per Adam's
comment below:

> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.

Both here and elsewhere, the debate taking place is around the manner of
Taproot activation, not whether or not Taproot should be activated. The
latter seems to have widespread support. Given this favorable environment,
it seems to me this is an incredible opportunity for the developer
contingency to "take the high road" while also minimizing time to Taproot
activation using political incentives. By offering power on the left hand
to miners and and power on the right to users, neither of whom is
expressing disapproval of activation, but both of whom are able to activate
without the consent of the other, both are incentivized to signal
activation as quickly as possible to emerge as the "group that did it". All
that must be done is to include a LOT=true option to Bitcoin Core that
carries a default of LOT=false. Miners can activate at any time, users can
signal their intent to activate should miners renege, and developers emerge
as politically neutral in the eyes of both.

Extrapolating a bit, I contend this expanded agency of full node
operatorship may result in more users running a full node, which is good
and healthy. From a miner's point of view, more full nodes only increases
the likelihood of future UASFs, and so they are even further incentivized
to expedite Taproot activation. Perhaps this is a stretch, perhaps not.

To summarize: (1) this positions developers as neutral facilitators who
deferred power to the other contingencies; (2) we may see a rise in the
popularity of running a full node and the number of full node operators;
(3) miners are incentivized to activate quickly to avoid being perceived as
the "bad guys" and to avoid the spread of full nodes; and (4) even if
miners do not activate, users can organize a UASF in a grass-roots way.

Matt Hill
___
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)

[Matt Corallo via bitcoin-dev]

It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an 
option like this is likely not practical/what people would wish to see.


Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with 
uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to 
enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles 
needed seem to be not worth it.


Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, 
testnet, and signet are treated), including its own separate datadir and the like.


Matt

On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:

(Also in response to ZMN...)

Bitcoin Core has a long-standing policy of not shipping options which shoot 
yourself in the foot. I’d be very disappointed if that changed now. People are 
of course more than welcome to run such software themselves, but I anticipate 
the loud minority on Twitter and here aren’t processing enough transactions or 
throwing enough financial weight behind their decision for them to do anything 
but just switch back if they find themselves on a chain with no blocks.

There’s nothing we can (or should) do to prevent people from threatening to 
(and possibly) forking themselves off of bitcoin, but that doesn’t mean we 
should encourage it either. The work Bitcoin Core maintainers and developers do 
is to recommend courses of action which they believe have reasonable levels of 
consensus and are technically sound. Luckily, there’s strong historical 
precedent for people deciding to run other software around forks, so 
misinterpretation is not very common (just like there’s strong historical 
precedent for miners not unilaterally deciding forks in the case of Segwit).

Matt


On Feb 19, 2021, at 07:08, Adam Back  wrote:

would dev consensus around releasing LOT=false be considered as "developers forcing 
their views on users"?


given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.



Otherwise it could be read as saying "developers on average
disapprove, but if you, the market disagree, go figure it out for
yourself" which is not a good message for being defensive and avoiding
mis-interpretation of code repositories or shipped defaults as
"control".



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


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

[Matt Corallo via bitcoin-dev]

(Also in response to ZMN...)

Bitcoin Core has a long-standing policy of not shipping options which shoot 
yourself in the foot. I’d be very disappointed if that changed now. People are 
of course more than welcome to run such software themselves, but I anticipate 
the loud minority on Twitter and here aren’t processing enough transactions or 
throwing enough financial weight behind their decision for them to do anything 
but just switch back if they find themselves on a chain with no blocks.

There’s nothing we can (or should) do to prevent people from threatening to 
(and possibly) forking themselves off of bitcoin, but that doesn’t mean we 
should encourage it either. The work Bitcoin Core maintainers and developers do 
is to recommend courses of action which they believe have reasonable levels of 
consensus and are technically sound. Luckily, there’s strong historical 
precedent for people deciding to run other software around forks, so 
misinterpretation is not very common (just like there’s strong historical 
precedent for miners not unilaterally deciding forks in the case of Segwit).

Matt

> On Feb 19, 2021, at 07:08, Adam Back  wrote:
>> would dev consensus around releasing LOT=false be considered as "developers 
>> forcing their views on users"?
> 
> given there are clearly people of both views, or for now don't care
> but might later, it would minimally be friendly and useful if
> bitcoin-core has a LOT=true option - and that IMO goes some way to
> avoid the assumptive control via defaults.

> Otherwise it could be read as saying "developers on average
> disapprove, but if you, the market disagree, go figure it out for
> yourself" which is not a good message for being defensive and avoiding
> mis-interpretation of code repositories or shipped defaults as
> "control".


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

[Adam Back via bitcoin-dev]

Personally I don't really have much of a view and think either
LOT=true or false is better in the context, they both seem safe given
the current context, where basically everyone is saying "are we there
yet", including pools (88.7% going out of their way to say YES
https://taprootactivation.com).  Not that pools are deciding of
anything, being service providers to miners, who can and will switch
pool fast, and miners in-turn being service providers to the market
and as the various forks showed will follow the market.

I think it's a very good idea for safety, if there is a tested and
reviewed code with an option to force LOT=true, even if the
bitcoin-core implementation ends up defaulting to LOT=false.

Part of the danger is rushed versions of things like BIP 91 to avoid a
chain split where miners left brinkmanship just a bit too late, to
avert BIP 148 forking, and BIP 91 was used to expedite activation to
avoid that. The rushed proposal, code, review, ship cycle on that was
dangerously fast - less time and eyes for review was the danger.

> would dev consensus around releasing LOT=false be considered as "developers 
> forcing their views on users"?

given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.

Otherwise it could be read as saying "developers on average
disapprove, but if you, the market disagree, go figure it out for
yourself" which is not a good message for being defensive and avoiding
mis-interpretation of code repositories or shipped defaults as
"control".

Adam

On Fri, 19 Feb 2021 at 11:30, ZmnSCPxj via bitcoin-dev
 wrote:
>
> Good morning list,
>
> > 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.
>
>
> Okay, I am backing off this proposal to force the LOT=false/true decision on 
> users, it was not particularly serious anyway (and was more a reaction to the 
> request of Samson Mow to just release both versions, which to my mind is no 
> different from such a thing).
>
>
> Nonetheless, as a thought experiment: the main issue is that some number of 
> people run LOT=true when miners do not activate Taproot early for some reason 
> and we decide to leave LOT=false for this particular bit until it times out.
> The issue is that those people will get forked off the network at the end of 
> this particular deployment attempt.
>
> I suspect those people will still exist whether or not Bitcoin Core supports 
> any kind of LOT=true mode.
> ("Never again" for some people)
>
> How do we convince them to go run LOT=false instead of getting themselves 
> forked off?
> Or do we simply let them?
>
> (and how is that different from asking each user to decide on LOT=false/true 
> right now?)
> ("reasonable default"?)
> (fundamentally speaking you still have to educate the users on the 
> ramifications of accepting the default and changing it.)
>
>
> Another thought experiment: From the point of view of a user who strongly 
> supports LOT=true, would dev consensus around releasing LOT=false be 
> considered as "developers forcing their views on users"?
> Why or why not?
>
>
> Regards,
> ZmnSCPxj
>
> > 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, 

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

[Ariel Luaces via bitcoin-dev]

Hi Michael
I think you're right, sorry for getting a little apocalyptic at the
end there lol.

> On Thu, Feb 18, 2021 at 3:08 AM 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.

I'm mostly referring to the two IRC discussions. I normally try to
avoid singling people out that's why I didn't refer to anyone in
perticular.
Here I'll list a couple of quotes from these ephemeral people, while
reading them keep in mind what would happen if a majority users and
miners decide to just avoid the latest version.
- 11:06: "LOT=true does not split the chain. It strictly reduces the
liklihood of that."
- 11:06: "LOT=false has chainsplit risks, not LOT=true"
- 08:59 "I guess it would be helpful to hear miners' answers to that question."
Response: 09:01 "not sure why; miners don't decide anything in this
regard it's more of `Taproot is activating. Please accelerate it if
you can`"
Reading the logs again I see some voices that do consider the right
that users and miners have to run whatever version they want
Response: 09:03 "I ask because you said something that's equivalent to
`miners don't get to decide which version of core their run`."
- T1, T2, T3, and T6 have language that assumes mass support for a
UASF and then proceed to make conclusions on what is safer and easier
to coordinate
A voice in the discussion expressed the same point I'm making:
10:53 "I disagree with T1: i don't think there is any logical
consequence in hardcoding LOT=true ensuring Taproot activation and
even less ensuring no political shenanigans. We obviously need
economic majority to run it and that would open way more political
arguments that they bluntly take part in an UASF without any bad
behaviour from miners."
- 11:14 "we know people will run LOT=true regardless of the default,
so it will be safer if LOT=true is made the default"
- 11:18 "With LOT=true, attempted UASFs are not necessary"
- 11:18 "why give them the ability to act maliciously in the first place?"
Response:11:18"LOT=false does not; people choosing to run software
that will enforce taproot under some reasonable circumstances provides
the information.  LOT=false just reduces the risk of unexpected
results from resulting in danger."
Response: 11:18 "LOT=false strictly increases the risks though.."
Response: 11:18 "please stop saying that, there are tradeoffs both ways."
- 11:11 "LOT=false gives miners the ability to decide [in response to
someone saying that LOT=false gives everyone else in the community the
ability to decide]"
This quote is a bit more nuanced because the implication is that
LOT=true doesn't give the ability to decide. But in reality they have
the ability to decide to not upgrade. Users  can also not upgrade to
be in solidarity with miners to protect them from unfair distrust and
aggression.
All the arguments above for LOT=true are rooted in the assumption that
everyone must upgrade to the latest version because of course they
will...? But that's not a given.

There are examples of people being aware that miners and users can run
any version they want. I misjudged the number of people who know that
LOT=true doesn't guarantee anything.
- 11:17 "The LOT=True crowd seems to have an underlying assumption
that a UASF will occur instead of something more orderly like Modern
Softfork Activation suggested, why? I don't think chances of that
happening are very high unless things play out similarly to Segwit but
it doesn't look like that."
- 11:17 "UASFs can be made much more difficult with a counter-UASF
UASFs like this one and segwit relied on intolerant-minority effects"
(I'm assuming counter-UASF means not upgrading as opposed to upgrading
to a new client that rejects the activation flag)

> 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.
If you look at https://taprootactivation.com/ no miners seem to be
expressing any support at all for lot=true. To pre-empt the counter
argument, I know 

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

[ZmnSCPxj via bitcoin-dev]

Good morning list,

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


Okay, I am backing off this proposal to force the LOT=false/true decision on 
users, it was not particularly serious anyway (and was more a reaction to the 
request of Samson Mow to just release both versions, which to my mind is no 
different from such a thing).


Nonetheless, as a thought experiment: the main issue is that some number of 
people run LOT=true when miners do not activate Taproot early for some reason 
and we decide to leave LOT=false for this particular bit until it times out.
The issue is that those people will get forked off the network at the end of 
this particular deployment attempt.

I suspect those people will still exist whether or not Bitcoin Core supports 
any kind of LOT=true mode.
("Never again" for some people)

How do we convince them to go run LOT=false instead of getting themselves 
forked off?
Or do we simply let them?

(and how is that different from asking each user to decide on LOT=false/true 
right now?)
("reasonable default"?)
(fundamentally speaking you still have to educate the users on the 
ramifications of accepting the default and changing it.)


Another thought experiment: From the point of view of a user who strongly 
supports LOT=true, would dev consensus around releasing LOT=false be considered 
as "developers forcing their views on users"?
Why or why not?


Regards,
ZmnSCPxj

> 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 

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: