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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 36B1CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 06:14:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id E955483E66
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 06:14:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E955483E66
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 5ig8WAknUdGc
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 06:14:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9AB1983E5F
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp1.osuosl.org (Postfix) with ESMTPS id 9AB1983E5F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2022 06:14:17 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1oZR5f-0000xa-24; Sat, 17 Sep 2022 16:14:13 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sat, 17 Sep 2022 16:14:05 +1000
Date: Sat, 17 Sep 2022 16:14:05 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YyVlra0AMIFO9Xid@erisian.com.au>
References: <YyQioS3F942wu1HW@erisian.com.au>
<798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <798e8c4a-78e2-b210-2202-4b358b95a581@mattcorallo.com>
X-Spam-Score-int: -18
X-Spam-Bar: -
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 06:14:19 -0000
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?
> 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. 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.
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). 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.
But each of those possibilities indicates a significant problem with
our answer for developing soft forks.
I guess my belief is that it's mostly (2) and (3) being too hard (which
taproot overcame because many were excited about it, and CTV overcame
because Jeremy's put a lot of effort into it; but consensus cleanup,
APO, simplicity, TXHASH, etc have not similarly overcome at this point),
which leads to the evaluation process being inconclusive when plausible
alternatives exist.
(In particular, I think having the process be massively difficult is
going to naturally cause any "humble" champion to decide that they're
not up to the task of following the process through to completion)
Anyway, that's some additional reasons why I believe what I said above,
in case that's interesting. But like I said at the start, if you still
disagree, that's fine of course.
Cheers,
aj
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html
https://github.com/bitcoin/bitcoin/pull/15481
https://github.com/bitcoin/bitcoin/pull/15482
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016765.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016763.html
https://github.com/bitcoin/bitcoin/pull/15482#issuecomment-469822630
[2] https://utxos.org/workshops/
[3] TXHASH https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
TX https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html
Elements-style opcodes https://twitter.com/rusty_twit/status/1518007923896578048
cf https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html
ANYPREVOUT? https://twitter.com/darosior/status/1474375301262151684
Simplicity? https://twitter.com/Mario_Gibney/status/1403890965903859718
Lisp? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020036.html
|
