Re: [bitcoin-dev] Response to Rusty Russell from Github

[Rusty Russell <rusty@rustcorp.com.au>]

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.