From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4D3D4C002D for ; Wed, 10 Aug 2022 16:42:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 96AB040586 for ; Wed, 10 Aug 2022 16:42:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 96AB040586 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=notatether.com header.i=@notatether.com header.a=rsa-sha256 header.s=protonmail header.b=stLDUhBu X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwKvG1IPAXVj for ; Wed, 10 Aug 2022 16:42:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org BE7D640189 Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) by smtp2.osuosl.org (Postfix) with ESMTPS id BE7D640189 for ; Wed, 10 Aug 2022 16:42:28 +0000 (UTC) Date: Wed, 10 Aug 2022 16:42:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com; s=protonmail; t=1660149745; x=1660408945; bh=Mbn60EsixqQf/p0q7uxa/cQngI9rwLW7hhAO7udOpH4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=stLDUhBuLJKd2CNtSww5WJjKvqwH8khq0rS6iPiToB4ouMZKGFWVjFv7FM27dxgvu E1V/xCGvVHcyoku9UQmA6qfFA2cb+9HplBV8txy70fIQV9UcSVMdqNst6txIsl0Edy GvHyPHlirBFrAIFtn0KqkbJ6EFB1APceL6CgfK9K/f97eVCRCLqLaBCv4T5O5lzwnx BNksumO66WE0aYP+Nm9XZ5Kp4BBkzBV+pBdldS8Oe6xBHHxm6heV1EK5qT8+D/VbLG ZYA+0JLo0bSVMV+WhDtJRGHobmAsyXkuWNtD3IK+K+RcPtem+4BIwA+zd3JA28tWeA 7B/ZLsN9FlD7g== To: vjudeu@gazeta.pl From: Ali Sherief Reply-To: Ali Sherief 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 X-Mailman-Approved-At: Wed, 10 Aug 2022 16:43:37 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Regarding BIP322 edge cases X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2022 16:42:31 -0000 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 off the stack and perform an ECDSA= public key recovery > > You can always perform key recovery for legacy ECDSA: " OP_SWA= P OP_CHECKSIG" is always spendable, for any valid DER-encoded pair. H= ere, if " OP_CHECKDATASIG" works for sign= ature verification BIP, then you only need to provide "" 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
OP_EQUALVERIFY = 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 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 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. > > > >