Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F2F56C002A for ; Thu, 11 May 2023 11:41:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B8DFC401FB for ; Thu, 11 May 2023 11:41:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B8DFC401FB Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=QQdBHK5L X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kex8sGVK0yq for ; Thu, 11 May 2023 11:41:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DA178400F1 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by smtp4.osuosl.org (Postfix) with ESMTPS id DA178400F1 for ; Thu, 11 May 2023 11:41:42 +0000 (UTC) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-55d2e87048cso126088847b3.1 for ; Thu, 11 May 2023 04:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683805301; x=1686397301; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/AVYtdyrXiWGQzuIvuTC6FuyETz9qjz0CICtIcSbI9g=; b=QQdBHK5LgWUytBOabuu5oPA98PZRQDaA0HkH5qcc6vdRRR3X723oe94Dc9DdeYGaNV 6/Embi2tXz8vORks7EJIE7D7hV2lIh7P+uCesZ49QhHdfFSjHLZTuxuL8poJHxaSfzS/ /7LQZ/XQ3sHInLCixA/J7TU11107iGxOIcQVKvXVMotBztTlhXIQzkPfG44537oSAXbS TvPNAFtARKR3tva3GjCYqORY9Terg4YSkC1xQ/AW3PncimGs709FnX3uq6CO+cexWyvu IooTP30HT03U+oBoWS9l4kwoItJPTwnFO91hHsrtcG11ZAGE3Wk/IG7tSU1IWVBZ13iJ qP1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683805301; x=1686397301; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/AVYtdyrXiWGQzuIvuTC6FuyETz9qjz0CICtIcSbI9g=; b=iomESV8MfXsddW3CXTXCceuaJeeQ6bCIkjxkqb+Ew3KVxL7Z2/mmhDmuvZrrIAsrc3 otaxJPeu9/Hv00ziRUqutR7MO9YsXq/P9wdARzKP6y+xKHAsJPJGEOI14OA8LHR4xdT3 aRMy8/KHQTldVMUxT8bT3jsBTQzlKi1Ha8rf0+L+K2fMB/zcF45n9vEKpsff0XPjJKIx y0ivmAmlbh/LnIEQSikECHyu3KtbkTSDEYNrw4pwPN3fdzcbo/Fy8uuCTUFrxJd6hXNo NiYiVsAebeJ0S2eGplnAiMGNrcXyMB01NWs0qfh0zK2CZE3G0Xr1fOP2/N57G/p3jW1t YiVQ== X-Gm-Message-State: AC+VfDzhFfAbwA+pPRX5ze8KTaFByeKPKf5ZEmYOc8/yeItoxtljqciy GruvbZStdyDcAPiOO3M50usE8wyxMrKuCSITh2Y= X-Google-Smtp-Source: ACHHUZ6SF9CXvXLvmUE/NJdT87H8VXlsIXXE7o24iwFM95FaPYY/sQWiytYvdN4XXdEECmh8UHkDKSfVArFcZKBV2QA= X-Received: by 2002:a05:6902:18c2:b0:ba1:66fa:ad35 with SMTP id ck2-20020a05690218c200b00ba166faad35mr21335726ybb.53.1683805301505; Thu, 11 May 2023 04:41:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lloyd Fournier Date: Thu, 11 May 2023 19:41:14 +0800 Message-ID: To: AdamISZ Content-Type: multipart/alternative; boundary="000000000000de020905fb69787b" X-Mailman-Approved-At: Thu, 11 May 2023 11:54:39 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] On adaptor security (in protocols) 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: Thu, 11 May 2023 11:41:45 -0000 --000000000000de020905fb69787b Content-Type: text/plain; charset="UTF-8" On Thu, 11 May 2023 at 13:12, AdamISZ wrote: > > A sidebar, but it immediately brings it to mind: the canonical adaptor > based swap, you can do it with only one half being multisig like this, > right? Alice can encrypt the single-key signature for her payment to Bob, > with the encryption key being T= sG, where s is the partial signature of > Bob, on the payout from a multisig, to Alice. That way Bob only gets his > money in the single sig (A->B) tx, if he reveals his partial sig on the > multisig. I don't think it's of practical interest (1 multisig instead of > 2? meh), but .. I don't see anywhere that potential variant being written > down? Is there some obvious flaw with that? > I think the problem is that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. I think you always need a multisig in these kinds of situations but it need not be a key aggregated multisig like MuSig -- this was the point I wanted to make (in retrospect clumsily). I don't think I can name a useful use of a single signer adaptor signature in Bitcoin at least not without some kind of other spending constraint. So your intuitive point holds in practice most of the time. LL Cheers, > waxwing/AdamISZ > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi Waxwing, > > On Tue, 2 May 2023 at 02:37, AdamISZ wrote: > >> Hi Lloyd, >> thanks for taking a look. >> >> > I think your view of the uselessness of single signer adaptors is too >> pessimistic. The claim you make is that they "don't provide a way to create >> enforcement that the publication of signature on a pre-defined message will >> reveal a secret'' and so are useless. I think this is wrong. If I hold a >> secret key for X and create a signature adaptor with some encryption key Y >> with message m and do not create any further signatures (adaptor or >> otherwise) on m, then any signature on m that is published necessarily >> reveals the secret on Y to me. This is very useful and has already been >> used for years by DLCs in production. >> >> I'm struggling with this one - say I hold privkey x for pubkey X. And I >> publish adaptor for a point Y (DL y) for message m, like: s' = k - y + >> H(R|X|m)x with k the nonce and R the nonce point. >> >> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of >> course the secret y is revealed. >> >> What do you mean in saying "any signature on m that is published reveals >> y"? Clearly you don't mean any signature on any key (i.e. not the key X). >> But I also can't parse it if you mean "any signature on m using key X", >> because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no >> algebraic relationship to the adaptor s' as defined above, right? >> > > Yes but suppose you do *not* create another signature adaptor or otherwise > on m. Since you've only generated one adaptor signature on m and no other > signatures on m there is no possibility that a signature on m that appears > under your key would not reveal y to you. This is an useful property in > theory and in practice. > > >> I think the point of confusion is maybe about the DLC construct? I >> referenced that in Section 4.2, parenthetically, because it's analogous in >> one sense - in MuSig(2) you're fixing R via a negotiation, whereas in >> Dryja's construct you're fixing R "by definition". When I was talking about >> single key Schnorr, I was saying that's what's missing, and thereby making >> them useless. >> >> I was not referencing the DLC oracle attestation protocol - I am pointing > out that DLC client implementations have been using single signer adaptor > signatures as signature encryption in practice for years for the > transaction signatures. There are even channel implementations using them > as well as atomic swaps doing this iirc. It's a pretty useful thing! > > Cheers, > > LL > > > --000000000000de020905fb69787b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 11 May 2023 at 13:12, AdamISZ= <AdamISZ@protonmail.com&g= t; wrote:

A sidebar, but it immediat= ely brings it to mind: the canonical adaptor based swap, you can do it with= only one half being multisig like this, right? Alice can encrypt the singl= e-key signature for her payment to Bob, with the encryption key being T=3D = sG, where s is the partial signature of Bob, on the payout from a multisig,= to Alice. That way Bob only gets his money in the single sig (A->B) tx,= if he reveals his partial sig on the multisig. I don't think it's = of practical interest (1 multisig instead of 2? meh), but .. I don't se= e anywhere that potential variant being written down? Is there some obvious= flaw with that?

I think the prob= lem is that Alice can still move the funds even if Bob decrypts and broadca= sts by revealing s if she gets confirmed first. I think you always need a m= ultisig in these kinds of situations but it need not be a key aggregated mu= ltisig like MuSig -- this was the point I wanted to make (in retrospect clu= msily). I don't think I can name a useful use of a single signer adapto= r signature in Bitcoin at least not without some kind of other spending con= straint. So your intuitive point holds in practice most of the time.

LL

Cheers,
waxwing/AdamISZ

=20
=20
Sent with Proton Mail secure email.

------- Original Message -------
On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:

Hi Waxwing,

On Tue, 2 May 2023 at 02:3= 7, AdamISZ <AdamISZ@protonmail.com> wrote:<= br>
Hi Lloyd,thanks for taking a look.

>= I think your view of the uselessness of single signer adaptors is too pess= imistic. The claim you make is that they "don't provide a way to c= reate enforcement that the publication of signature on a pre-defined messag= e will reveal a secret'' and so are useless. I think this is wrong.= If I hold a secret key for X and create a signature adaptor with some encr= yption key Y with message m and do not create any further signatures (adapt= or or otherwise) on m, then any signature on m that is published necessaril= y reveals the secret on Y to me. This is very useful and has already been u= sed for years by DLCs in production.

= I'm struggling with this one - say I hold privkey x for pubkey X. And I= publish adaptor for a point Y (DL y) for message m, like: s' =3D k - y= + H(R|X|m)x with k the nonce and R the nonce point.

<= /div>
And to get the basics clear first, if I publish s =3D k + H= (R|X|m)x then of course the secret y is revealed.

What do you mean in saying "any signature on m that is pu= blished reveals y"? Clearly you don't mean any signature on any ke= y (i.e. not the key X). But I also can't parse it if you mean "any= signature on m using key X", because if I go ahead and publish s =3D = k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor s' a= s defined above, right?

Yes bu= t suppose you do *not* create another signature adaptor or otherwise on m. = Since you've only generated one adaptor signature on m and no other sig= natures on m there is no possibility that a signature on m that appears und= er your key would not reveal y to you. This is an useful property in theory= and in practice.


I think the point of confusion = is maybe about the DLC construct? I referenced that in Section 4.2, parenth= etically, because it's analogous in one sense - in MuSig(2) you're = fixing R via a negotiation, whereas in Dryja's construct you're fix= ing R "by definition". When I was talking about single key Schnor= r, I was saying that's what's missing, and thereby making them usel= ess.

I was not ref= erencing the DLC oracle attestation protocol - I am pointing out that DLC c= lient implementations have been using single signer adaptor signatures as s= ignature encryption in practice for years for the transaction signatures. T= here are even channel implementations using them as well as atomic swaps do= ing this iirc. It's a pretty useful thing!

Cheers,

LL

--000000000000de020905fb69787b--