Delivery-date: Mon, 09 Dec 2024 14:16:34 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) client-ip=2607:f2f8:ad40:ea11::1;
Date: Mon, 9 Dec 2024 14:06:08 -0800
From: Brandon Black <freedom@reardencode.com>
To: Andrew Poelstra <apoelstra@wpsoftware.net>
Cc: Weikeng Chen <weikeng.chen@l2iterative.com>,
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [bitcoindev] Difficulty in emulating "weaker" OP_SUCCESS and why
 it should be a real opcode
Message-ID: <Z1dp0Jtbrkcf7Roi@console>
References: <ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com>
 <Z1dAQ8pSIqn8XA56@camus>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <Z1dAQ8pSIqn8XA56@camus>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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.

For Weikeng's scripts, this would require 2 OP_CODESEPARATORS for each
OP_SUCCESS (or some really weird logic about what's executed in what
SUCCESS state).

Thoughts on this approach?

--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/Z1dp0Jtbrkcf7Roi%40console.