Date: Wed, 10 Aug 2022 16:42:10 +0000
To: vjudeu@gazeta.pl
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <20220810164204.5toj4tph52lehpvv@artanis>
In-Reply-To: <166373835-fcb0adc6e7c70aa2d37a60a977c1af89@pmq4v.m5r2.onet>
References: <166373835-fcb0adc6e7c70aa2d37a60a977c1af89@pmq4v.m5r2.onet>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Regarding BIP322 edge cases
Precedence: list

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 proponen=
ts do not have BCH script compatibility on a high prioirty, perhaps not eve=
n medium prioity, so we should be able to make an opcode called OP_CHECKDAT=
ASIG 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 direct=
ly impact miners?) with an activation height. If we want to redefine an exi=
sting opcode, we must also make a similar soft-fork. Because consensus rule=
s are being modified here.

At the same time, a message signing/verifying algorithm using Script must i=
mplement some way to verify a *single* ECDSA or Schnorr signature that is o=
n the stack. The existing opcodes such as OP_CHECKSIG verify all of the inp=
uts and outputs, and this won't work here since there's a deliberate invali=
d iput in "to_spend".

I tried to research if there is any known use of OP_RESERVED in a script, e=
ven if it's only of academic origin, but I unfortunately could not find any=
 references except for https://bitcoin.stackexchange.com/questions/105778/w=
hy-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, vjudeu@gazeta.pl wrote:
> > I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKD=
ATASIG 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_SWA=
P OP_CHECKSIG" is always spendable, for any valid <r,s> DER-encoded pair. H=
ere, if "<signature> <messageHash> <pubkey> OP_CHECKDATASIG" works for sign=
ature verification BIP, then you only need to provide "<signature>" as an i=
nput, the rest could be placed in some output, and your program could easil=
y compute that. Or you can use "OP_DUP OP_HASH160 <address> OP_EQUALVERIFY =
<messageHash> OP_SWAP OP_CHECKDATASIG" as your output script, then the sign=
er 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 y=
ourself.
>
> Because if OP_CHECKDATASIG is not handled, then still, signing by scripts=
 can handle that, but the Script would be unnecessarily complex. And becaus=
e 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 instruc=
tion.
>
> Because if you want to support any script, and you want to add a new opco=
de, 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 wi=
ll get OP_CHECKSIGADD or other opcodes from TapScript, so your script decod=
er will no longer handle two script versions at once. Unless you want to ma=
ke it also compatible with altcoins like BCH, but I guess it is not needed.
>
>
> On 2022-08-10 15:53:31 user Ali Sherief <ali@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_CHECKDAT=
ASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA p=
ublic key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid bet=
ween OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.
>
> But the implementations would have to decode the Base58 address into "0x0=
0" 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, the=
n it is "conditionally valid transaction".
>
> I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help im=
plement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instructi=
on.
>
> - Ali
>
> On Wed, 10 Aug 2022 04:59:46 +0200, vjudeu@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 t=
o be somehow introduced to make it compatible with "Bitcoin Message". And w=
e 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.
> >
> >