Is there any useful place where OP_CODESEPARATOR is used? - page 2.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: RobinLinus on February 12, 2022, 06:03:31 AM

Here is an example how you could use it in an interesting way: https://github.com/coins/bitcoin-scripts/blob/master/op-codeseparator.md

I think I saw this 2 months ago when I started the topic and it still doesn't make any sense. Take the last example:

Code:

OP_IF
# Case 1
OP_CODESEPARATOR
600300
OP_ENDIF

OP_IF
# Case 2
OP_CODESEPARATOR
600200
OP_ENDIF

OP_IF
# Case 3
OP_CODESEPARATOR
600100
OP_ENDIF

OP_CHECKLOCKTIMEVERIFY
OP_DROP

2

2
OP_CHECKMULTISIG

When you spend it with something like

Code:

0 0 1

The first IF pops 1 but the second IF is not popping the 0, instead it pops 600300 that was pushed to the stack inside the conditional branch! And OP_CODESEPARATOR doesn't seem to be doing anything here. Then 600200 will be pushed to the stack to be popped by the next IF and finally 600100 which will be popped by OP_CHECKLOCKTIMEVERIFY.
So why not use a nested IF?

Code:

OP_IF
600300
OP_ELSE
OP_IF
600200
OP_ELSE
600100
OP_ENDIF
OP_ENDIF

OP_CHECKLOCKTIMEVERIFY
OP_DROP

2

2
OP_CHECKMULTISIG

It is shorter and achieves the same thing without OP_CODESEPARATOR.

RobinLinus

newbie

Activity: 20

Merit: 39

Quote from: pooya87 on December 08, 2021, 12:32:47 AM

I never could figure out where would OP_CODESEPARATOR be useful and some very old comments from early days suggest it may be a byproduct of a bad decision (eg. scripts were concatenated then executed at first).
While going through Taproot this OP code makes even less sense in Tapscripts and yet it is there. So I was wondering if I'm missing something and whether there is any good script examples I could look at where OP_CODESEPARATOR solves a problem that can't be solved in any other way.

Here is an example how you could use it in an interesting way: https://github.com/coins/bitcoin-scripts/blob/master/op-codeseparator.md

PawGo

legendary

Activity: 952

Merit: 1386

I think you are not the first who investigates OP_CODESEPARATOR
https://bitcointalksearch.org/topic/m.2757093

In other words - conclusion is that as it is a source of potential problems, it is not used at all.

vjudeu

copper member

Activity: 909

Merit: 2301

This is a great question, but I am worried, that the answer could be "no", when it comes to "a problem that can't be solved in any other way".

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: garlonicon on December 08, 2021, 01:30:46 AM

But if you have " OP_CHECKSIG" in scriptPubKey, then your signature has to sign itself,

No you don't. When computing sighash (for legacy and witness version 0) the FindAndDelete method is called which would remove the signature. So the script that would be used in signing becomes " OP_CHECKSIG".

For witness version 1 (Tapscripts) things are very different and the leaf hash is used.

garlonicon

copper member

Activity: 821

Merit: 1992

If you have " OP_CHECKSIG" in scriptPubKey and "" in scriptSig, you don't need OP_CODESEPARATOR. But if you have " OP_CHECKSIG" in scriptPubKey, then your signature has to sign itself, because you put scriptPubKey of the previous output when calculating z-value to sign for transaction. On the other hand, if you have " OP_CODESEPARATOR OP_CHECKSIG" in scriptPubKey, then your z-value is independent from your "", which means you can put signatures in your output scripts.

The practical use case I can think of is to limit possible transactions, where you can spend your input. If your "" uses SIGHASH_ALL, that means you can pre-calculate your next transaction, get your z-value, make a signature, and then create your output, that will be spendable only in this pre-computed transaction and nowhere else. Probably, if you combine it with other sighashes or use some kind of OP_IF or OP_PICK to choose one of N signatures from scriptPubKey, then you can decide, in which of N transactions your input can be included.

pooya87

legendary

Activity: 3472

Merit: 10611

I'm aware of the mechanics, the same mechanics that no longer exist in Tapscripts since the script is no longer changed, we just add the OP position to the bytes we are hashing when computing the sighash. Which raises the question of why wasn't this OP code removed/disabled like OP_CHECKMULTISIG(VERIFY).

Quote from: NotATether on December 08, 2021, 12:47:29 AM

It has no practical use because it has a side effect that any part of the public key you modify will change the transaction hash.

You don't need to modify the pubkey scripts and also there are redeem scripts that this OP code could be used in. And it seems that there are some use cases (which still don't make sense to me since there are alternative ways) that this OP code could come in play so I'm hoping for more or better examples.
Example: https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: https://bitcoin.stackexchange.com/a/34177/112589

Looking at this diagram of OP_CHECKSIG steps and the Bitcoin Script wiki, OP_CODESEPARATOR is used to make OP_CHECKSIG check only part of the scriptPubKey. Essentially, only the script that goes after the last OP_CODESEPARATOR is used to sign the transaction and hence evaluated by OP_CHECKSIG.

In theory, a spending transaction could change the part of the scriptPubKey before the last OP_CODESEPARATOR of the input transaction.

However, there's a problem. Since scriptPubKey comes from the input transaction, you can't actually modify any part of the scriptPubKey (even the part before the last OP_CODESEPARATOR) without changing the input transaction hash. Changing the input transaction hash breaks the link for any transaction trying to spend outputs from the unspent input transaction, making it impossible to use OP_CODESEPARATOR in practice.

I wasn't able to find any cases in practice where people have successfully used OP_CODESEPARATOR for a useful purpose, although it does show up in the blockchain. See this, this and this (and the thread you referenced) for core developers commenting on or discussing possible uses for OP_CODESEPARATOR.

It has no practical use because it has a side effect that any part of the public key you modify will change the transaction hash.

Granted, I've only ever seen OP_CODESEPARATOR scripts inside Bitcoin Core unit tests.

pooya87

legendary

Activity: 3472

Merit: 10611

I never could figure out where would OP_CODESEPARATOR be useful and some very old comments from early days suggest it may be a byproduct of a bad decision (eg. scripts were concatenated then executed at first).
While going through Taproot this OP code makes even less sense in Tapscripts and yet it is there. So I was wondering if I'm missing something and whether there is any good script examples I could look at where OP_CODESEPARATOR solves a problem that can't be solved in any other way.

Topic: Is there any useful place where OP_CODESEPARATOR is used? - page 2. (Read 478 times)