From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
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 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.

We can, = however, solve that by allowing multi-byte opcodes.

<= div>Say, for example, we can have:
=C2=A0 =C2=A0 OP_OP { 0x1521 }=
which will set the current opcode to be the one with the assigne= d number 0x1521.

Another idea is maybe OP_OP tak= es a stack element as the opcode.
=C2=A0 =C2=A0 { 0x1521 } OP_OP<= /div>

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 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>
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 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.

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).

What do people think?
=
Thanks,
Weikeng

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/4235f7d2-8e09-428a-813d-9034cb21f48an%40googlegroups.com.
------=_Part_125863_1234969896.1731717904267-- ------=_Part_125862_803978748.1731717904267--