Delivery-date: Tue, 19 Nov 2024 09:36:37 -0800
Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.140 as permitted sender) client-ip=185.70.40.140;
Date: Tue, 19 Nov 2024 16:38:21 +0000
To: Brandon Black <freedom@reardencode.com>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Weikeng Chen <weikeng.chen@l2iterative.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Multi-byte opcodes
Message-ID: <E95uz4uyQgikJKtximyueqFTRs7cTJfpcdVvkrYEkfZ__DTpvwlsm0MSsX8BaqKg6KnONx6eQ5VueijeMqWQ8uI4iFKA--irKATjN1K4Fbg=@protonmail.com>
In-Reply-To: <Zzt2OCE6Aj9H3DiY@console>
References: <4235f7d2-8e09-428a-813d-9034cb21f48an@googlegroups.com> <Zzt2OCE6Aj9H3DiY@console>
Feedback-ID: 38540639:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Reply-To: moonsettler <moonsettler@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi All,

I think we should discuss back-porting tapscript instead of coming up with a further divergent set of opcodes.

To sum up earlier discussion with Brandon, we could:

* Use a single upgradeable NOP for OP_TAPSCRIPTVERIFY
* <s1> .. <sn> | <faux-control-block> <tapscript> CTAPV
* Isolated execution environment
* Gets the entire stack below the top 2 elements
* Fails if it fails, does nothing if internal script succeeds.
* Require the last opcode executed by the script interpreter to be a push opcode, fails otherwise

The faux control block can be just a few bytes mainly for tapscript version.

BR,
moonsettler

Sent with Proton Mail secure email.

On Monday, November 18th, 2024 at 6:15 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/E95uz4uyQgikJKtximyueqFTRs7cTJfpcdVvkrYEkfZ__DTpvwlsm0MSsX8BaqKg6KnONx6eQ5VueijeMqWQ8uI4iFKA--irKATjN1K4Fbg%3D%40protonmail.com.