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
227
228
229
230
231
232
233
234
235
236
237
238
|
Delivery-date: Mon, 23 Jun 2025 06:26:28 -0700
Received: from mail-oa1-f64.google.com ([209.85.160.64])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDL4XL646QOBB6NL4XBAMGQEJOJUKAA@googlegroups.com>)
id 1uThBr-0007oc-BK
for bitcoindev@gnusha.org; Mon, 23 Jun 2025 06:26:27 -0700
Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-2e954a1d239sf3684774fac.1
for <bitcoindev@gnusha.org>; Mon, 23 Jun 2025 06:26:27 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1750685181; cv=pass;
d=google.com; s=arc-20240605;
b=A+FiOv0KzSdSt/bwr/Q/s0OJsF7plh6NF1GAqd49+5Nt5bq1irNB7gJM9Kq5g0hBcq
eOuqYLq43NmOmSqnvMcFjJ7qXxNRIH0i9He+o2mHama02GEz5/kDyRYbN61jm6lytlC4
7lUkQpvey1tJPnmjfG0GLm+mySHoRuAXWoxpPYjypcZRIaNjatffF2aD7BFAUZ6xXEVU
a4EdV2513YW2iala3LxHC+5rW68o2DUVGf3GYj2h1jcU79bUa2YvB0jkpRzrBFXjqsu9
BQxuPhzAizyuXTKsD6dJRe9TTIbuYYv6b+5OJ2Bvf0C+dTfO7nuGmcBCJ3vnSSK8ZcxE
9n3g==
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:reply-to:mime-version:feedback-id
:message-id:subject:from:to:date:dkim-signature;
bh=zD4IRnxheqENaTne8w8qUVxyFgX1r1QYTbATI7BAPG0=;
fh=TA5esPfD/x5aXc0iy5Ay9DxxvmvM3PYKM+GA6TBZ0Bg=;
b=UjkaMANr5jD3k5s68vnH0dsuo8ZRWtGyavkXw4nhg5wOk2wYz/GWto7GaM7LHYR9vi
lSU+R4Vhh5uGG3Wvbem900OEywzOIvL0vYqsR5GGbHSimPnddXYvGNaaxV8ThVcMUysw
h1TkNrABkZJ0YkJ5e1X6wKSaqighdXIrBJOeTmOcO5mYx2lIka1r5d4LL19V5QRkJELX
ZIy/jVsnp/qyjx5fC2x55ZSEPlxImNMDylG3K7+3Su9nvxS6jSPtvs4bVgWJJBCjIlu9
TiLnslsKgvY4U3h0ZT8HGW8rYe89vg5GbEQMBEPdG2WWWNJBJX7KVnpTGvhX6bVsXgmY
xjmA==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=xdUCYcIg;
spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1750685181; x=1751289981; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:reply-to
:x-original-authentication-results:x-original-sender:mime-version
:feedback-id:message-id:subject:from:to:date:from:to:cc:subject:date
:message-id:reply-to;
bh=zD4IRnxheqENaTne8w8qUVxyFgX1r1QYTbATI7BAPG0=;
b=CLAiQR2Yi+9MDyu+6pRKTMWV2+8fHAXJ0DBC698BwVwKIaUrqTeG4SsgimRw96aWzv
fnsjAvmhLufHX2rxMCgoS0i8IAI5lC6GT6CJEgGPiDytmG1GpIS0zsiYgBJ+eWXOsGbx
gO6Q7A/uNc7g9gTRbbuInACz/NlLop4K0bUdDsq7aQIDixpBWs2Q1PiWNmNWfNE6JS3j
NOopT5oLSOlk3KDiHlnQ8tjRMgW2qz82zNpLgXLXa4vhmvok23H2dt6zvjCbfXXZfGyG
ClgM8trliXf3h8Xvya4DHJIG0+8MI+u1MnPZ/WqMNKEP9R9/0cpVDotQz5aLoQKeW6cG
Takw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1750685181; x=1751289981;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:reply-to
:x-original-authentication-results:x-original-sender:mime-version
:feedback-id:message-id:subject:from:to:date:x-beenthere
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=zD4IRnxheqENaTne8w8qUVxyFgX1r1QYTbATI7BAPG0=;
b=VivtkGLErNKUi+LbG0BX5THmq7TWW/84zhpuiaY+Hr6/SEEeCni25tTPfwNPkMEj9f
rr2Ag/kqfv1N1I2jwlattQPqUR3NlHiNKTUnqr2vP0o+0RfyCcaGmlQzUb0+LH4JTaIE
tYtyhuNCwMka6HFzRCNA+RkVNLwmEpqZlBzhqabdhzD2pm6LHmSU8LbkdIpsvhrS1zpj
r/zODOubU9yvdL+OVl6tsSerb1wy3MOdWNDCxoCSa+Pp2jT3DdR0sLfjqIIAXabvkiZT
C70j7mde9hg6mt/lGbCxOc3IoUhSAkG2imfXHSZV+HAw8RfTfbpRbJxW+Sy7XWPAnnDC
1bUg==
X-Forwarded-Encrypted: i=2; AJvYcCXSiPqjZkiTwf+xi1o/j8Osd4cuF5hjZDRvRFQq6+QpJFytuutjOuzwH/F9Khda8xR8hIGhW+yLeSSC@gnusha.org
X-Gm-Message-State: AOJu0YwA3QIg/xgp3NoMPXQiCB10t8IVE3g3XibWeGvfYzlhexX8AWTw
JlpqmoqOUoKKPIDX92T2fDD8mlUz2IDiKmJYAm9ZNuK4il6iLu9rmOWS
X-Google-Smtp-Source: AGHT+IFlzhqCJgOEgEW11MJewe8jCdEjaCcUTcjg5K7WQRe9ZV1Vnq/yPXgFDMo9s8psVriLGjwv5g==
X-Received: by 2002:a05:6870:d90b:b0:2d5:296d:4ed4 with SMTP id 586e51a60fabf-2eeee5573c8mr8227673fac.28.1750685180875;
Mon, 23 Jun 2025 06:26:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc+fyU6nM/pqHU1mKG6COxt8jTZqwUxdK1bce2pNomMxg==
Received: by 2002:a05:6870:ed95:b0:2ea:7154:1841 with SMTP id
586e51a60fabf-2ebacabeff6ls1731320fac.2.-pod-prod-03-us; Mon, 23 Jun 2025
06:26:17 -0700 (PDT)
X-Received: by 2002:a05:6808:2f15:b0:403:31f8:44c6 with SMTP id 5614622812f47-40ac6fb3c43mr10539003b6e.26.1750685177212;
Mon, 23 Jun 2025 06:26:17 -0700 (PDT)
Received: by 2002:a05:600c:35d3:b0:450:ce23:93de with SMTP id 5b1f17b1804b1-45358da89acms5e9;
Mon, 23 Jun 2025 06:14:37 -0700 (PDT)
X-Received: by 2002:a05:600c:3b8d:b0:441:d437:e3b8 with SMTP id 5b1f17b1804b1-453659f80c3mr103932445e9.23.1750684474586;
Mon, 23 Jun 2025 06:14:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1750684474; cv=none;
d=google.com; s=arc-20240605;
b=JpDKKdxbOvrIFHB6dg9zAuMzjQ6HY2m9mklfW5fpW/J5A/Cue1vX1vFHjqzcuw2l/f
V240juPdfzZp+DxBUxlFKir8+cJNR8R5tUIs3ifAiV2SFdy5Z/A8rf734N8WEzO7bD7g
89Y3Zp3WUBLmc3Ade39DizjDN2jvPgNNUeWOCXlWXG+HrSWsU8TxXhyjCxtT5Qcha+EC
q74tXhkrvUUyIX3hoEKE5Ol+jQR1o84zho0Omtld3kYMkC14Qe3pnG/pnEEQt98XMuMY
W2hBdgNdKkR9FtLSxa9wAV2VF0H+UP9edKue0Gem14rJQO+aEDRdGwIAaRvKXHf5g84P
lrlQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=content-transfer-encoding:mime-version:feedback-id:message-id
:subject:from:to:date:dkim-signature;
bh=mPnegMQD0LMjPNipfMtYwV1NyjdoYA7jZwyAj4fM4l8=;
fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
b=hbV/k0eNcUEe4sy2yIEQUK4IQsVXULh7/uweSZmAvNbOyrTkMSrWrUs32NdQgMP4GF
gIdgQ4tBEPFgR6Ox7R+M/YqCeS1DgiGktRAr7pLCnM7Yb7xzPuiaSxi+qol3fQVykiz6
F/YrZHPh2rLwUYHapU1s/W8mnEhuENPLo23/5rZ6NlvZuzYGzsNCgzb6tw5JPPg2nfp5
myIgASd/57VWwixLIQp8dvUpWmfZSFZIEWyC2InGIITLpLQH/2pV6fLUvvPgbV1Q8dWz
3bT/UFp7QnU2qI6uU0xJ2kEwWANxk/fbRPPNbsZ8+Ww1jyhNlm+9VWKxCY1gjahxAgGb
JQig==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=xdUCYcIg;
spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22])
by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4535e984052si2755385e9.1.2025.06.23.06.14.34
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 23 Jun 2025 06:14:34 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22;
Date: Mon, 23 Jun 2025 13:14:29 +0000
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Subject: [bitcoindev] What's a good stopping point? Making the case for the
capabilities enabled by CTV+CSFS
Message-ID: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 1956d62f2b83cfd4ce8096c8fd1146d244375825
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@protonmail.com header.s=protonmail3 header.b=xdUCYcIg;
spf=pass (google.com: domain of darosior@protonmail.com designates
185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -1.0 (-)
There is excitement in the technical community about a CTV+CSFS soft fork as specified in BIP119 and BIP348. We think
this combination of opcodes offers desirable capabilities to scale Bitcoin payments and is worth considering to soft
fork into Bitcoin. There has been several objections to this proposal, which we can group into three categories:
exploration of alternatives, demonstration of usage, and design of the operations to achieve these capabilities.
In an attempt to help the proposal move forward we would like to kick-off a discussion about the first category:
alternatives. We will start by making the case that the capabilities "commit to the transaction spending this output"
and "verify a BIP340 signature for an arbitrary message" are a good stopping point for a Bitcoin soft fork. We invite
anyone to share objections in reply to this thread so they can be addressed or inform a better course of action.
Let's keep the discussion focused on the capabilities, not the specific way of designing operations to achieve them. For
the sake of this discussion `OP_CTV` would be equivalent to `OP_TEMPLATEHASH` (push the template hash on the stack) as
the capability "commit to the transaction to spend an output". `OP_TXHASH` would be separate, as a "programmable
transaction introspection" capability.
The ability to commit to the exact transaction spending an output is useful to reduce interactivity in second-layer
protocols. For instance it can reduce roundtrips[^0] in the implementation of LN-Symmetry, or make receiving an Ark
"vtxo" non-interactive[^1]. Additionally, it enables significant optimizations[^2] in the implementation of Discreet Log
Contracts.
The ability to verify a signature for an arbitrary message in Tapscript enables oracle attestations and a form of
delegation. Oracle attestation for instance significantly reduce[^3] the onchain footprint of BitVM. Reducing an
application's onchain footprint benefits all Bitcoin users by easing block space competition, and it's especially
important for applications that generate very large transactions, which could otherwise increase pressure toward mining
centralization[^4].
Together, these two features enable a third capability: rebindable transaction signatures. Rebindable signatures make
possible a new type of payment channels, LN-Symmetry ("Eltoo"), whose simplicity makes practical advanced constructs
such as multiparty channels. They also enable further interactivity reduction in second layer protocols, as illustrated
by the Ark variant "Erk"[^5] or the dramatic simplification[^6] they bring to upgrading today's Lightning (i.e. without
switching to LN-Symmetry) from HTLCs to PTLCs.
These capabilities are simple and modular. They are well understood and present a low risk of enabling unwanted
behaviour. They do not increase the cost of validation, have low implementation complexity and are unlikely to become
redundant, even if more powerful capabilities are added in the future. These capabilities improve existing
tried-and-proven protocols used daily by Bitcoin users, like the Lightning Network. They also make new ones possible
either at all or through realistic interactivity requirements. The new enabled protocols take a similar approach to
existing Bitcoin scaling solutions, only with different tradeoffs not previously available. We can therefore reasonably
expect they won't introduce new systemic incentives, while broadening the range of supported use cases.
The first alternative approach to address is doing nothing. Doing nothing is *the* valid schelling point in a system
where consensus changes must be agreed on by a supermajority of the economic activity, and ideally by all stakeholders
in the system. Unless there is a critical vulnerability being fixed, the onus is on the proposer to overcome the various
valid objections. Further, a number of smart contracts have been deployed on Bitcoin and more are incoming, with or
without consensus changes. No softforks on the horizon are known to generate asymptotic scaling, and what's more,
on-chain demand has not been high except on infrequent intervals.
As said prior, we believe the capabilities of CTV+CSFS reach an appropriate bar for consideration for activation. While
it will not achieve asymptotic scaling, it will enable significant reduction in complexity in already-deployed systems,
and is worth deploying for their specific benefits. Regardless, it's important to emphasize it again: the onus is on the
proposer to overcome objections.
Other alternative approaches to scaling Bitcoin payments have been proposed such as with validation rollups[^7], enabled
by the ability to verify a zero-knowledge proof directly in Bitcoin Script. These rollups are trustless and could
effectuate a modest factor throughput increase under realistic assumptions and transaction load. This approach, used on
altcoins but new to Bitcoin, has yet to reach consensus among the technical community and Bitcoin users more broadly.
Relative immaturity of many of the employed crypto-systems make designing a ZKP-specific primitive a difficult task.
Further, trustless composibility with interactive protocols like LN to achieve further scaling are speculative at the
time. Nonetheless, the capabilities that enable this alternative approach to scaling are neither exclusionary nor
redundant with those proposed here.
It makes sense to focus first on capabilities improving the tried-and-proven approach, as the newer approach
(and the capabilities enabling it) may come with different tradeoffs.
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], which
warrants a compelling demonstration that arbitrary transaction introspection does enable important use cases not
achievable with more minimal capabilities.
Finally, a more radical alternative is to focus efforts to make Bitcoin smart contracts more capable with a sane
re-design of its scripting language. Similarly to the alternative of more powerful Bitcoin Script capabilities, it
remains to be shown that more expressivity is both safe and desirable. Furthermore, it is unclear that such an
undertaking would be achievable with the (very) limited engineering resources currently allocated to extending Bitcoin
scripting capabilities.
In conclusion, we believe the bundle of capabilities "commitment to the transaction spending an output" and "BIP340
signature verification of arbitrary message" to be the best direction for Bitcoin to take. These are well-understood,
simple capabilities, substantially improving an existing well-understood approach to scaling Bitcoin payments. This
direction does not preclude research into more advanced capabilities, though questions remain about their overall
desirability.
Antoine Poinsot & Greg Sanders
[^0]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
[^1]: https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528
[^2]: https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com
[^3]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
[^4]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8
[^5]: https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602
[^6]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/18
[^7]: https://github.com/john-light/validity-rollups
[^8]: https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev
--
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/F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI%3D%40protonmail.com.
|
