Delivery-date: Mon, 18 Nov 2024 10:36:36 -0800
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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

&gt; 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 />&gt; 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&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAj=
SdCgAJ&amp;source=3Dgmail&amp;ust=3D1732028955061000&amp;usg=3DAOvVaw0JqvB2=
WMH4Tm3ZwjIJxxdc">https://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hh=
tvAjSdCgAJ</a>) that the reasoning of &quot;its&#39; 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&quot; 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--