Wait a minute. I did some lookup on OP_CHECKDATASIG to see if it's in some btc BIP draft somewhere, and it is actually an opcode in Bitcoin Cash since some years ago - https://mengerian.medium.com/the-story-of-op-checkdatasig-c2b1b38e801a
I think we can safely assume that Kalle and the other major BIP322 proponents do not have BCH script compatibility on a high prioirty, perhaps not even medium prioity, so we should be able to make an opcode called OP_CHECKDATASIG for this BIP's internal purposes. However, a new opcode cannot be created without a lengthy soft-fork (which requires miner signalling - but for what use here, this BIP does not directly impact miners?) with an activation height. If we want to redefine an existing opcode, we must also make a similar soft-fork. Because consensus rules are being modified here. At the same time, a message signing/verifying algorithm using Script must implement some way to verify a *single* ECDSA or Schnorr signature that is on the stack. The existing opcodes such as OP_CHECKSIG verify all of the inputs and outputs, and this won't work here since there's a deliberate invalid iput in "to_spend". I tried to research if there is any known use of OP_RESERVED in a script, even if it's only of academic origin, but I unfortunately could not find any references except for https://bitcoin.stackexchange.com/questions/105778/why-were-op-reserved-op-reserved1-and-op-reserved2-originally-reserved . So this is now an open problem: How should Script verify a single signature that is on the stack without touching any of the inputs or outputs? - Ali On Wed, Aug 10, 2022 at 05:05:59PM +0200, vju...@gazeta.pl wrote: > > I suppose in the case of legacy P2PKH signing, a hypothetical > > OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform > > an ECDSA public key recovery > > You can always perform key recovery for legacy ECDSA: "<signature> OP_SWAP > OP_CHECKSIG" is always spendable, for any valid <r,s> DER-encoded pair. Here, > if "<signature> <messageHash> <pubkey> OP_CHECKDATASIG" works for signature > verification BIP, then you only need to provide "<signature>" as an input, > the rest could be placed in some output, and your program could easily > compute that. Or you can use "OP_DUP OP_HASH160 <address> OP_EQUALVERIFY > <messageHash> OP_SWAP OP_CHECKDATASIG" as your output script, then the signer > has to provide a valid signature, and a valid public key explicitly, but if > you only have some signature, then you can always recover that key by > yourself. > > Because if OP_CHECKDATASIG is not handled, then still, signing by scripts can > handle that, but the Script would be unnecessarily complex. And because there > is no need to introduce OP_CHECKDATASIG on-chain, it can be safely done > inside this BIP. > > > I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help > > implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid > > instruction. > > Because if you want to support any script, and you want to add a new opcode, > you have to make it somehow compatible with existing schemes. You have to > assign some byte for OP_CHECKDATASIG or for any new opcodes you want to add. > And you don't want to assign just the next free opcode, because you will get > OP_CHECKSIGADD or other opcodes from TapScript, so your script decoder will > no longer handle two script versions at once. Unless you want to make it also > compatible with altcoins like BCH, but I guess it is not needed. > > > On 2022-08-10 15:53:31 user Ali Sherief <a...@notatether.com> wrote: > > > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to > > > be somehow introduced to make it compatible with "Bitcoin Message". > > I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG > can take <signature> <pubkeyhash> off the stack and perform an ECDSA public > key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between > OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG. > > But the implementations would have to decode the Base58 address into "0x00" > plus the address hash. As the only supported invoice type for the Legacy > signing methods, this should be straight forward to do. > > > And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it > > is "conditionally valid transaction". > > I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help > implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid > instruction. > > - Ali > > On Wed, 10 Aug 2022 04:59:46 +0200, vju...@gazeta.pl wrote: > > > I'm not sure what is to be gained from adding an opcode > > > > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be > > somehow introduced to make it compatible with "Bitcoin Message". And we > > have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is > > "conditionally valid transaction". It is also possible to assign some > > unused opcode, but then it will be more complex, because in Script, those > > opcodes make transaction invalid, but inside TapScript, those opcodes are > > defined as OP_SUCCESS, and make things automatically valid. > > > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
