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
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
|
Delivery-date: Sat, 27 Sep 2025 06:23:05 -0700
Received: from mail-ot1-f64.google.com ([209.85.210.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+bncBAABBL6K37DAMGQE72IWGRQ@googlegroups.com>)
id 1v2UtF-0007F0-60
for bitcoindev@gnusha.org; Sat, 27 Sep 2025 06:23:05 -0700
Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-79d4b65f161sf1995076a34.2
for <bitcoindev@gnusha.org>; Sat, 27 Sep 2025 06:23:04 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1758979379; cv=pass;
d=google.com; s=arc-20240605;
b=OUbSEWF+x04VkZrBnwCCsNaEGrrjeHtFSOtbv53OReqqZqHJO9LQ1VT2Cx046OyNxe
1yVlmIjWj37AK6ddN8dSJNCyXO7WU70n+2KIbqC0EDSvdQAncNvCCXzEtOQjkLWxaAO8
grFjQjux79QdLzCTbbH59FiBCL/snFCm3XlgqQZhRRE0rMgWyL23fIyvzjFNyeRfZ8pL
UYMxIB/VBqDwRgBMMnfQfBNJLQ2xrsLk1e9D+ks1aCbbYfX9SdPznVTxZ0oOpsQbwIGu
elp05oQ6MdbmrGbGCr23DQ0NgGheL17nWkvaHqvGpSexejDn8rUmKLdbPST7sG5sN5nI
XUiA==
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:content-transfer-encoding
:mime-version:message-id:date:in-reply-to:subject:cc:to:from:sender
:dkim-signature;
bh=px0SM/V/fXKuorddT0u1UdD0UAp3dXO9vPkcvO9+jeI=;
fh=XokK81rsy3kMOf8hr85d9R9I4S7B8dq750jGd74wCIA=;
b=JIldcxKhUbGqkxB1Hbpk9jfxgNcywbgGPDWatuVvyDw1fJMVvlxazKyZQecT8LhQqq
eW+sxvxOdaYsznGoXrmfK1b9rb15/sCjooUR0JWq4axmWCpfDHOLPGyeqYkw9L1uaq4D
sZxQYPNU9h/a4ysJcRJIc2vtyORy0vRRxsiJU1bARPzbT9Jz1d29h+1ObDbPoyX9k7x/
t28UJem562L/lpW7DlOGvOjHJkoHcvpRBQbjSPv8vFve881S347YZ1uS/Vt/lmLrHwCc
84hO6WHnZ2VBlNNDe4aVE2JqTpWk9YVodtnpkkGmC5w/GumjbXkTacZOoFG+iijUHwWt
wLvg==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@rustcorp.com.au header.s=202305 header.b=RDCK2Vyi;
spf=pass (google.com: domain of rusty@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) smtp.mailfrom=rusty@gandalf.ozlabs.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1758979379; x=1759584179; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:content-transfer-encoding
:x-original-authentication-results:x-original-sender:mime-version
:message-id:date:in-reply-to:subject:cc:to:from:sender:from:to:cc
:subject:date:message-id:reply-to;
bh=px0SM/V/fXKuorddT0u1UdD0UAp3dXO9vPkcvO9+jeI=;
b=u750zQ7qmZzhkvAcPQOuRD4VF7P+I0qv1sglqduMv0+gV6ykZRYiLN5RWcKI8Ej36k
ePXN97U7eXvELzTTtq402zOVcVP7KzaEFytLxSh0hCCv5M3OqiWJjuoXRpixi+4FAwYt
U2Xmbb0LyFCgiehj9ypz1TLyM5+FnppkZOCTDvm7rduNKf428yhWRSOjONBcqDIYOvou
XBSs3ZzPH8Nd05/XEGlSR3FM7F5tx8DYpSxr+xHfpceplS4vzk1N3GX0aFMUp6pUjBHt
lLqguRO7qxISop7CRXlX0bsosqj/pXGFN29a/gVCAYasPiswdm+xUXgQzQLPZk0o7QOk
T5eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1758979379; x=1759584179;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:content-transfer-encoding
:x-original-authentication-results:x-original-sender:mime-version
:message-id:date:in-reply-to:subject:cc:to:from:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=px0SM/V/fXKuorddT0u1UdD0UAp3dXO9vPkcvO9+jeI=;
b=B4AktquzfY9J4qajEolz+BT2SdEPQtgHDh3J9HrEKy7fnS8UO03xrqhoKloUUtJ6+f
Nb/kq1MfCdzP2pew5yYTGGEqh4zp91Vlr5GUYzZgu6//d7+vi6foLgqMPciXQN9mloLQ
txcKrR6StyprDrkr4/5GUuLZ2DCI1UIJUU4XBX8KUc40VGPUlOuD8v6IczIl5QJdqtMA
uh7ND0giDmS2iAjgNyli5Ky1LJbmVhYQjDYDFr8Pa6Ic8nHDCzTqqp/ljKYE8uieWnrX
lQFfC8JAjod96Jezx3tRgOYwh3phMW4NtFze2r0i3FnxCYPyrxikKUOf6FjBOBAaC0Nm
IVuA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWAlIupt+7+4uas3+GpA4elGfzXUiDyeu/E5yolmom8KSDC2ETXQc/mCit2xCnw/3OtWv+m7j3pXk3d@gnusha.org
X-Gm-Message-State: AOJu0YwQHp5s4ca1oFR/qFvfzMX4X8xJL69jAFasKA7KjxXpZ+vtKt15
qUBSIpOlvvQGG4zA9HwQae2dsQyumqQxG0SczVB+pVPOPOqyYIsGs0bR
X-Google-Smtp-Source: AGHT+IFHYeGaGQnshy/3X8IVQr3XyeHYwstwlDpf4ejO7FG99BjLO27Uo/pPReSh5eaHM+aZCLBShw==
X-Received: by 2002:a05:6870:9a10:b0:315:b513:a6ef with SMTP id 586e51a60fabf-35eec27afd4mr5186003fac.43.1758979378672;
Sat, 27 Sep 2025 06:22:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5HpifCAtHjU2oE3D5nbdKb35snnsmtQpWp/xoymDUTgg=="
Received: by 2002:a05:6870:ac24:b0:34e:7f9a:dbf4 with SMTP id
586e51a60fabf-35ef15012bels1108533fac.2.-pod-prod-06-us; Sat, 27 Sep 2025
06:22:55 -0700 (PDT)
X-Received: by 2002:a05:6808:4f4e:b0:43f:1e42:9e89 with SMTP id 5614622812f47-43f4cef4a66mr6028075b6e.45.1758979375369;
Sat, 27 Sep 2025 06:22:55 -0700 (PDT)
Received: by 2002:a05:6808:22c9:b0:438:241d:e72f with SMTP id 5614622812f47-43f5e412992msb6e;
Sat, 27 Sep 2025 04:29:55 -0700 (PDT)
X-Received: by 2002:a05:6808:144b:b0:43f:6bd2:3a57 with SMTP id 5614622812f47-43f6bd23d43mr1267677b6e.20.1758972595076;
Sat, 27 Sep 2025 04:29:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1758972595; cv=none;
d=google.com; s=arc-20240605;
b=LcwOA34cAScjScHS/0Wjj/+qsI4HF4Nv+k8bD/IEFlKkWwnqoBmIxiSgmeJBgpJp10
DB+lKMfs+AhkMtaZPA3qzTKbBgFECf/1Y87hPODcq/0uCPobRmhL55xEasqXjlPycoiC
s3c5fFWNttBmbS6a7Op8sWkHUc4/OVweZWazdjKXeDtZNerO0GijZiUT6uCRKuak0qar
8MNycGrulOXngpqHLRkdm+royGLlsrNYvViH1HXPs2VWQ6ScSTpG0fv4K/Xgk47Uwdzd
UlbwM9wBt/OY1Z6OOEip3l9tuqDqIebuzGeOETFR3Po01ZxIJWGtrxhOkygTjdkt/Ouj
Ph1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=mime-version:message-id:date:in-reply-to:subject:cc:to:from
:dkim-signature;
bh=uKMUfQ2RukOIj4skc0Ei7ZxMCAKiyK47+hBIYv/eYbQ=;
fh=VKRDeyaA3Okg5Ur9YeEuvs3adnjn1Zay82pjgmdy54E=;
b=a+N77RnQPI5XPpcuZLC4cqH95UPFEj3hsXZpXtxLJJcnfpx/itAw84sCqug/xwzIZk
qGNUwTHA5XQzJQVzAY94VCLgoq9rrgV/oN2HT4HQjP8oX4cSxmRnCAs/vHGvQLpTUm6i
1Ipx4Qa049i+nVy/dZO/UVF9NffvAzmfu5E0tisUMpmoC+Pxu4fjhD/TQCBBGFGG3vcO
59Z8f8Rzh9FLkOLLGtWq/7bH+DI3jTv/l6BWIi5ij8dqVKouFk2XrAmUE2AU24deT35f
JzeBbFZZQ4RQ2iIJO2EUhMnGHHNS3HHZQlGO1H7NZIe9RDDki9SVxzMu2pWc66NzL/Dz
iH9A==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@rustcorp.com.au header.s=202305 header.b=RDCK2Vyi;
spf=pass (google.com: domain of rusty@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) smtp.mailfrom=rusty@gandalf.ozlabs.org
Received: from mail.ozlabs.org (gandalf.ozlabs.org. [150.107.74.76])
by gmr-mx.google.com with ESMTPS id 5614622812f47-43f511fc06csi293356b6e.3.2025.09.27.04.29.54
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 27 Sep 2025 04:29:54 -0700 (PDT)
Received-SPF: pass (google.com: domain of rusty@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) client-ip=150.107.74.76;
Received: by gandalf.ozlabs.org (Postfix, from userid 1011)
id 4cYlby5VXkz4w9f; Sat, 27 Sep 2025 21:29:50 +1000 (AEST)
From: Rusty Russell <bitcoin-dev@rustcorp.com.au>
To: bitcoindev@googlegroups.com
Cc: Julian Moik <julianmoik@gmail.com>
Subject: [bitcoindev] [4/4] New Opcodes for Tapscript v2
In-Reply-To: <87y0q0m8vz.fsf@rustcorp.com.au>
Date: Sat, 27 Sep 2025 20:59:40 +0930
Message-ID: <87tt0om8uz.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Original-Sender: bitcoin-dev@rustcorp.com.au
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@rustcorp.com.au header.s=202305 header.b=RDCK2Vyi; spf=pass
(google.com: domain of rusty@gandalf.ozlabs.org designates 150.107.74.76 as
permitted sender) smtp.mailfrom=rusty@gandalf.ozlabs.org
Content-Transfer-Encoding: quoted-printable
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 (/)
Hi all!
Now for the least polished BIP, which proposes a scattering of new
opcodes. These need not be deployed at the same time, and some may not
ever qualify. But as they they might have interactions with other
proposals, I feel we are obligated to peer over this horizon a little.
Many of these are not mine, and I definitely feel remiss in not
giving canonical references (I would appreciate this feedback!).
Thank you for you consideration!
Rusty.
<pre>
BIP: ?
Layer: Consensus (soft fork)
Title: New Opcodes for Tapscript v2
Author: Rusty Russell <rusty@rustcorp.com.au>
Comments-URI: TBA
Status: Draft
Type: Standards Track
Created: 2025-06-17
License: BSD-3-Clause
</pre>
=3D=3DIntroduction=3D=3D
=3D=3D=3DAbstract=3D=3D=3D
This BIP proposes several new opcodes for tapscript v2, to take full advant=
age of scripting enhancements and covenant facilities offered by OP_TX.
=3D=3D=3DCopyright=3D=3D=3D
This document is licensed under the 3-clause BSD license.
=3D=3D=3DMotivation=3D=3D=3D
Restoration of opcodes and introspection make script much more useful, and =
thus increase the range of things we may want to do. This, in turn, highli=
ghts some existing shortfalls in Script, both in the way it handles multipl=
e stack objects, and when attempting to reproduce modern Taproot constructi=
ons.
This list of opcodes is not exhaustive, but each offers some significant ca=
pability which was previously impossible or extremely awkward in script.
A key motivation for these changes lies in future possible BIPs: once scrip=
t is well-rounded (if not "complete"), most proposals will be optimizations=
, whose benifits can be quantitatively assessed based on actual usage.
=3D=3DNew Opcodes=3D=3D
;OP_CHECKSIGFROMSTACK
: A subset of OP_CHECKSIG. With OP_TX and OP_SHA256 we have the part of CH=
ECKSIG which obtains and hashes parts of the transaction. What remains is =
being able to check a signature against a hash on the stack. OP_CHECKSIGFR=
OMSTACK provides this. The varops cost is the same as a CHECKSIG operation=
.
;OP_SEGMENT
: This opcode remains an NOP. But it makes script parts ''composable'': cu=
rrently you cannot append two scripts, because OP_SUCCESS causes immediate =
success without script evaluation. OP_SEGMENT changes this rule to ''segme=
nt'' the script into parts, which are evaluated in order. If a segment doe=
s not have OP_SUCCESS, that part of the script is evaluated. This allows a=
transaction to ensure some condition is met, but also allow arbitrary scri=
pt conditions thereafter.
;OP_BYTEREV
: This is the minimium requirement for constructing ordered Merkle trees as=
specified in Taproot. Unfortunately, hashes need to be compared left to r=
ight, where Script opcodes operate right to left (as per little endian numb=
ers). Alternatives would be a direct OP_REVCMP opcode, or even a dedicated=
Merkle opcode, but byte reversal can be generally useful.
;OP_ECPOINTADD
: Also required for constructing Taproot spends. The varops cost is the sa=
me as a CHECKSIG operation.
;OP_INTERNALKEY
: An optimization: an unspendable keypath for Taproot simply wastes space. =
If this is not changed in a future version, OP_INTERNALKEY at least allows=
the script to use this data for something else. An alternative would be a=
nother OP_TX ''selection_vector'' bit. See [[bip-0349.mediawiki|BIP-349]].
;OP_MULTI
: Several opcodes would benefit from a variant which takes the number of op=
erands off the stack. Instead of introducing many more opcodes, we propose=
OP_MULTI as a prefix to the following opcode which pops a number off the s=
tack, and makes the next opcode operate on more than its usual number of op=
erands: OP_CAT, OP_ADD, OP_SHA256, OP_DUP, OP_DROP, OP_MIN, OP_MAX, OP_AND,=
OP_OR, OP_BOOLAND, OP_BOOLOR, OP_EQUAL. This is simpler than introducing =
general iteration into script, and intuitive to constrain using varops. It=
is particularly beneficial when examining inputs or outputs of a transacti=
on, such as calculating fees.
=3D=3D=3DRationale=3D=3D=3D
Bitcoin script was developed long before Taproot: OP_ECPOINTADD and OP_BYTE=
REV are the minimal missing opcodes required for creating Taproot trees in =
script. The need for OP_CHECKSIGFROMSTACK and OP_SEGMENT are a side-effect=
of generic introspection, into the tx itself for arbitrary signature cover=
age, and into scripts to allow specification of partial spending requiremen=
ts. OP_INTERNALKEY is trivial, but can save 32 weight on a transaction in =
many cases, which is a non-trivial savings. OP_MULTI is more complex, but =
allows for much more general handling of multiple inputs or outputs: bitcoi=
n script does not have iteration, so all possible numbers have to be handle=
d directly, which is unwieldy at best.
There are definitely other opcodes which would be helpful, but from this po=
int most are "merely" optimizations from what is now possible. This itself=
is a major milestone: that future opcode proposals can be assessed numeric=
ally, by measuring the impact they would have on aggregate onchain space, a=
nd from there assessing whether the cost of implementation and deployment i=
s worth the savings.
=3D=3D=3DDetailed Specification=3D=3D=3D
TBA.
=3D=3DReference Implementation=3D=3D
None as yet.
=3D=3DTODO=3D=3D
- Are there other fundamental building blocks we are missing? I don't see =
an immediate reason for OP_ECPOINTMUL, for example, but it would not be pos=
sible in script today (due to varops limits).
- If we do want OP_INTERNALKEY, it should probably be a OP_TX selector bit.
- Is OP_MULTI too ambitious? I previously considered for-each-input and fo=
r-each-output iterators, but this is far simpler.
- Can we come up with a better name for OP_CHECKSIGFROMSTACK? Unfortunatel=
y OP_CHECKSIG is taken, but OP_THE_REAL_CHECKSIG isn't!
=3D=3D Footnotes =3D=3D
<references />
--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
87tt0om8uz.fsf%40rustcorp.com.au.
|
