path: root/4d/47c6d476498b6229ca6948eec4734040a2322f

Return-Path: <ali@notatether.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4D3D4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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.
> >
> >