public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Ryan Grant <bitcoin-dev@rgrant.org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
Date: Wed, 07 Apr 2021 14:31:13 +0930	[thread overview]
Message-ID: <87pmz6it7q.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>

Ryan Grant <bitcoin-dev@rgrant.org> writes:
> On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> The core question always was: what do we do if miners fail to activate?
>>
>> [...]  Speedy Trial takes the approach that "let's pretend we didn't
>> *actually* ask [miners]".
>
> What ST is saying is that a strategy of avoiding unnecessary risk is
> stronger than a strategy of brinkmanship when brinkmanship wasn't
> our only option.  Having deescalation in the strategy toolkit makes
> Bitcoin stronger.

I don't believe that having a plan is brinkmanship or an escalation.

During the segwit debate, Pieter Wuille said that users should decide.
I've been thinking about that a lot, especially about what that means in
a practical sense where the normal developer / miner dynamic has failed.

>> It's totally a political approach, to avoid facing the awkward question.
>> Since I believe that such prevaricating makes a future crisis less
>> predictable, I am forced to conclude that it makes bitcoin less robust.
>
> LOT=true does face the awkward question, but there are downsides:
>
>   - in the requirement to drop blocks from apathetic miners (although
>     as Luke-Jr pointed out in a previous reply on this list they have
>     no contract under which to raise a complaint); and

Surely, yes.  If the users of bitcoin decide blocks are invalid, they're
invalid.  With a year's warning, and developer and user consensus
against them, I think we've reached the limits of acceptable miner
apathy.

>   - in the risk of a chain split, should gauging economic majority
>     support - which there is zero intrinsic tooling for - go poorly.

Agreed that we should definitely do better here: in practice people
would rely on third party explorers for information on the other side of
the split.  Tracking the cumulative work on invalid chains would be a
good idea for bitcoind in general (AJ suggested this, IIRC).

>> Personally, I think the compromise position is using LOT=false and
>> having those such as Luke and myself continue working on a LOT=true
>> branch for future consideration.  It's less than optimal, but I
>> appreciate that people want Taproot activated more than they want
>> the groundwork future upgrades.
>
> Another way of viewing the current situation is that should
> brinkmanship be necessary, then better tooling to resolve a situation
> that requires brinkmanship will be invaluable.  But:
>
>   - we do not need to normalize brinkmanship;
>
>   - designing brinkmanship tooling well before the next crisis does
>     not require selecting conveniently completed host features to
>     strap the tooling onto for testing; and

Again, openly creating a contingency plan is not brinkmanship, it's
normal.  I know that considering these scenarios is uncomfortable; I
avoid conflict myself!  But I feel obliged to face this as a real
possibility.

I think we should be normalizing the understanding that bitcoin users
are the ultimate decider.  By offering *all* of them the tools to do so
we show this isn't lip-service, but something that businesses and
everyone else in the ecosystem should consider.

>   - it's already the case that a UASF branch can be prepared along
>     with ST (ie. without requiring LOT=false), although the code is a
>     bit more complex and the appropriate stopheight a few blocks later.

I don't believe this is true, unless you UASF before ST expires?  ST is
explicitly designed *not* to give time to conclude that miners are
stalling (unless something has changed from the initial 3 month
proposal?).

> Although your NACK is well explained, for the reasons above I am
> prepared to run code that overrides it.

Good.  In the end, we're all at the whim of the economic majority.

Cheers!
Rusty.


  reply	other threads:[~2021-04-07  5:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24  3:46 [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes Jeremy
2021-03-25  7:02 ` Anthony Towns
2021-03-25 14:30   ` Jeremy
2021-04-06  4:25 ` Rusty Russell
2021-04-07  1:20   ` Ryan Grant
2021-04-07  5:01     ` Rusty Russell [this message]
2021-04-07 13:42       ` Claus Ehrenberg
2021-04-07 15:25         ` eric
2021-04-07 17:13       ` Matt Corallo
2021-04-08 11:11       ` Anthony Towns
2021-03-24 11:23 Michael Folkson
2021-03-24 18:10 ` Jeremy
2021-03-24 19:14   ` Michael Folkson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmz6it7q.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@rgrant.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox