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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
Delivery-date: Tue, 24 Jun 2025 09:01:03 -0700
Received: from mail-oo1-f59.google.com ([209.85.161.59])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBAABBNEX5PBAMGQEDYRZSFY@googlegroups.com>)
id 1uU651-0008Kx-6O
for bitcoindev@gnusha.org; Tue, 24 Jun 2025 09:01:03 -0700
Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-611051d18fesf429845eaf.1
for <bitcoindev@gnusha.org>; Tue, 24 Jun 2025 09:01:02 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1750780857; cv=pass;
d=google.com; s=arc-20240605;
b=EtV4unjZHlF3/Egv/jF6IyKe+5ithNVIrX/WpMzI5d3L+QKKjSIze+HGbJrFdgA+4a
MdyRG1JVPZn+gyf/QvuPr7cPhf0ys4OldL6YG98scsOtbQreD/fS0FAsZGvbo7CvU29O
M7Qq0A9Q10V2owkidVK9fGE3lZQuS0RY2lBK51XIZGElsxBFnThz5q/yjSReAGA2lUZD
xwoWZv5/U9Z8xTNpkIF2zQkrL4j0XXRh31CQ0Y0owqbjmjHMQ4IpBFNY4U9F26p/c9E2
LgMFBkz9GNS5Am35k1jOXYxmEm9BOWK+40lpTf0Hx+ONuYzmhkL0f0tvEmDeEFaNs41X
241A==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:in-reply-to:from:content-language
:references:to:subject:mime-version:date:message-id:sender
:dkim-signature;
bh=ctRt0ppjtcUJcLDWL1d025NR3u0gSg+DT+lZMsJz/kk=;
fh=CWpG9zqrHk7CyDomW9V2pwXyrnLGnE6u3Wd2CO+umho=;
b=k3RhunP7+Zzw4vyBr1/WeIVbOkx/aaAF8q9DQINHoy/wOwkYvkdOnEFwvkd3tIpexN
BisdmJk5seyJYBjlaSfvFdK5w8lIMZojKOs8vnEGz2gGKDv9dfJL+dX3vk2vq/CUZIns
opPZhgPKqkk9fb4NfXdX07XOK4xssvjtSAravFqYNN5hv9Up9YdVOVnRDQwma6MGyiBg
mRpbSgVrp3WETG63oCWGOK3u7NeHKHO5gl6XkkEDLwYGfsvuZ6pZdgaVMFS5ERBAlyvk
6ifEFw3BFszbGWU/0AmyCmWoCIFxTZqRsYqr1KVJAXGuU9wSziSNLutas+RS+lsoRDw+
uG7A==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@mattcorallo.com header.s=1750778463 header.b=asLfboNr;
dkim=pass header.i=@clients.mail.as397444.net header.s=1750778466 header.b=C+20759k;
spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1750780857; x=1751385657; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:from:content-language:references:to
:subject:mime-version:date:message-id:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=ctRt0ppjtcUJcLDWL1d025NR3u0gSg+DT+lZMsJz/kk=;
b=lP38kZP874Z0MxFjjX48FiME11VYcznH/aShMbjrS+QVoUCajrtXpeHT+9uIRAd7MC
8YkjQl0fn1bImk959TdpegfY+Y+b9VQQ7ekimlEpoCzOm6sl1C8yY9+eF9ln3gH2HLve
kho/ZcjXcOeRpf+AIB243WfA6nFZfUo3U5+reT9Ieh6RxDM4QLTOXqzngU0zK06aYvJy
WT80XaxTQjFGpPqtXllG3ZXAIqXlZo9U/up9+iuN06P5q1G3LJzc3dgDrXRMvKJAHdSd
3GhMllvUqQTf9NlZtfS3OrQv1bqPiZkjJd3aPWl3EgnsUG2WlR1nPb9wA8kB6tnfgcoe
7pjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1750780857; x=1751385657;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:from:content-language:references:to
:subject:mime-version:date:message-id:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=ctRt0ppjtcUJcLDWL1d025NR3u0gSg+DT+lZMsJz/kk=;
b=NjlgXMZveA4ovCbLL3am07KD6IJfJ/qOubEu3jM1I1lbHGZ3DLm4Hlj1NcXdr9fpeC
tLZkvzpS0llDruomMmGGBVp6Nz4l4ZDGNujMNJw2uWp3a0cMPFcg/xhmf/iSKqv02+qL
/cbDBm4vGBv8uHXFhoQLwUN+IrlPltl5mwHrZnqzA4e89e1FrNcLtqFk7QphZ6kiGPEJ
xZwks9zxT4CaLke/hxw+B/qYypaDDpx0rbUyCsU5r0lXgpDZQMqY8ccPWRAENxCKysZ0
nVqvAo52nkWWFylshSX1068wC43lhX87vRz54Uom+jEdrbyIOGqwPQZJc6a+1pXBLQFS
I5tQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCU7Kkw/TmKtI2HV23IGTxxvZDlHOEZQtyGyD15ZKN7aRFuSWQmvGPzhyQyMM5fICg2LTiNLNhv6Ejwi@gnusha.org
X-Gm-Message-State: AOJu0YxabofJtrSxHMVbrD+1CLIjea9uXrExhc1v6DZskdPlCHHnQSDk
Mh7J586c/Dtxv0bRB2LsTgl88qlgOUYJ0xRyw/PMjaURIuTzbGTArj4x
X-Google-Smtp-Source: AGHT+IFtyNkKc+1ggR2AXddOHpANc1kT5rYZd2Snj5GTJ+R+lDsIKBsCySjt+H2B+jrpUY4j6m5jUg==
X-Received: by 2002:a05:6871:7984:b0:2cb:c780:ac52 with SMTP id 586e51a60fabf-2eeee4dabd7mr11180370fac.23.1750780856399;
Tue, 24 Jun 2025 09:00:56 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdQCB/ENJzR+CQs9pM/HSsDN1D6nLIwO9RH1GD2OOpMyg==
Received: by 2002:a05:6870:1b88:b0:2eb:b30a:f5e0 with SMTP id
586e51a60fabf-2ebb30b04e6ls3726257fac.1.-pod-prod-03-us; Tue, 24 Jun 2025
09:00:52 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUR0rnSstm8pcOUO8PVzLcgAn4dNBCy2wqxL0vWPayuo7LX6fwhlu/0e3ys1n8nE2QZPu2x/27csEbt@googlegroups.com
X-Received: by 2002:a05:6808:130c:b0:404:e2fe:ee91 with SMTP id 5614622812f47-40ac6ed7ce3mr14730538b6e.8.1750780852624;
Tue, 24 Jun 2025 09:00:52 -0700 (PDT)
Received: by 2002:a05:6808:848c:b0:3f6:a384:eb6f with SMTP id 5614622812f47-40aa32aa09cmsb6e;
Tue, 24 Jun 2025 08:54:11 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVchnfHgfdBEXNmshd7x7flEnqw4/l0QES/g3+8nz5spuTTkNtFAI04Uv2PPXvP2qVcbfFtnYovZwXk@googlegroups.com
X-Received: by 2002:a05:6602:15c2:b0:86c:f8ba:5f08 with SMTP id ca18e2360f4ac-8762d18892bmr1946548439f.1.1750780451009;
Tue, 24 Jun 2025 08:54:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1750780450; cv=none;
d=google.com; s=arc-20240605;
b=MZz0RV7j/vZwF8iIA6021vxWc1T0/LZ3L4lTSbL69l+QPPR9uhZea1Uv1s8c+CDmd3
8psR4mgoYvgzU3M8F5dlG/bljR/ySMEz6KUMCdAyO94SW+ussXE733eCjSDGvf+kum9x
acQUxk5R77a9mgNLZkylPcIM3ahSVos88WDumUJZ03c5LXkTVrdqGBGWYLetvPgAAsg+
nRzklaRhjr0NJ56d6xrjvG9SZa0gfc+cEugIt7pfpHTz/nxJqDvAMMBW0m5g6Aejy17W
zPESj5QEXE1WuZI5Kbj6TdcbftE3neC+ZC2powK/tN4aRoDdP9qpx0nsU8zHcl8WWK/1
z+TQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:to:subject:mime-version:date:message-id:dkim-signature
:dkim-signature;
bh=G12RUMHFtKxC9GchJsvgPpMBET1Nb/U/vh+Fq5ksgx4=;
fh=02nJZxx48b/TyKrcvewNiN7FJtTrEjLEvj+vPN5r4s8=;
b=d8dmNDW4J8DXX5nrBrmj3gVbPgXdAK30XscFG4NtIPsOuLyJi2fF61YAwA53b7EGkz
sm43V2agb21Mrp9dNVrpQflprrc35fRVSr9gIryU7LgP7c/hCW53Wyrahs71fhZB253P
adVLEyYQPjDwPzEc+ODSI4JV9eNlT3BygUJcDz0eznCETorxwNojVIoZ4H/2QDh++kLn
IyggIh4U+KVaD5sTad7VJxwnK7uZbk1o95k9kbFLo2UJSpvJ85/TCWplKA/hcwupZtmK
AsZYKbEcAJrKILmUiINAC3y0NADk44RNDfHpEcQPStBQ+6+O0M3hOO2K0TTRvKdEl1iD
wlyQ==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@mattcorallo.com header.s=1750778463 header.b=asLfboNr;
dkim=pass header.i=@clients.mail.as397444.net header.s=1750778466 header.b=C+20759k;
spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99])
by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-5019e0516absi464930173.5.2025.06.24.08.54.10
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 24 Jun 2025 08:54:10 -0700 (PDT)
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99;
X-DKIM-Note: Keys used to sign are likely public at
X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and
X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>)
id 1uU5yK-002Zgw-18;
Tue, 24 Jun 2025 15:54:08 +0000
Message-ID: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
Date: Tue, 24 Jun 2025 11:54:02 -0400
MIME-Version: 1.0
Subject: Re: [bitcoindev] What's a good stopping point? Making the case for
the capabilities enabled by CTV+CSFS
To: Antoine Poinsot <darosior@protonmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
X-Original-Sender: lf-lists@mattcorallo.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@mattcorallo.com header.s=1750778463 header.b=asLfboNr;
dkim=pass header.i=@clients.mail.as397444.net header.s=1750778466
header.b=C+20759k; spf=pass (google.com: domain of lf-lists@mattcorallo.com
designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com;
dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
Thanks, responding to one specific point:
On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> Yet another alternative is a set of more powerful capabilities, enabling the use cases that "commit to next transaction"
> and "verify a BIP340 signature for an arbitrary message" enable and more. For instance replacing "commit to the exact
> transaction which must spend this output" with "programmable introspection on the spending transaction's fields" has
> been considered. However this approach increases implementation complexity and broadens the risk surface[^8]
Responded to below [1]
> which
> warrants a compelling demonstration that arbitrary transaction introspection does enable important use cases not
> achievable with more minimal capabilities.
I'm somewhat skeptical that showing this isn't rather simple, though I admit I've spent less time
thinking about these concepts. ISTM even something as simple as a rate-limit requires more
full-featured introspection than only "commit to the exact next transaction" can provide. For
example, a trivial construction would be something which requires that transactions spending an
output have an output which claims at least Amount - Rate, which requires both more full-featured
introspection as well as a bit of math. Given one of the loudest groups advocating for the
additional features of CTV+CSFS are enterprise or large-value personal custody providers, it seems
somewhat of a loss to not work our way towards really basic features for this use-case.
More generally, more full-featured introspection like TXHASH provides a lot of flexibility in the
constructs people can build. For example, allowing BYO fees in the form of an additional input +
output in a transaction, rather than fixing an anchor output in the fixed "next transaction"
commitment to allow for fees (and then requiring the same additional input + output later). There's
also open questions as to the incentive-compatibility of anchors in a world with expensive block
space, as OOB fees become much cheaper.
Indeed, ISTM many use-cases for a construction like TXHASH become a lot more substantial with Math
(though, again, I spend less time thinking about the use-cases of these things than most, so I'm
sure others have more examples), I'm quite skeptical that *just* looking at an individual fork on
its own is the right benchmark. Sure, functionality in proposed changes to Bitcoin's consensus need
to be well-justified, but they don't need to be well-justified *purely on their own*. We add things
like OP_SUCCESS opcodes in soft forks specifically to expand the set of things we can do later, not
specifically in this fork.
If we assume that we end up wanting things like velocity limits (which I imagine we would?) then it
seems to me we should do a logical fork that adds features today, but which will allow us to make
minimal extensions in the future to further expand its use-cases later. Taking a more myopic view of
the present and ignoring the future results in us doing one thing today, then effectively replacing
it later by adding more flexibility in a new opcode later, subsuming the features of what we do
today. I don't see how this results in a net reduction in risk to Bitcoin, rather just means more
total work and more cruft in Bitcoin's consensus.
[1]
Responding to the MEVil question OOO because I think the above should go first :).
Indeed, more flexible introspection provides for a difference in risk to the system (though its
worth noting we cannot both argue that there is no "demonstrated utility" *and* that the utility of
a change is so substantially higher that it adds material risk to the system in the form of MEVil
from its use-cases). However, given the uses of the Bitcoin chain today, it seems entirely possible
(assuming sufficient adoption) that we end up with a substantial MEVil risk with or without any
functionality expansion. This mandates a response from the Bitcoin development community in either
case, and I'm confident that response can happen faster than any reasonable soft fork timeline.
While its possible that existing CSV-based MEVil risk never grows beyond its current anemic state
(due to preferences for stronger trust models from their users), and that there's a particularly
clever design using expanded introspection that improves the trust model such that suddenly
CSV-based protocol use explodes, ISTM given the risk and the need to mitigate it on its own, taking
decisions that are sub-optimal for Bitcoin's consensus on this basis isn't accomplishing much and
has real costs.
Matt
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.com.
|
