Delivery-date: Mon, 09 Dec 2024 11:10:08 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.127 as permitted sender) client-ip=66.183.0.127;
Date: Mon, 9 Dec 2024 19:08:51 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Weikeng Chen <weikeng.chen@l2iterative.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Difficulty in emulating "weaker" OP_SUCCESS and why
 it should be a real opcode
Message-ID: <Z1dAQ8pSIqn8XA56@camus>
References: <ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="Y5YQOTfDJyCBwcB0"
Content-Disposition: inline
In-Reply-To: <ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--Y5YQOTfDJyCBwcB0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

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. 
> 
> Of course, this opcode can be emulated, and one can rewrite the existing 
> script in a way to realize the same functionality without adding a new 
> opcode to Bitcoin.
> 
> The problem is that such rewriting is indeed fairly complicated. For 
> example, say that we have the following program.
>
> <snip>

I raised the question on IRC about why the existing SUCCESSx codes work
the way they do, and got several good anwsers that you can read here

https://gnusha.org/bitcoin-wizards/2024-12-09.log

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?

-- 
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster

-- 
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/Z1dAQ8pSIqn8XA56%40camus.

--Y5YQOTfDJyCBwcB0
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmdXQEIACgkQxYjWPOQb
l8F4Egf/fP0GgPYiv85lzdEjSK2kZUzGMAtmhzceLrXhiDP1rOsHaPe/MP2/DivF
K/EVPzna/uy4W4Jms1d/8CWJEd/RRJKmZKS5WJlt6mdCTlMVoUpT204oOxHuE2Dh
aoqMeOE/91kT/obxYz8PgblhDACZIqkJRgwF4ImWwB8e38Ppa6CpTzYH+ryiCtgC
c5ndCZ/p2B/U22KhfXWOF2B0H0eFCbjVNdXjRG5cv6RHyw9ZR8os45PCYusPhs7M
ggXI4tOJFBFM/rcKfyq5u9lP/VWpmlUOsWMUvHo97RN+61R/ObB+c2Lo5hFPpcWV
tewfnYpTPQ/GHrxheNaDbsecFXsj/A==
=gKi0
-----END PGP SIGNATURE-----

--Y5YQOTfDJyCBwcB0--