From: Weikeng Chen <weikeng.chen@l2iterative•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode
Date: Mon, 9 Dec 2024 05:27:54 -0800 (PST) [thread overview]
Message-ID: <ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3537 bytes --]
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.
```
OP_NOP1
OP_IF
OP_NOP2
OP_IF_SUCCESS
OP_NOP3
OP_IF_SUCCESS
OP_NOP4
OP_IF_SUCCESS
OP_NOP5
OP_ENDIF
OP_NOP6
```
with OP_IF_SUCCESS short for "OP_IF OP_SUCCESS OP_ENDIF"
The equivalent version without using new opcode is as follows (generated by
computer, using a rewriting tool:
https://github.com/Bitcoin-Wildlife-Sanctuary/fraud-proof-compiler)
```
OP_NOP1
OP_IF
OP_NOP2
OP_IF
1
0
OP_ELSE
OP_NOP3
OP_IF
1
0
OP_ELSE
OP_NOP4
OP_IF
1
OP_ELSE
OP_NOP5
0
0
0
OP_ENDIF
OP_ENDIF
OP_IF 1 OP_ENDIF
OP_ENDIF
OP_IF 1 OP_ENDIF
OP_ELSE
0
OP_ENDIF
OP_IF
1
OP_ELSE
OP_NOP6
0
OP_ENDIF
OP_IF
OP_DEPTH 512 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (256 OP_2DROP)
OP_ENDIF
OP_DEPTH 256 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (128 OP_2DROP)
OP_ENDIF
OP_DEPTH 128 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (64 OP_2DROP)
OP_ENDIF
OP_DEPTH 64 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (32 OP_2DROP)
OP_ENDIF
OP_DEPTH 32 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (16 OP_2DROP)
OP_ENDIF
OP_DEPTH 16 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (8 OP_2DROP)
OP_ENDIF
OP_DEPTH 8 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (4 OP_2DROP)
OP_ENDIF
OP_DEPTH 4 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP ... OP_2DROP (2 OP_2DROP)
OP_ENDIF
OP_DEPTH 2 OP_GREATERTHANOREQUAL OP_IF
OP_2DROP
OP_ENDIF
OP_DEPTH OP_IF
OP_DROP
OP_ENDIF
OP_TRUE
OP_ENDIF
```
The second part of the code is mainly a general-purpose and
stack-size-independent method to remove all the stack elements in order to
be standard.
For this reason, it seems better to avoid the need for developers to
"emulate" such a weak version of OP_SUCCESS but to actually implement an
opcode for that.
What do you think?
--
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/ebd77d82-96ab-4530-909a-d085378b9868n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4876 bytes --]
next reply other threads:[~2024-12-09 13:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 13:27 Weikeng Chen [this message]
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
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=ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com \
--to=weikeng.chen@l2iterative$(echo .)com \
--cc=bitcoindev@googlegroups.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