From: Brandon Black <freedom@reardencode•com>
To: moonsettler <moonsettler@protonmail•com>
Cc: Weikeng Chen <weikeng.chen@l2iterative•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Multi-byte opcodes
Date: Tue, 19 Nov 2024 11:35:32 -0800 [thread overview]
Message-ID: <ZzzohFCFjJebA8_2@console> (raw)
In-Reply-To: <E95uz4uyQgikJKtximyueqFTRs7cTJfpcdVvkrYEkfZ__DTpvwlsm0MSsX8BaqKg6KnONx6eQ5VueijeMqWQ8uI4iFKA--irKATjN1K4Fbg=@protonmail.com>
On 2024-11-19 (Tue) at 16:38:21 +0000, moonsettler wrote:
> 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.
Few additional points that came up in discussing this with moon earlier:
* Compared to enabling tapscript without a key spend path (i.e.
potential for quantum resistance) via a new witnessv1 program length
or a new witness version, this approach will be similar in weight.
* The biggest challenge with this approach that I came up with is the
need to clean up the stack after execution (to satisfy witness v0
clean stack).
* To keep it simple, it probably makes sense to make it a 1-primary
argument opcode where the argument is `<tapscript||version>` to
prevent the version from coming from spend-time witness elements.
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/ZzzohFCFjJebA8_2%40console.
prev parent reply other threads:[~2024-11-19 20:24 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
2024-11-19 16:38 ` 'moonsettler' via Bitcoin Development Mailing List
2024-11-19 19:35 ` Brandon Black [this message]
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=ZzzohFCFjJebA8_2@console \
--to=freedom@reardencode$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=moonsettler@protonmail$(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