summaryrefslogtreecommitdiff
path: root/7f/51e9c185c743b5e807762a2e1616afd8a8b1f8
blob: ce2a99840bad37bc038e266223de8c94542c6034 (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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 528CAC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 17:13:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with UTF8SMTP id 33824418DA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 17:13:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with UTF8SMTP id FL-r8LxLu5sk
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 17:13:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by smtp4.osuosl.org (Postfix) with UTF8SMTPS id DCA3F403F9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 17:13:13 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id D1B9751B7F8;
 Wed,  7 Apr 2021 17:13:11 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
 s=1617813664; t=1617815591;
 bh=Zf2BTGEZJPINcWZYzaQpu8fd1+x2vgE0R/EUxcZY99o=;
 h=Date:Subject:To:References:From:In-Reply-To:From;
 b=R7A4ueqeVR/5WAH5BkY3tkXlm3XFVG9zRkDZ8+ymFEPvkBqJAk4gdMhu+TRk76y+1
 oNgxZPisc/dyMoxCGm/k4ZQ1YS1xeVZBakmZgQc90TNzsBCTP0oeQ16F6QaypFLjAu
 FUiWDLDlQVHwgG6Rux27TTH7jz1R6tF2fzycHMGa2jvJb5hnvDwVgQtjx+R4inoIVB
 JYc72qCjPPfqI9BkcsNTgnwqyj4qRzxrR1jnIoI5Vy7E+9jIk+WhMCB5wmHrBSfaM4
 PlYnWnMoNQJAU9NrlntElAMdWARFjRzdY3H9Ncji/ekxaOCZm7qSRaZsPpV74pfI0d
 kiqVFr7yVguhg==
Message-ID: <21f49308-c624-8d55-a40d-6634b3cf4cb8@mattcorallo.com>
Date: Wed, 7 Apr 2021 13:13:11 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Ryan Grant <bitcoin-dev@rgrant.org>
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
 <874kgkkpji.fsf@rustcorp.com.au>
 <CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
 <87pmz6it7q.fsf@rustcorp.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <87pmz6it7q.fsf@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 17:13:15 -0000



On 4/7/21 01:01, Rusty Russell via bitcoin-dev wrote:
> Ryan Grant <bitcoin-dev@rgrant.org> writes:
>> On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
>> 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.

I strongly disagree with this characterization of ST, primarily because there just isn't the kind of agreement you seem 
to be assuming. ST isn't a "lets not decide because we don't want to formulate a specific grand plan" its more of a 
"lets not decide, because there are very strong, and very divergent viewpoints on what a specific grand plan can or 
should look like, and something most people are ok with is better than nothing at all". Ultimately, there are a number 
of possible directions a grand plan could go, and there appear to be at least several prominent (and likely many 
non-prominent) individuals who would strongly disagree with any such plan, you and I likely among them :).
>>
>> 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.

You say "developer and user consensus against them" here, but then go on to argue that its perfectly acceptable for only 
a small subset of users to be required to do something below.

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

We already have a really, really great precedent for tracking economic majority, I'd argue we have great tooling here! 
During Segwit2x, we had multiple futures and chain-split-tokens available, including the BitMex futures with billions of 
dollars in daily volume! For the BCH split, ViaBTC issued similar chain split tokens.

At the end of the day, economic value is going to determine the amount of hashrate on any chain, and there is a very, 
very strong incentive (trading fees!) for an exchange to list...more stuff, chainsplit tokens included.

Why do we need to build in really janky ways to measure economic majority when there's already a great one that 
experience has shown us will prop up and provide reasonable signal, given any material demand.

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

While I strongly agree with your principle, I strongly disagree with the practice of how you propose going about it. 
Ultimately, no matter what we decide here, elsewhere, or what the process for consensus changes is, the decider will be 
economic activity and users voting with their Bitcoin. We should start by acknowledging that, and acknowledging that the 
markets will (and have!) let us know what they think when there is any kind of material disagreement.

Then, we should optimize for ensuring that the market never needs to "correct the situation", because if we end up there 
(or in any of these kinds of scenarios), we've basically screwed the pooch. Sure, some 10% minority group (and usually 
less as time goes on) forking themselves off has turned out to basically be irrelevant, but if we end up with multiple 
active chains as a normal course of business (which I'd strongly argue we'd be optimizing for with some kind of UASF/LOT 
option design out the gate), all we do is encourage strife, at the cost of users who just want to use a robust and 
reliable Bitcoin.

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

ST is not intended to be an end-all, be-all of the taproot activation story. I don't think anyone who is pushing for it 
thinks that ST is the only option if miners are not able to upgrade before its signaling window expires. Just because it 
isn't designed to ensure we can play brinksman ship fork games with a UASF doesn't mean there isn't a followup that 
could include such a thing.

Matt