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
|
Delivery-date: Mon, 18 Nov 2024 10:36:36 -0800
Received: from mail-yb1-f192.google.com ([209.85.219.192])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCY3VBMZVAMRBKUS524QMGQEZCRCTMQ@googlegroups.com>)
id 1tD6bz-0007Jl-FL
for bitcoindev@gnusha.org; Mon, 18 Nov 2024 10:36:35 -0800
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e3886f4cee2sf2183768276.0
for <bitcoindev@gnusha.org>; Mon, 18 Nov 2024 10:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1731954989; x=1732559789; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=WqG4mMqNJW2pcZdfv3TOruqva0tcV66C6C0MO4Ej+Xo=;
b=iBT5ZEIRPMuYpsRt5acjxVB7KPzGp9beJhKsMFCppu1Ike5bbjYfNgsmk79NokmSqI
q3nt0LydTL9AZUzIkudGs7UTZH/rO5j0R00/gFiSyrUfqG2TjaybQ3jXCgIqTwsqkr1G
n1d4iToHU+dKhXoSi/Jve4Xi89XiuPLOl2kQ/Qw+KL4P0x1WmVsOpMXa1RUMZp17+W5V
xuoLyPm+vHbF5Mb1Xo0yWGaAsLpAlAYiTQAAKP9kufI81d0AUTMDQN78JlXKth43zQi/
7lgHz/rLvjTmhWL6R0BRJd1SZI2lhsBlNvHS8Y1DNxov3Jms12OrpwG1s9d37CPqwGkb
dRGg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1731954989; x=1732559789; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=WqG4mMqNJW2pcZdfv3TOruqva0tcV66C6C0MO4Ej+Xo=;
b=cfBrx3CJDsAXORiyOdYr8yjLmzSwYPSsVM+eM9t+D4CgB7yz9zdna+WuzYf/TOAufS
DepCOKC3uYQzVZ7TSuodsaow0GRnwL6bsuRp27WEm9diZlMBVoOpeXPdATBIvaMlJA5b
5dtNaFe357RJue9sHbJNTbvHRZtPM/YUj2htGYMtAUloPO0/aDfLR/A8Ty0UAQ/iH6Le
OTDz21NLmb3Y7XQevmKIzus08E3NY2+i/qspCMJJsOk0gkVxZ6GC1Fxl7UlqjAdbkwYV
RpkEx5mRArRSKVNcp4z0NYGZIt5D8nChmFqH883501TyITFajqyRJp0YQwgEbiNBH75r
+GEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1731954989; x=1732559789;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=WqG4mMqNJW2pcZdfv3TOruqva0tcV66C6C0MO4Ej+Xo=;
b=NXIhpLWY+PDuyPcY+RW7HoAvVRgNz5dCYr6NTFLxRihOzllQM0vqm/vQQM2COoUmQU
JBRnuoJ8sUJrDd58CSXxv+nJnhY6ShsWRqgDuTybMA0sOxQEEDoXLXxmjUFmlBx2K2dR
t9992hOLfYsOUH33rUDEzw6Ry31zy96k4uLx6nkhk2dn+hVCrT3Yce6CvlCu3VCBYhHo
AXEMVzjnooosd8Q1D0K5OpYooTWyKckTuscUaL6qGllj6aoqx21ItoIM2fZCBhMKN11M
p2Zt8uU5sxKZ48Z1MDuIuddugxWJo3VTPnOTySAMseePcDqS8ohxgxHhJ4q51YGLfTkE
HSzQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUw5gJ0pLj2ASMccbvC9uN7f07tlikZQqhxNk9qacgk8cXFcwKvSsv/L/7K0/yWGGfDI2AWyToPreTJ@gnusha.org
X-Gm-Message-State: AOJu0YzJJ9jmeiEwiCXRxKdaRnH4L8G67fDOyTzWq6aw2bAC7jCaV/T7
H85Tbz5GNlp0LpeYee5hI9oPfRDr7+2ZEMUA2WmZMOGs6BPVZ+5V
X-Google-Smtp-Source: AGHT+IGE7QO7GdIpwQ6F2bXLnIiFgm6kbsP7n9ZjrWry5YdnXRDQ6+Bq2zEKF7eOjbAS/TMaCFE1Ng==
X-Received: by 2002:a25:b29c:0:b0:e38:2b99:7f2d with SMTP id 3f1490d57ef6-e38b77ee737mr426155276.12.1731954988774;
Mon, 18 Nov 2024 10:36:28 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:d886:0:b0:e30:cb77:2e86 with SMTP id 3f1490d57ef6-e387e6a2d17ls956600276.0.-pod-prod-05-us;
Mon, 18 Nov 2024 10:36:25 -0800 (PST)
X-Received: by 2002:a05:690c:a86:b0:6e3:15ad:a560 with SMTP id 00721157ae682-6ee55be2712mr131877977b3.12.1731954985656;
Mon, 18 Nov 2024 10:36:25 -0800 (PST)
Received: by 2002:a05:690c:dd4:b0:6dd:c9c1:7a16 with SMTP id 00721157ae682-6ee56bff1c8ms7b3;
Mon, 18 Nov 2024 07:10:18 -0800 (PST)
X-Received: by 2002:a05:690c:9b10:b0:6e5:d35b:ca80 with SMTP id 00721157ae682-6ee55a2f663mr100000737b3.5.1731942617024;
Mon, 18 Nov 2024 07:10:17 -0800 (PST)
Date: Mon, 18 Nov 2024 07:10:16 -0800 (PST)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <3b2707fe-0ddd-4c1a-8167-fccef47a9d2en@googlegroups.com>
In-Reply-To: <4235f7d2-8e09-428a-813d-9034cb21f48an@googlegroups.com>
References: <4235f7d2-8e09-428a-813d-9034cb21f48an@googlegroups.com>
Subject: [bitcoindev] Re: Multi-byte opcodes
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_230262_456130746.1731942616563"
X-Original-Sender: garlonicon@gmail.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.5 (/)
------=_Part_230262_456130746.1731942616563
Content-Type: multipart/alternative;
boundary="----=_Part_230263_858273540.1731942616563"
------=_Part_230263_858273540.1731942616563
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> I think we need a way to allow more opcodes without taking up the rest of=
=20
the NOPs.
It is already possible since Taproot. For example: OP_CHECKSIGADD was=20
added, without replacing any OP_NOP.
> I feel that someone must have brought this up before (but it is a little=
=20
bit hard to find the history in this mailing list at this moment).
Satoshi added OP_SINGLEBYTE_END, set to 0xf0, and OP_DOUBLEBYTE_BEGIN, set=
=20
to 0xf000. It was removed later, but it can be reintroduced in a similar=20
way, if needed. See source code for version 0.1.0 for more details.
sobota, 16 listopada 2024 o 03:00:53 UTC+1 Weikeng Chen napisa=C5=82(a):
> I think we need a way to allow more opcodes without taking up the rest of=
=20
> the NOPs.
>
> This is related to a point from Murch (
> https://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAjSdCgAJ) that=
=20
> the reasoning of "its' compatible, why not" for adding=20
> CHECKSIGFROMSTACK(VERIFY/ADD) is not solid because when we add a new=20
> opcode, we usually have to give up a NOP. We do not have many NOPs left.
>
> We can, however, solve that by allowing multi-byte opcodes.
>
> Say, for example, we can have:
> OP_OP { 0x1521 }
> which will set the current opcode to be the one with the assigned number=
=20
> 0x1521.
>
> Another idea is maybe OP_OP takes a stack element as the opcode.
> { 0x1521 } OP_OP
>
> We can enforce some sort of minimal rule, or not do so, to allow more=20
> flexible use of existing opcodes.
>
> This, of course, runs at a cost as this opcode needs three bytes in total=
=20
> to represent, but since the existing opcodes already take care of most of=
=20
> the basic functionalities that we expect users to use very frequently, th=
e=20
> new opcodes that we want to add are likely those that complete something=
=20
> important and are going to be used only a few times in a script.
>
> Similarly, we can require that multi-byte opcodes that have not been=20
> enabled my result in OP_SUCCESS.
>
> OP_OP is not the best name as it could be confusing. OP_SETOP, OP_NEXT,=
=20
> etc could be taken into consideration.
>
> The result of this is that we can worry less about whether it is worthy o=
f=20
> a NOP to do an opcode, but focus on if the opcode has enough use cases to=
=20
> support it.
>
> I feel that someone must have brought this up before (but it is a little=
=20
> bit hard to find the history in this mailing list at this moment).
>
> What do people think?
>
> Thanks,
> Weikeng
>
--=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/=
3b2707fe-0ddd-4c1a-8167-fccef47a9d2en%40googlegroups.com.
------=_Part_230263_858273540.1731942616563
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> I think we need a way to allow more opcodes without taking up the rest=
of the NOPs.<br /><br />It is already possible since Taproot. For example:=
OP_CHECKSIGADD was added, without replacing any OP_NOP.<br /><br />> I =
feel that someone must have brought this up before (but it is a little bit =
hard to find the history in this mailing list at this moment).<br /><br />S=
atoshi added OP_SINGLEBYTE_END, set to 0xf0, and OP_DOUBLEBYTE_BEGIN, set t=
o 0xf000. It was removed later, but it can be reintroduced in a similar way=
, if needed. See source code for version 0.1.0 for more details.<br /><br /=
><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">sobota, =
16 listopada 2024 o=C2=A003:00:53 UTC+1 Weikeng Chen napisa=C5=82(a):<br/><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>I think we ne=
ed a way to allow more opcodes without taking up the rest of the NOPs.</div=
><div><br></div>This is related to a point from Murch (<a href=3D"https://g=
roups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAjSdCgAJ" target=3D"_blan=
k" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dpl&q=3Dhttps://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAj=
SdCgAJ&source=3Dgmail&ust=3D1732028955061000&usg=3DAOvVaw0JqvB2=
WMH4Tm3ZwjIJxxdc">https://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hh=
tvAjSdCgAJ</a>) that the reasoning of "its' compatible, why not&qu=
ot; for adding CHECKSIGFROMSTACK(VERIFY/ADD) is not solid because when we a=
dd a new opcode, we usually have to give up a NOP. We do not have many NOPs=
left.<div><br></div><div>We can, however, solve that by allowing multi-byt=
e opcodes.</div><div><br></div><div>Say, for example, we can have:</div><di=
v>=C2=A0 =C2=A0 OP_OP { 0x1521 }</div><div>which will set the current opcod=
e to be the one with the assigned number 0x1521.</div><div><br></div><div>A=
nother idea is maybe OP_OP takes a stack element as the opcode.</div><div>=
=C2=A0 =C2=A0 { 0x1521 } OP_OP</div><div><br></div><div>We can enforce some=
sort of minimal rule, or not do so, to allow more flexible use of existing=
opcodes.</div><div><br></div><div>This, of course, runs at a cost as this =
opcode needs three bytes in total to represent, but since the existing opco=
des already take care of most of the basic functionalities that we expect u=
sers to use very frequently, the new opcodes that we want to add are likely=
those that complete something important and are going to be used only a fe=
w times in a script.</div><div><br></div><div>Similarly, we can require tha=
t multi-byte opcodes that have not been enabled my result in OP_SUCCESS.</d=
iv><div><br></div><div>OP_OP is not the best name as it could be confusing.=
OP_SETOP, OP_NEXT, etc could be taken into consideration.</div><div><br></=
div><div>The result of this is that we can worry less about whether it is w=
orthy of a NOP to do an opcode, but focus on if the opcode has enough use c=
ases to support it.</div><div><br></div><div>I feel that someone must have =
brought this up before (but it is a little bit hard to find the history in =
this mailing list at this moment).</div><div><br></div><div>What do people =
think?</div><div><br></div><div>Thanks,</div><div>Weikeng</div></blockquote=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/3b2707fe-0ddd-4c1a-8167-fccef47a9d2en%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/3b2707fe-0ddd-4c1a-8167-fccef47a9d2en%40googlegroups.com</a>.<br />
------=_Part_230263_858273540.1731942616563--
------=_Part_230262_456130746.1731942616563--
|
