From: "'Brandon Black' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Rusty Russell <bitcoin-dev@rustcorp.com.au>,
bitcoindev@googlegroups.com, Julian Moik <julianmoik@gmail.com>
Subject: Re: [bitcoindev] [4/4] New Opcodes for Tapscript v2
Date: Thu, 12 Mar 2026 11:00:15 -0700 [thread overview]
Message-ID: <abL_L1IFf1-uZaGX@console> (raw)
In-Reply-To: <87seadabvi.fsf@rustcorp.com.au>
> CODESEPARATOR always feels like a loaded weapon, so I avoid it!
I've tried to find uses for it several times. Briefly had one as part of
a DLC protocol, but ended up killing it with a later revision.
> I'm not sure what the "don't sign the whole script" semantics are for,
> but I suspect they're orthogonal to the separation of execution of
> OP_SEGMENT.
To me, they seem to have basically the same conceptual purpose -
compartmentalize validity. SUCCESS only force-validates this portion of
the script, CHECKSIG on this signature is only valid in this portion of
the script.
I'd suggest that having both is silly, and also that with SEGMENT it
wouldn't make sense for a signature for a given pubkey intended for one
segment to be valid in another segment. Therefore, there is no need to
have both. Pick one and it compartmentalizes both signatures and
SUCCESSes.
All the 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/abL_L1IFf1-uZaGX%40console.
next prev parent reply other threads:[~2026-03-12 18:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-27 8:12 [bitcoindev] [0/4] A Bitcoin Scripting Proposal BIP Quartet Rusty Russell
2025-09-27 11:27 ` [bitcoindev] [1/4] Varops Budget For Script Runtime Constraint Rusty Russell
2025-09-27 11:28 ` [bitcoindev] [2/4] Restoration of disabled script functionality (Tapscript v2) Rusty Russell
2025-09-27 11:29 ` [bitcoindev] [3/4] OP_TX Rusty Russell
2025-09-27 11:29 ` [bitcoindev] [4/4] New Opcodes for Tapscript v2 Rusty Russell
2025-09-29 22:55 ` Brandon Black
[not found] ` <87seadabvi.fsf@rustcorp.com.au>
2026-03-12 18:00 ` 'Brandon Black' via Bitcoin Development Mailing List [this message]
2025-10-06 11:29 ` Anthony Towns
2025-10-06 11:41 ` [bitcoindev] [3/4] OP_TX Anthony Towns
[not found] ` <871phxaaac.fsf@rustcorp.com.au>
2026-03-26 8:30 ` Anthony Towns
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=abL_L1IFf1-uZaGX@console \
--to=bitcoindev@googlegroups.com \
--cc=bitcoin-dev@rustcorp.com.au \
--cc=freedom@reardencode.com \
--cc=julianmoik@gmail.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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