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
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B5320C007A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 22:28:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A03E284331
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 22:28:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=no 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 R39F6y7sVDVU
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 22:28:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp1.osuosl.org (Postfix) with ESMTPS id 075B084325
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 22:28:20 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 62DF9280005A;
Thu, 21 Apr 2022 15:28:18 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Thu, 21 Apr 2022 15:28:17 -0700 (PDT)
MIME-Version: 1.0
Date: Thu, 21 Apr 2022 12:28:17 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
<4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
<c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <4056eca7e1ff018bff03918b8c266d76@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 7dff.6261da81.ea10e.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
e.g. for CTV
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: Thu, 21 Apr 2022 22:28:21 -0000
On 21.04.2022 08:39, Matt Corallo wrote:
> We add things to Bitcoin because (a) there's some demonstrated
> use-cases and intent to use the change (which I think we definitely
> have for covenants, but which only barely, if at all, suggests
> favoring one covenant design over any other)
I'm unconvinced about CTV's use cases but others have made reasonable
claims that it will be used. We could argue about this indefinitely,
but I would love to give CTV proponents an opportunity to prove that a
significant number of people would use it.
> (b) because its
> generally considered aligned with Bitcoin's design and goals, based on
> developer and more broad community response
I think CTV fulfills this criteria. At least, I can't think of any way
BIP119 itself (notwithstanding activation concerns) violates Bitcoin's
designs and goals.
> (c) because the
> technical folks who have/are wiling to spend time working on the
> specific design space think the concrete proposal is the best design
> we have
This is the criteria that most concerns me. What if there is no
universal best? For example, I mentioned in my previous email that I'm
a partisan of OP_CAT+OP_CSFS due to their min-max of implementation
simplicity versus production flexibility. But one problem is that
spends using them would need to contain a lot of witness data. In my
mind, they're the best for experimentation and for proving the existence
of demand for more optimized constructions.
OP_TX or OP_TXHASH would likely offer almost as much simplicity and
flexibility but be more efficient onchain. Does that make them better
than OP_CAT+OP_CSFS? I don't know how to objectively answer that
question, and I don't feel comfortable with my subjective opinion of
CAT+CSFS being better than OP_TX.
APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
certain usecases (respectively: Eltoo, congestion control, and
joinpools), providing maximum onchain efficiency for those cases but
requiring contortions or larger witnesses to accomplish other covenant
usecases. Is their increased efficiency better than more general
constructions like CSFS or TX? Again, I don't know how to answer that
question objectively, although subjectively I'm ok with optimized
constructions for cases of proven demand.
> , and finally (d) because the implementation is well-reviewed
> and complete.
No comment here; I haven't followed CTV's review progress to know
whether I'd consider it well enough reviewed or not.
> I do not see how we can make an argument for any specific covenant
> under (c) here. We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".
I'm curious how we as a technical community will be able to determine
which is the best approach. Again, I like starting simple and general,
gathering real usage data, and then optimizing for demonstrated needs.
But the simplest and most general approaches seem to be too general for
some people (because they enable recursive covenants), seemingly forcing
us into looking only at application-optimized designs. In that case, I
think the main thing we want to know about these narrow proposals for
new applications is whether the applications and the proposed consensus
changes will actually receive significant use. For that, I think we
need some sort of test bed with real paying users, and ideally one that
is as similar to Bitcoin mainnet as possible.
> we
> cannot remove the validation code for something ever, really - you
> still want to be able to validate the historical chain
You and Jeremy both brought up this point. I understand it and I
should've addressed it better in my OP, but I'm of the opinion that
reverting to earlier consensus rules gives future developers the
*option* of dropping no-longer-used consensus code as a practical
simplification of the same type we've used on several occasions before,
and which is an optional default in newly started Bitcoin Core nodes for
over a decade now (i.e. skipping verification of old signatures). If
future devs *want* to maintain code from a set of temporary rules used
millions of blocks ago, that's great, but giving them the option to
forget about those rules eliminates one of my concerns about making
consensus changes without fully proven demand for that change.
I just wanted to mention the above in case this discussion comes back to
serious consideration of a transitory soft fork. For now, I think we
can table a debate over validating reverted rules and focus on how we'll
come to agreement that a particular covenant-related consensus change is
warranted.
Thanks for your thoughtful response,
-Dave
|
