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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D7C73C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 08:39:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id B156A41936
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 08:39:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B156A41936
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=mattcorallo.com header.i=@mattcorallo.com
header.a=rsa-sha256 header.s=1663401662 header.b=qS4fjq1A;
dkim=pass (2048-bit key) header.d=clients.mail.as397444.net
header.i=@clients.mail.as397444.net header.a=rsa-sha256 header.s=1663401664
header.b=OJ+xxMxk
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham 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 bGkU2RPufHJ7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 08:39:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5F1E6418FF
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp4.osuosl.org (Postfix) with ESMTPS id 5F1E6418FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 08:39:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1663401662; h=In-Reply-To:From:References:To:Subject:
From:Subject:To:Cc:Cc:Reply-To;
bh=9u6z7oH0vQzzBiIUp17F1WRVY+emIne+I2S7nUSfSrA=; b=qS4fjq1AwMT8uuaJ4Uar1saucO
5x0NGpyF8VRaf7D46XBgTbg/CSx0xirh5R5QGWBzO4j87y37IIia7A1T4mddqgyDOKRRtWnPIDkwt
1ro+wGd4T0BN+Uans1bMRLUzfwdCSLHG4evDF4Z0Gvkj+3VCoTrW8jUdHba2ALA81YbQEwJ3NP2K4
lc1Lf7pt3TS/8dbv+h53uY9io7qpqv6/lQsXSPtK+Hl92EkYRxQPciJ7IedDBwGxl2zvrLlYdb5bt
/ihpm2wQE5JHDrM4DcZd2J1tlTsnuIwZaTTYC+gxBD+VEWvm3pXMGaDH7HNiHvQPM7lo/MYbO6imo
LcQq1bIg==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=clients.mail.as397444.net; s=1663401664; h=In-Reply-To:From:References:To:
Subject:From:Subject:To:Cc:Cc:Reply-To;
bh=9u6z7oH0vQzzBiIUp17F1WRVY+emIne+I2S7nUSfSrA=; b=OJ+xxMxkhVHZiod/pH00vQTvQh
2EGS4SKcGmnm6l7ZrSiTk3P45W1fO/dXJQEK2Wnqz/oAcQDjjMFp509D8tH5O2fGxoWkGlJGPGQVI
T8OM45Z54vCsLOzGvOMC2ecZfOeKr+3qtknzzWN0OIaohRlTvgRRgqGk9j9pMXpieaK9hXyzjoT+h
ZO8V6Mtk+3giQlewH7p8+kUnHVaLRFLfuEWj//Yf1o/JQtUhIhjN+mANkP47qMRLBJgPo3Zo22w3E
UStW5Hkpiv1jG0dOEJ8b5/8Lmxj6Meq82XAW3OwpKW4oEQ6l6nWmK60HemhlQ4Jkp9N9JI3xFmeo5
NA7CNJ1w==;
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>) id 1oZTLz-003vT0-0S;
Sat, 17 Sep 2022 08:39:11 +0000
Message-ID: <8e4dc33b-2992-0380-de2a-0b8afa3db5b7@mattcorallo.com>
Date: Sat, 17 Sep 2022 04:39:07 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <YyQioS3F942wu1HW@erisian.com.au>
<798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
<YyVlra0AMIFO9Xid@erisian.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <YyVlra0AMIFO9Xid@erisian.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-DKIM-Note: Keys used to sign are likely public at
https://as397444.net/dkim/mattcorallo.com
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
signet
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: Sat, 17 Sep 2022 08:39:15 -0000
On 9/17/22 2:14 AM, Anthony Towns wrote:
> On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote:
>> On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
>>> As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier
>>> in the year [0], the question of "how to successfully get soft fork
>>> ideas from concept to deployment" doesn't really have a good answer today.
>> I strongly disagree with this.
>
> Okay? "X is good" is obviously just a statement of opinion, so if you
> want to disagree, that's obviously allowed.
>
> I also kind of feel like that's the *least* interesting paragraph in the
> entire email to talk further about; if you think the current answer's
> already good, then the rest of the mail's just about (hopefully) making
> it better, which would be worthwhile anyway?
No, I think its at least a good chunk of the "statement of problem". Yes, more testing is good, and
this project is a way to get that. Cool. But implying that lack of test frameworks is in any
material way part of the lack of movement on forks in Bitcoin I think is very wrong, so its worth
pointing out, whether the particular project is useful or not is separate.
>> Going back many, many years we've had many
>> discussions about fork process, and the parts people (historically) agreed
>> with tend to be:
>> (1) come up with an idea
>> (2) socialize the idea in the technical community, see if anyone comes up
>> with any major issues or can suggest better ideas which solve the same
>> use-cases in cleaner ways
>> (3) propose the concrete idea with a more well-defined strawman, socialize
>> that, get some kind of rough consensus in the loosely-defined, subjective,
>> "technical community" (ie just ask people and adapt to feedback until you
>> have found some kind of average of the opinions of people you, the
>> fork-champion, think are reasonably well-informed!).
>> (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there.
>> Turns out, the issue today is a lack of champions following steps 1-3, we
>> can debate what the correct answer is to step (4) once we actually have
>> people who want to be champions who are willing to (humbly) push an idea
>> forward towards rough agreement of the world of technical bitcoiners
>> (without which I highly doubt you'd ever see broader-community consensus).
>
> Personally, I think this is easily refuted by contradiction.
>
> 1) If we did have a good answer for how to progress a soft-fork, then
> the great consensus cleanup [0] would have made more progress over the
> past 3.5 years
No? Who is the champion for it? I haven't been. No one else is obliged to take up the reins and run
with it, that's not how open-source works. And no one has emerged who has strong interest in doing
so, and that's totally fine. It means it hasn't made any progress, but that's an indication that no
one feels strongly enough about it that its risen to the top of their personal priority list so
clearly doesn't *need* to make progress.
> Maybe not all of the ideas in it were unambiguously good
> [1], but personally, I'm convinced at least some of them are, and I
> don't think I'm alone in thinking that. Even if the excuse is that its
> original champion wasn't humble enough, there's something wrong with
> the process if there doesn't exist some other potential champion with
> the right balance of humility, confidence, interest and time who could
> have taken it over in that timeframe.
No? Its not up to the community to find a champion for someone who wants a fork to happen. Either
someone thinks its a good enough idea that they step up, or no one does. If no one does, then so be
it. If the original proper (me, in this case) thought it was that important then its *their*
responsibility to be the champion, no one else's.
> 2) Many will argue that CTV has already done steps (1) through (3) above:
> certainly there's been an idea, it's been socialised through giving talks,
> having discussion forums, having research workshops [2], documenting use
> cases use cases; there's been a concrete implementation for years now,
> with a test network that supports the proposed feature, and new tools
> that demonstrate some of the proposed use cases, and while alternative
> approaches have been suggested [3], none of them have even really made
> it to step (2), let alone step (3).
I don't really see how you can make this argument seriously. Honestly, if a soft-fork BIP only has
one author on the list, then I'm not sure one can argue that step (3) has really been completed, and
maybe not even step (2).
> So that leaves a few possibilities
> to my mind:
> * CTV should be in step (4), and its lack of definition is a problem,
> and trying the "deal with it when we get there" approach is precisely
> what didn't work back in April.
>
> * The evaluation process is too inconclusive: it should either be
> saying "CTV is not good enough, fix these problems", or "CTV hasn't
> sufficiently demonstrated its value/cost, work on X next", but it
> isn't.
>
> * Parts (2) to (3) are too hard, and that's preventing alternatives
> from making progress, which in turn is preventing people from
> being able to decide whether CTV is the superior approach, or some
> alternative is.
I think this is most of it, but its not that they're too hard, its that people are *too busy*. There
seemed to be more positive feedback, for example, to Rusty's proposal, but being the champion for a
soft-fork is a full-time job for months on end, and last I checked Rusty has a lightning
implementation to maintain, which tends to be a more-than-full-time job already.
To my knowledge, no one but Jeremy has made any serious attempt at being the champion for a
soft-fork since Taproot, and before that Segwit (if someone reading this who contributes to Core
already wants to, and isn't sure how to, there's lots of people who would happily mentor you! I'm
sure you can figure out who to reach out to!).
Matt
|
