Currently, we have
<pubkey> OP_CHECKSIG, usually wrapped with
OP_HASH160, when we have outputs that could be spent by providing any valid signature. There were some ideas how to implement Taproot on BCH but I found nothing that involved
OP_CODESEPARATOR, so I share it here.
The basic idea is simple:
OP_CODESEPARATOR can be used to separate many parts of the script. So, if we want to get 2-of-2 multisig that will be hidden behind some public key, we could do it that way:
<signatureBob> <pubkeyBob> OP_CHECKSIGVERIFY OP_CODESEPARATOR <signatureAlice>
That would mean two things: first, for each TapBCH public key, there is a need to provide some valid signature. That means, all previous owners are protected, because they are not exposed to any new cryptographic risks. Second: there could be more ways to spend any coin that is hidden behind some public key.
And when it comes to unspendable public keys, then in practice they are not needed at all. We have Schnorr signatures, so we can start from any N-of-N multisig that will guarantee, that all participants agreed to everything. And the best thing is that by placing
OP_CODESEPARATOR in the right position in our input script, we can decide, which things are signed, and which are not. So, it is possible to make some signature for a shared key, that will be valid only if the input script will contain
OP_CODESEPARATOR <some> <opcodes> <goes> <here>, that will be joined with
So, as far as I know, transaction standardness is the only limit that stops users from using those features right here and right now. Or maybe I am wrong and those transactions are standard? Can you see any obvious ways, how this way of spending coins can be unsafe, assuming that we use Schnorr signatures, and nobody knows the private key to the shared public key?