Response to Rusty Russell from Github

In response to https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3679489, reproduced below.

Rusty,

I concur with the gist of what you're saying -- Speedy Trial alone is not the final word on activation logic. There are likely better procedures for releasing and activating updates.

Where I disagree is that I do not believe that BIP8 with LOT configuration is the improved long term option we should ossify around either. I understand the triumvirate model you desire to achieve, but BIP8 with an individually set LOT configuration does not formalize how economic nodes send a network legible signal ahead of a chain split. A regular flag day, with no signalling, but communally released and communicated openly most likely better achieves the goal of providing users choice.

Where I also disagree is that we are likely to come to consensus on an improved long term process in the immediate future (e.g., within the next year), let alone the software for it.

Do you believe that perfecting a release mechanism is a showstopping issue for proceeding with any upgrade at this time? Or do you just want for this problem to actively be worked on going forward?

I think it's reasonable to want to form an open ended process to investigate, spec, and formalize a consistent and complete activation pathway but I don't think we should force the community to wait around for an unknown solution to release upgrades that are waiting for takeoff.

Lastly, I'll make the case that ST *does* meet your desired triumvirate at least as well as BIP8 with configurable LOT.

1. Developers release, but do not activate 2. Miners signal 3. Users may override by compiling and releasing a patched Bitcoin with moderate changes that activates Taproot at a later date. While this might *seem* more complicated a procedure than configurable LOT, here are four reasons why it may be simpler (and safer) to just do a fresh release:

A. No time-based consensus sensitivity on when LOT must be set (e.g., what happens if mid final signal period users decide to set LOT? Do all users set it at the same time? Or different times and end up causing nodes to ban each other for various reasons?) B. No "missed window" if users don't coordinate on setting LOT before the final period -- release whenever ready. C. ST fails fast, permitting users ample time to prepare an alternative release D. If miners continue to mine without signalling, and users abandon a LOT=true setting, their node will have already marked those blocks invalid and they will need to figure out how to re-validate the block.

RE: point 3, is it as easy as it *could* be? No, but I don't have any genius ideas on how to make it easier either. (Note that I've previously argued for adding configurable LOT=true on the basis that a user-run script could emulate LOT without any software change as a harm reduction, but I did not advocate that particular technique be formalized as a part of the activation process)

Best,

Jeremy

> > > Taproot could be activated by a blind monkey, [...] ST avoids the

hard questions, since it will almost certainly pass; [...] But one day, a real crisis will return. We won't have an answer, and we won't have practiced: this will make the crisis far worse. Instead, if we codify "devs propose, miners activate, users override" (i.e. a LOT=true option, off by default) we'll know exactly what the process will be when miners fail to activate. It may still be messy, of course, but we'll have all the tools at hand, and we'll even know the date the crisis will come to a head.

> >
> >
> > I think this argument makes two major errors:
> > ```
> > * First, it tries to artificially tie two improvements together; "if

you can't solve controversial activations, you shouldn't get taproot". That isn't the way we should do development: just as it was a mistake to try to tie segwit and a hard-fork to double the block size together, other improvements should also stand or fall on their own merits. If we're tying updates together there should be good reasons for why they're better together (eg segwit and the witness discount; and taproot, schnorr and tapscript).

> > ```
>
> No, this is a disagreement about how _all_ changes should be activated.

This is completely germane to the current debate. Remember, segwit wasn't "controversial" until it suddenly was, either. I believe this is not the case here, but then, I believed that last time as well.

>
> > ```
> > * Second, it assumes that you can usefully test a weapon when play

fighting -- if taproot can be activated by a blind monkey, then having your bodyguards activate taproot only proves they're as good as a blind monkey, not that they're ready to protect you from a home invasion. In particular, bip8 isn't even as ready as bip148 for a real battle; it lacks even the limited safeguards that were included in that client (and it's also lost the element of surprise, which might've been bip148's biggest advantage).

> > ```
>
> "BIP 8 isn't ready" is definitely a factor, but while I prefer existing

code when there are no other major factors, there are IMHO major factors here.

>
> > I think it also probably assumes that the bip8 approach is more ready

to go than it is -- there are (IMHO) serious unresolved objections to bip8 in every possible deployment mode (eg, just lot=true: developers are imposing decisions on miners and users; just lot=false: miners can object; lot=true and lot=false: unnecessary chain split risk, risk of downtime for those running lot=true, risk of reorgs/wipeout for those running lot=false). Maybe all those objections -- even the ones from one of the bip8 authors -- are mistaken, but personally I think it's more likely that significant improvements are needed.

>
> "unnecessary chainsplit risk". No, that's exactly the point: if we end up

with various significant factions fighting over the rules, there will be a chainsplit. There are no technical workarounds for this. BIP 8 has been revised to minimize the chance of an _unnecessary_ chainsplit, and the entire BIP-8 lot=true mechanism was designed as an explicit mining forcing function.

>
> I remember @pwuille saying explicitly about Segwit activation that users

must decide. That has stuck with me, and my preference for a hidden lot=true option reflects this understanding. Without such an option, developers are saying "you can override, but you'll have to replace us." The result in practice that users are reduced to "beg the devs" or "beg the miners". That kinda worked last time but damn it was messy, and such uncertainty does not help the BItcoin ecosystem.

>
> > Personally, I can think of about half a dozen soft-forks I would

like/expect to see progress on once taproot is squared away (great consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, op_cat/covenants), so it's not like there aren't other opportunities to improve activation methodologies coming up.

>
> If this approach is good enough until there's a crisis, then why would

anyone approve anything until a crisis comes?

Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> writes:

> Where I disagree is that I do not believe that BIP8 with LOT configuration
> is the improved long term option we should ossify around either. I
> understand the triumvirate model you desire to achieve, but BIP8 with an
> individually set LOT configuration does not formalize how economic nodes
> send a network legible signal ahead of a chain split. A regular flag day,
> with no signalling, but communally released and communicated openly most
> likely better achieves the goal of providing users choice.

You're ignoring the role of infrastructure. It's similar to saying that there is no need for elections: if things are bad enough, citizens can rise up and overthrow their government.

> 1. Developers release, but do not activate
> 2. Miners signal
> 3. Users may override by compiling and releasing a patched Bitcoin with
> moderate changes that activates Taproot at a later date. While this might
> *seem* more complicated a procedure than configurable LOT, here are four
> reasons why it may be simpler (and safer) to just do a fresh release:

Users may indeed, fire the devs and replace them, as this implies. This is not empowering users, but in effect risks reducing their role to "beg the devs or beg the miners".

> A. No time-based consensus sensitivity on when LOT must be set (e.g., what
> happens if mid final signal period users decide to set LOT? Do all users
> set it at the same time? Or different times and end up causing nodes to ban
> each other for various reasons?)

Yes, this Schelling point is important. If you read BIP-8, you will see that LOT=true activates at the last moment for this very reason.

> B. No "missed window" if users don't coordinate on setting LOT before the
> final period -- release whenever ready.

Of course there is: they need to upgrade in time.

> C. ST fails fast, permitting users ample time to prepare an alternative
> release

You'd think so, but given the confusion surrounding Segwit, it seems a year was barely time to debate, decide and coordinate. You want this ready to go at the *beginning* of the 1 year process, not being decided, debated, build and deployed once the crisis is upon us. That existing deployment is a vital stake in the calculus of those who might try to disrupt the process for any reason.

> D. If miners continue to mine without signalling, and users abandon a
> LOT=true setting, their node will have already marked those blocks invalid
> and they will need to figure out how to re-validate the block.

This is true, in fact, of any soft fork: a Luke points out, our lack of revalidation of blocks after upgrade is a bug. Which should be fixed: IMHO a decent PR to make LOT runtime configurable would reevaluate any blocks >= timeoutheight-2016 when it is altered.

> RE: point 3, is it as easy as it *could* be? No, but I don't have any
> genius ideas on how to make it easier either. (Note that I've previously
> argued for adding configurable LOT=true on the basis that a user-run script
> could emulate LOT without any software change as a harm reduction, but I
> did not advocate that particular technique be formalized as a part of the
> activation process)

BIP-8 (with the recent modifications to allow maximal number of non-signalling blocks) is technically as fork-preventative as we can seek to make it.

I am hopeful that our ecosystem will remain harmonious and we won't have to use it. But I am significantly more hopeful that we won't have to use it if we have it deployed and ready.

Cheers, Rusty.

I'm somewhat gobsmacked that this entire conversation hasn't included the word "market" in it at all. If there's one thing we can all agree we learned from Segwit2x, BCH, BSV, BU, etc, its that, ultimately, the market decides. Not only does the market decide, but there's lots of money to be made by being the market maker or operator letting the market make its voice heard. There is nothing we can, or should, do to ensure the market can make its voice heard - it always will.

We don't need to bend over backwards to make sure individual users are forced to try to form consensus among themselves via options or chain splits, we can just let the market decide. Within reason, the market will probably decide "yep, what the brains are doing looks good, Bitcoin needs to stay in consensus, no point in trying to nitpick something or we'll never come to consensus about anything". If what's being proposed is ever disagreed with by some small-ish but nontrivial group, futures markets are going to decide the fate of the system no matter what the consensus rules or activation method is, why do we need to do very much else?

Matt

On 4/6/21 00:40, Rusty Russell via bitcoin-dev wrote:

> Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> writes:
>> Where I disagree is that I do not believe that BIP8 with LOT configuration
>> is the improved long term option we should ossify around either. I
>> understand the triumvirate model you desire to achieve, but BIP8 with an
>> individually set LOT configuration does not formalize how economic nodes
>> send a network legible signal ahead of a chain split. A regular flag day,
>> with no signalling, but communally released and communicated openly most
>> likely better achieves the goal of providing users choice.
>
> You're ignoring the role of infrastructure.  It's similar to saying that
> there is no need for elections: if things are bad enough, citizens can
> rise up and overthrow their government.
>
>> 1. Developers release, but do not activate
>> 2. Miners signal
>> 3. Users may override by compiling and releasing a patched Bitcoin with
>> moderate changes that activates Taproot at a later date. While this might
>> *seem* more complicated a procedure than configurable LOT, here are four
>> reasons why it may be simpler (and safer) to just do a fresh release:
>
> Users may indeed, fire the devs and replace them, as this implies.  This
> is not empowering users, but in effect risks reducing their role to "beg
> the devs or beg the miners".
>
>> A. No time-based consensus sensitivity on when LOT must be set (e.g., what
>> happens if mid final signal period users decide to set LOT? Do all users
>> set it at the same time? Or different times and end up causing nodes to ban
>> each other for various reasons?)
>
> Yes, this Schelling point is important.  If you read BIP-8, you will see
> that LOT=true activates at the last moment for this very reason.
>
>> B. No "missed window" if users don't coordinate on setting LOT before the
>> final period -- release whenever ready.
>
> Of course there is: they need to upgrade in time.
>
>> C. ST fails fast, permitting users ample time to prepare an alternative
>> release
>
> You'd think so, but given the confusion surrounding Segwit, it seems a
> year was barely time to debate, decide and coordinate.  You want this
> ready to go at the *beginning* of the 1 year process, not being decided,
> debated, build and deployed once the crisis is upon us.  That existing
> deployment is a vital stake in the calculus of those who might try to
> disrupt the process for any reason.
>
>> D. If miners continue to mine without signalling, and users abandon a
>> LOT=true setting, their node will have already marked those blocks invalid
>> and they will need to figure out how to re-validate the block.
>
> This is true, in fact, of any soft fork: a Luke points out, our lack of
> revalidation of blocks after upgrade is a bug.  Which should be fixed:
> IMHO a decent PR to make LOT runtime configurable would reevaluate any
> blocks >= timeoutheight-2016 when it is altered.
>
>> RE: point 3, is it as easy as it *could* be? No, but I don't have any
>> genius ideas on how to make it easier either. (Note that I've previously
>> argued for adding configurable LOT=true on the basis that a user-run script
>> could emulate LOT without any software change as a harm reduction, but I
>> did not advocate that particular technique be formalized as a part of the
>> activation process)
>
> BIP-8 (with the recent modifications to allow maximal number of
> non-signalling blocks) is technically as fork-preventative as we can
> seek to make it.
>
> I am hopeful that our ecosystem will remain harmonious and we won't have
> to use it.  But I am significantly more hopeful that we won't have to
> use it if we have it deployed and ready.
>
> Cheers,
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>