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
|
Delivery-date: Fri, 15 Nov 2024 18:00:59 -0800
Received: from mail-oo1-f62.google.com ([209.85.161.62])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCTP33FZ3YMBBUXZ364QMGQE3YXEY3Y@googlegroups.com>)
id 1tC87P-0006Y0-9B
for bitcoindev@gnusha.org; Fri, 15 Nov 2024 18:00:59 -0800
Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-5eb649aa7cesf992231eaf.3
for <bitcoindev@gnusha.org>; Fri, 15 Nov 2024 18:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1731722453; x=1732327253; 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:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=rXjWw2fGbPJHMhGr8t88vet0bQ4WWhz7aOvuTCABxj4=;
b=D6MjIq8TFYYOd0UuLfWILhNLyqegPz2+Oe5gmrS+P2otpCiUBdBp9d+OJ8WQkmiCgr
LCVdWMuLRvKn/kHeIVDG8DnFeTvhj+mEOD92/bumV0ObDuJ2+iJZNyF4hS21g3XTVsSI
ALvbMvCHEvzyk8VM/rwWa/okuaNPtetTiJCZZMn9QbEfpcUadLQJccbnyxvYbgBA6yF3
nGH1c4HFGqVojSCT3ehpeIT+auDTdvfFQQ6yLYV0JNu6ChKPXIUaeH8c6THVHI+VkxQj
DlYVM+RBV4Qc3LDA9D6odkHka5BNjozop8oXN80xDn7PxM7RusPymLHjDWlMJSuVe0pQ
NN4w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1731722453; x=1732327253; 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:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=rXjWw2fGbPJHMhGr8t88vet0bQ4WWhz7aOvuTCABxj4=;
b=QABqnjS10fyQb548N4eq7kjhahiMypRRyHPX9Uvb3zquObC9RkRcOucbfAk6ezgBVi
tW0cWFCUrP0dQ1BrvCt6lWRNayviuTXexz4umJ3bCcwIAD2BUG1n62lqOXs9UMjCcGjN
DJFdL7KoGB1CANlb5E2gK+FrT9wqyiCYiiqMpubt2bsUM1YbJDPF+H+i7Qpafo2bT8SP
VlyrpPHSK9FaJ+0T5pQRMEAIlmZwjQdYZcAqHIQg+8MPVE72/0nuS9xusyHzWt+N2dC4
g4hIAovXADgHay+ZXVdk0RmdpftGNl7fiD9JjxNMTIXJa8Dej0XTN0UsgNemKBFiffJY
6XfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1731722453; x=1732327253;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=rXjWw2fGbPJHMhGr8t88vet0bQ4WWhz7aOvuTCABxj4=;
b=CDYuv2ZURtJGpKit3kx0w/eRQshKmgV8V+2n15QW3A9kN5aV3tt+3u0amGxvChytuZ
hrBfxSmZ29XBlGJxigjY1Jff7VvEZ3FwuhTzzFfggdc3Y8QW+W9uQuVGhoYDrJ/RDzKF
AxNcTEoL7TN6DY1O+QHVI6d+LPmAwXURhem2XeP55tv21QClGjqRlBJ8LVbR3Cq220v/
CM6uPNtb/EfAM6PCrlweKDvLW8Tx4VjiBBko2DcCqsuCQNJ2cRsA1Fr61drlkq9yFrow
71eJ2rOVMW8jagWo9WXebrmxSVozfucERnymbd/ehq08VxozuuCb4eZhMg+ba2CEdKUi
1stA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXHiG1g4S9T3N1N6MKu132AkS97vw/hnKBSWEIMpLXj4y0VedGnvqqpNoTT/s39ZTzUsGGK/9l16reU@gnusha.org
X-Gm-Message-State: AOJu0YwkTudq0fK4q6xjqrA2q4DByAsfCwGmW7cH2FVQWAkPgXGzSLhN
LbtxH7hhx4jmHeVOJnNq4sl2hb1OK3CHomFT75GzAZ+LH7J0ewH2
X-Google-Smtp-Source: AGHT+IGRQp9zoN1X7J92E3qiAxu5TAMA1lTAC4W5Z1JBCNm+eneX0Y1TCP8aYZN58F4sGr53bCZZbw==
X-Received: by 2002:a05:6870:2104:b0:277:e6fc:4a69 with SMTP id 586e51a60fabf-2962dcb489cmr5233593fac.2.1731722453063;
Fri, 15 Nov 2024 18:00:53 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6870:9a12:b0:288:93de:9ec9 with SMTP id
586e51a60fabf-2962cd386cals1027598fac.2.-pod-prod-03-us; Fri, 15 Nov 2024
18:00:50 -0800 (PST)
X-Received: by 2002:a05:6808:2213:b0:3e6:6170:88ff with SMTP id 5614622812f47-3e7bc7a4a56mr5805742b6e.6.1731722450243;
Fri, 15 Nov 2024 18:00:50 -0800 (PST)
Received: by 2002:a05:690c:2a91:b0:6dd:f386:13dc with SMTP id 00721157ae682-6ee533c8898ms7b3;
Fri, 15 Nov 2024 16:45:05 -0800 (PST)
X-Received: by 2002:a05:690c:b82:b0:6e3:fd6:6ccb with SMTP id 00721157ae682-6ee55a54673mr57907337b3.13.1731717904556;
Fri, 15 Nov 2024 16:45:04 -0800 (PST)
Date: Fri, 15 Nov 2024 16:45:04 -0800 (PST)
From: Weikeng Chen <weikeng.chen@l2iterative.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <4235f7d2-8e09-428a-813d-9034cb21f48an@googlegroups.com>
Subject: [bitcoindev] Multi-byte opcodes
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_125862_803978748.1731717904267"
X-Original-Sender: weikeng.chen@l2iterative.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.7 (/)
------=_Part_125862_803978748.1731717904267
Content-Type: multipart/alternative;
boundary="----=_Part_125863_1234969896.1731717904267"
------=_Part_125863_1234969896.1731717904267
Content-Type: text/plain; charset="UTF-8"
I think we need a way to allow more opcodes without taking up the rest of
the NOPs.
This is related to a point from Murch
(https://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAjSdCgAJ) that
the reasoning of "its' compatible, why not" for adding
CHECKSIGFROMSTACK(VERIFY/ADD) is not solid because when we add a new
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
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
flexible use of existing opcodes.
This, of course, runs at a cost as this opcode needs three bytes in total
to represent, but since the existing opcodes already take care of most of
the basic functionalities that we expect users 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 few times in a script.
Similarly, we can require that multi-byte opcodes that have not been
enabled my result in OP_SUCCESS.
OP_OP is not the best name as it could be confusing. OP_SETOP, OP_NEXT, etc
could be taken into consideration.
The result of this is that we can worry less about whether it is worthy of
a NOP to do an opcode, but focus on if the opcode has enough use cases to
support it.
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).
What do people think?
Thanks,
Weikeng
--
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/4235f7d2-8e09-428a-813d-9034cb21f48an%40googlegroups.com.
------=_Part_125863_1234969896.1731717904267
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div>I think we need 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 (=
https://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAjSdCgAJ) that t=
he reasoning of "its' compatible, why not" for adding CHECKSIGFROMSTACK(VER=
IFY/ADD) is not solid because when we add 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-byte opcodes.</div><div><br /></div><=
div>Say, for example, we can have:</div><div>=C2=A0 =C2=A0 OP_OP { 0x1521 }=
</div><div>which will set the current opcode to be the one with the assigne=
d number 0x1521.</div><div><br /></div><div>Another idea is maybe OP_OP tak=
es 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 /></d=
iv><div>This, of course, runs at a cost as this opcode needs three bytes in=
total to represent, but since the existing opcodes already take care of mo=
st of the basic functionalities that we expect users to use very frequently=
, the new opcodes that we want to add are likely those that complete someth=
ing important and are going to be used only a few times in a script.</div><=
div><br /></div><div>Similarly, we can require that multi-byte opcodes that=
have not been enabled my result in OP_SUCCESS.</div><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 o=
f this is that we can worry less about whether it is worthy of a NOP to do =
an opcode, but focus on if the opcode has enough use cases to support it.</=
div><div><br /></div><div>I feel that someone must have brought this up bef=
ore (but it is a little bit hard to find the history in this mailing list a=
t this moment).</div><div><br /></div><div>What do people think?</div><div>=
<br /></div><div>Thanks,</div><div>Weikeng</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/4235f7d2-8e09-428a-813d-9034cb21f48an%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/4235f7d2-8e09-428a-813d-9034cb21f48an%40googlegroups.com</a>.<br />
------=_Part_125863_1234969896.1731717904267--
------=_Part_125862_803978748.1731717904267--
|
