From: Weikeng Chen <weikeng.chen@l2iterative•com>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: Brandon Black <freedom@reardencode•com>,
Andrew Poelstra <apoelstra@wpsoftware•net>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode
Date: Thu, 12 Dec 2024 11:17:12 +0800 [thread overview]
Message-ID: <CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ@mail.gmail.com> (raw)
In-Reply-To: <87ttbccrql.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]
I was mostly thinking about the names atm. OP_RETURN_TRUE may be a name
less confusing than OP_SUCCESS. It helps if one day we nickname/alias
OP_RETURN as OP_RETURN_FALSE.
This could eventually become an opcode BIP proposal that is pretty
causal---if a major soft fork happens (like the one that adds tapscript),
it could be piggybacked into it, otherwise, it would just stay as a
proposal as there is no urgency since it doesn't enhance the ability of
Bitcoin script (you can emulate it), but more to avoid bugs in code and for
clarity.
On Thu, Dec 12, 2024 at 10:54 AM Rusty Russell <rusty@rustcorp•com.au>
wrote:
> Brandon Black <freedom@reardencode•com> writes:
> > Hey list,
> >
> > On 2024-12-09 (Mon) at 19:08:51 +0000, Andrew Poelstra wrote:
> >> On Mon, Dec 09, 2024 at 05:27:54AM -0800, Weikeng Chen wrote:
> >> > When I am implementing fraud proofs in Bitcoin script, I find it
> useful to
> >> > have an opcode "OP_SUCCESS" that will mark the execution to be
> successful
> >> > without running the rest of the script, if this opcode is being
> executed.
> >> > This is useful for writing code for fraud proofs such as BitVM, where
> the
> >> > verifier wins if it finds one mismatch, and the verifier does not
> need to
> >> > show the other mismatches.
> >> >
> >> > This OP_SUCCESS is weaker version of the OP_SUCCESSx in the Taproot
> >> > upgrade, which marks the execution as successful for the mere
> presence of
> >> > OP_SUCCESSx anywhere in the script. Rusty Russell in a 2023 article,
> >> > "Covenants: Examining ScriptPubkeys in Bitcoin Script", also
> mentioned
> >> > about the usefulness of such an opcode.
> >> >
> >> > <snip>
> >>
> >> In short, for purpose of softforking upgrade mechanism, the existing
> >> SUCCESS codes give us way more freedom of action.
> >>
> >> But it sounds like you want a "weak SUCCESS" opcode in order to use the
> >> success semantics, not as an upgrade mechanism. Maybe it makes sense to
> >> propose that one of the existing OP_SUCCESSx opcodes should be
> >> softforked to become OP_WEAK_SUCCESS?
> >
> > An alternative that Rusty Russel has discussed wanting as part of his
> > script restoration work is "OP_SEGMENT" which would split the script
> > execution for purposes of SUCCESS checking, allowing (for example) a
> > prefix to be required to execute before an arbitrary user provided
> > script that might contain an OP_SUCCESS.
> >
> > It occurred to me today when thinking about Weikeng's post that we can
> > slightly weaken the existing OP_SUCCESS behavior while retaining
> > essentially all of its benefits in practice without introducing
> > OP_SEGMENT by leveraging OP_CODESEPARATOR. Redefine OP_SUCCESS with a
> > soft fork from "make the script unconditionally valid" to "make the
> > script segment unconditionally valid", and define a script segment as
> > "each lexicographic section of the script containing no
> > OP_CODESEPARATOR".
> >
> > The script interpreter can perform SUCCESS checking as it currently does
> > until it encounters an OP_CODESEPARATOR. Each OP_CODESEPARATOR gets a
> > "SUCCESS" flag defaulted to false and SUCCESS checking now sets that
> > flag to true on the most recently encountered OP_CODESEPARATOR.
> >
> > During script execution, whenever an OP_CODESEPARATOR is popped (not
> > executed) its "SUCCESS" flag value is copied to the interpreter state.
> > After this state setting conditional, if the interpreter "SUCCESS" flag
> > is true, and fExec is true, the script immediately succeeds.
>
> Beware success inside branches? This is why I preferred to segment the
> script and scan for OP_SUCCESS and evaluate each part in order (if you
> have part of an if statement inside one segment, you fail as expected).
> This is actually not that different inside Bitcoin's script.cpp.
>
> But that's kind of a detail. IMHO there's nothing fundamentally wrong
> with runtime success opcodes, in fact several proposals work better if
> you allow them (e.g. "undefined bit patterns in operand to OP_TXHASH
> cause immediate success" lets you reserve some bits for future
> extension).
>
> (Also: OP_CODESEPARATOR is cursed, so I chose a different name :)
>
> Cheers,
> Rusty.
>
--
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/CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5860 bytes --]
next prev parent reply other threads:[~2024-12-12 6:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 13:27 Weikeng Chen
2024-12-09 19:08 ` Andrew Poelstra
2024-12-09 22:06 ` Brandon Black
[not found] ` <87ttbccrql.fsf@rustcorp.com.au>
2024-12-12 3:17 ` Weikeng Chen [this message]
2024-12-12 5:49 ` 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=CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ@mail.gmail.com \
--to=weikeng.chen@l2iterative$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=freedom@reardencode$(echo .)com \
--cc=rusty@rustcorp$(echo .)com.au \
/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