summaryrefslogtreecommitdiff
path: root/53/5cd42b9e13afbee8ef476ff0ef9ea34d9927bc
blob: db64c55311ca4811fda8bd284c1eecb5e7ba2f72 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Return-Path: <rgrant@rgrant.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F078AC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 01:20:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D76766067B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 01:20:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level: 
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wg6opDf6q-ZJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 01:20:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com
 [209.85.221.53])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 9799F6062F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 01:20:43 +0000 (UTC)
Received: by mail-wr1-f53.google.com with SMTP id j18so16075945wra.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 06 Apr 2021 18:20:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=JBKgmI25ytKClADh9H4QO1IQ/0Evk0lJ0klzx7cvXRo=;
 b=bavr2z4yu6FvI/hEpZ8l7x4CH/bWHwU9fPbPZRK2c0885wGKCM07c96JdsqhQiGqEd
 5xax8V0UK+oevtSmkJEowXnAkuyiPZRSPrNArsASZvmlLt9e7NI4rN2f5+ggJQCrdBs/
 DGWvV65TAWVeOy66Nxp9D+Fm6FjCPvrYqAJ/9yyWtRaoyflAm4A1RmEwiEPlqiQt1P2l
 ceH50u4rBd9sd2G+EigFAzvkirI1cIs1V4QG1eUnXEwIaGWUWl75QNHUPGC6F3cn+YJG
 feOZo8aOlIebeYsEbouMe2Ej8JvZLOkLqGXbhpvph88b4xPMAhadMZmyjkGOeTREHu0A
 4ukA==
X-Gm-Message-State: AOAM5308UWzXLnAwcgl3vUE/57KCI2HPxZmFYjkWekMS2mmwrcd9xAIo
 nsYaw4KsmoSZxlU0U1FPt1OsdzqGQHCVNt7dZNyn+9kJe/9YYWwdfvs=
X-Google-Smtp-Source: ABdhPJxO+WBz2YQGyp63zfezetU6cY2dVYy8pyecVoOQZXVYvK6srz2aZckiV8vlRCrNdAcVnxdiY2p8t/G2612kTWo=
X-Received: by 2002:adf:f005:: with SMTP id j5mr1049929wro.423.1617758441739; 
 Tue, 06 Apr 2021 18:20:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
 <874kgkkpji.fsf@rustcorp.com.au>
In-Reply-To: <874kgkkpji.fsf@rustcorp.com.au>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Wed, 7 Apr 2021 01:20:15 +0000
Message-ID: <CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 01:20:45 -0000

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.

> 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

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

> 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

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

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