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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id BDC22C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Apr 2021 05:01:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 990AA402AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Apr 2021 05:01:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.653
X-Spam-Level:
X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id l52TJdy_D3gz
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Apr 2021 05:01:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2])
by smtp4.osuosl.org (Postfix) with ESMTPS id 57896402A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Apr 2021 05:01:58 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 4FFXLS74sfz9sWK; Wed, 7 Apr 2021 15:01:52 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Ryan Grant <bitcoin-dev@rgrant.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
<874kgkkpji.fsf@rustcorp.com.au>
<CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
Date: Wed, 07 Apr 2021 14:31:13 +0930
Message-ID: <87pmz6it7q.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
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 05:01:59 -0000
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.
|
