From: Ethan Heilman <eth3rs@gmail•com>
To: Brandon Black <freedom@reardencode•com>
Cc: Weikeng Chen <weikeng.chen@l2iterative•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Multi-byte opcodes
Date: Mon, 18 Nov 2024 13:54:17 -0500 [thread overview]
Message-ID: <CAEM=y+VpeEwqWtXqs+RpOFrO=WGzbSkPEEqBqBxc-87Z4ruh2g@mail.gmail.com> (raw)
In-Reply-To: <Zzt2OCE6Aj9H3DiY@console>
[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]
Couldn't we add opcodes contexts via the script version?
By context I mean an opcode that loads a 1 to N byte map rewriting the
mapping from opcode number to what instruction that number signifies. This
should let you have an infinite number of instructions. You could change
the context multiple times in a script as a cost of only two or three bytes.
On Mon, Nov 18, 2024, 1:36 PM Brandon Black <freedom@reardencode•com> wrote:
> Hi Weikeng, thanks for your thoughts on this!
>
> > 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
>
> Another option that works for many cases is to have opcode families
> where an argument is augmented with flags to determine the behavior. We
> can consider this to already be the case for OP_CHECKSIG* where the
> signature determines the behavior of the hashing portion of the opcode.
>
> This is also how OP_CHECKTEMPLATEVERIFY is designed, and how
> OP_CHECKSIGFROMSTACKVERIFY as currently spec'd in the PR is designed.
> CTV and CSFSV only constrain 32-byte first arguments, but not other
> lengths leaving open extensions using any other length, including using
> other lengths of either opcode as OP_OP, or as variants on CTV and CSFSV
> respectively.
>
> The benefit of this approach is that it doesn't "waste" the length byte
> only to specify the opcode behavior, but enables it to do double duty as
> specifying the total length of the first argument including both flags
> and data.
>
> Best,
>
> --Brandon
>
> --
> 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/Zzt2OCE6Aj9H3DiY%40console.
>
--
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/CAEM%3Dy%2BVpeEwqWtXqs%2BRpOFrO%3DWGzbSkPEEqBqBxc-87Z4ruh2g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3551 bytes --]
next prev parent reply other threads:[~2024-11-18 19:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-16 0:45 Weikeng Chen
2024-11-18 15:10 ` [bitcoindev] " Garlo Nicon
2024-11-18 17:15 ` [bitcoindev] " Brandon Black
2024-11-18 18:54 ` Ethan Heilman [this message]
2024-11-19 16:38 ` 'moonsettler' via Bitcoin Development Mailing List
2024-11-19 19:35 ` Brandon Black
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEM=y+VpeEwqWtXqs+RpOFrO=WGzbSkPEEqBqBxc-87Z4ruh2g@mail.gmail.com' \
--to=eth3rs@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=freedom@reardencode$(echo .)com \
--cc=weikeng.chen@l2iterative$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox