From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E6DF9C002D for ; Sat, 21 May 2022 21:24:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DDBCA60E90 for ; Sat, 21 May 2022 21:24:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAqLYUdeG4nM for ; Sat, 21 May 2022 21:24:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9AB306058C for ; Sat, 21 May 2022 21:24:46 +0000 (UTC) Date: Sat, 21 May 2022 21:24:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1653168283; x=1653427483; bh=lQFUNPy0+nSdQLDhvmbWZZgngpf/Cy90B8GY4o1AaZA=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=W6k75pcldGKSJliTcriuHn3fhjZ47g6XVughqUC2OA9GbkdUVicOlbSSGrmoPltuK vM3hWXUZ/vYALKnAcpQG9300O7AfA+XOCrABwKEG4sotVFpwMHDN62Z600Chq8HQT6 mjXyNqIfXm3MwAAP97T+jRsL924UsP+Sf3V0btcdCzWr3UWqg++T2QTu/sCGWI2xyz yBcxNUvfnHfksa9Jz5/EPYCC/zyyfxtjdYbuwKUB/FVxllWaOOotdMuY+EjQ88q1Zw KXUC64xSLze3BB4pkQGNhVgqkw6v2quNTyZvW/GskCAn4/SKPXgIOO6BZYh1Olgm0U vVtlCsI8Nex7A== To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet> References: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet> Feedback-ID: 11565511:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 22 May 2022 14:29:01 +0000 Subject: Re: [bitcoin-dev] Pay to signature hash as a covenant 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: Sat, 21 May 2022 21:24:48 -0000 Sent with ProtonMail secure email. ------- Original Message ------- On Tuesday, May 3rd, 2022 at 02:37, vjudeu via bitcoin-dev wrote: > Typical P2PK looks like that: " OP_CHECKSIG". In a ty= pical scenario, we have "" in out input and " OP_CHECKSI= G" in our output. I wonder if it is possible to use covenants right here an= d right now, with no consensus changes, just by requiring a specific signat= ure. To start with, I am trying to play with P2PK and legacy signatures, bu= t it may turn out, that doing such things with Schnorr signatures will be m= ore flexible and will allow more use cases. > > > The simplest "pay to signature" script I can think of is: " OP= _SWAP OP_CHECKSIG". Then, any user can provide just a "" in some in= put, as a part of a public key recovery. The problem with such scheme is th= at it is insecure. Another problem is that we should handle it carefully, b= ecause signatures are removed from outputs. However, we could replace it wi= th some signature hash, then it will be untouched, for example: "OP_TOALTST= ACK OP_DUP OP_HASH160 OP_EQUALVERIFY OP_FROMALTSTACK OP_CHE= CKSIG". > Doesn't this suffer from the standard "circular reference" problem for cove= nants? To pay to a utxo U1, whose scriptpubkey is a (p2wsh wrapped, say) sc= ript of: sig, op_checksig, I must create that sig, using my chosen public k= ey, and a message which is a (signature style) hashing of a tx TX1, where a= n/the input to TX1 is U1, and the txid of U1 'hashes over' that script, whi= ch includes the sig we're trying to create. You can't make a hash of data w= hich includes that hash (unless the hash fn is broken ofc). I don't think that's affected by the later discussion here or in Zmn's resp= onse right? Also a side detail which you might find useful in these ponderings: pubkey = recovery is, as you know, possible in ECDSA but is not possible in BIP340 s= chnorr (which has key prefixing, i.e. the pubkey is included in the message= hash binding, i.e. the e in s =3D k + ex), but is in the original Schnorr = where only R(=3DkG), m are included in e. Easy to see why: from R, s and e(= =3DH(R,m) .. easy to calculate) you can get P =3D (sG - R)* e^-1. But in BIP340 Schnorr where (R, s) is published and e (=3DH(P, R, m)) is no= t, you cannot reconstruct e and so can only calculate e*P, which by DL assu= mption does not reveal P. Another way to put it is: if you made up a random= R, s you wouldn't be able to find the right 'P' to put into e=3DH(P, R, m)= so that the same P came out, and so that the sig actually verifies. Cheers, waxwing/AdamISZ