Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4F3B6C002A for ; Mon, 8 May 2023 04:38:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1485E4059D for ; Mon, 8 May 2023 04:38:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1485E4059D 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=kb8jbwVs 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 EGAqoO1LHf7x for ; Mon, 8 May 2023 04:38:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D09BB40547 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by smtp4.osuosl.org (Postfix) with ESMTPS id D09BB40547 for ; Mon, 8 May 2023 04:38:16 +0000 (UTC) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-55a64f0053fso61053067b3.3 for ; Sun, 07 May 2023 21:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683520696; x=1686112696; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Lwv1JmoWD7od9veF4V83yiX38Q6AAkLicLcXCb1CoT4=; b=kb8jbwVsMK3fvNcbAaKns1lylqtn+vNFVE2l725X7EYakgh/pqhy8amaro54k/dL3L AlzRZzqLydiGeica1umJkvh1CAtiJ4TErvDmhEKxt2dPlT4vc6Z4Cd4UqIzS3DR0EVd2 OUpRWODO9OUOuAYvwfGQhBtZ+QPU0pTkVztGssaK+214rMUV/hxY17XmVygb0zXALsgQ Y8ELfdWPDzRrRU+RFyPZjGOuBWNxjwek4GkwqHlE+ZG/ohGMApZFlDnWp75r9pme9GLt JjcTvmQ0sL60F/6I8BtyawxtIsVoq5x5ZEEVDQf8+ipealbhdpfXdw7rHc2ItZPaYXQJ xVqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683520696; x=1686112696; 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=Lwv1JmoWD7od9veF4V83yiX38Q6AAkLicLcXCb1CoT4=; b=EmySik14JuMvd4YGeYDvddt5qhMwI7EeBNYZXhhp0ZtxTchLvAdsvmIbNBxtzn5tVl nHkBsrne17048WyAhShyrqqAcbSuGrofgn9nRlDuNSHOPcW54BSf57HFqrMCuE+bEtdw LTmtmtilxYibAcc8paeqmn2BA0q4LFfZH51/cK/37UtEiFznHQlhaDpP+PeOdyfSkQLI 0tFxhhmwW4W/pO7p38NkUiDqxu9eyg30w5dqjO/SpL0aaEDY2muKg7Ou+0rw5JNrRhuA SRcfMZBcQPA2atbxCzQroMP9zcO0E+RoQ9M+aPyn+NFoMAz5+M+if1ZM1awk6w5l6ZaM scvw== X-Gm-Message-State: AC+VfDz0rEKzFEuXsiDJ8L/GN46MVvAveEmiDvSlZTCn3DRX470b7iD9 tEIq43YC1d45prmJFtnEeSa4YdoXNZ55DIfHlzY= X-Google-Smtp-Source: ACHHUZ7l+1m1cxXkmxPv0eQVPJzM7H78QfHTgoS7WQfVvUOPWfVdbdiraPCN38TdMpCiseGXIUKlS9An/OamqVrcPqs= X-Received: by 2002:a81:a0d5:0:b0:54f:bec1:c106 with SMTP id x204-20020a81a0d5000000b0054fbec1c106mr7407442ywg.45.1683520695624; Sun, 07 May 2023 21:38:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lloyd Fournier Date: Mon, 8 May 2023 12:37:48 +0800 Message-ID: To: AdamISZ Content-Type: multipart/alternative; boundary="00000000000008e69805fb273555" X-Mailman-Approved-At: Mon, 08 May 2023 11:54:58 +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: Mon, 08 May 2023 04:38:18 -0000 --00000000000008e69805fb273555 Content-Type: text/plain; charset="UTF-8" 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 --00000000000008e69805fb273555 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Waxwing,

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, 2 May 2023 at 02:37, AdamISZ &= lt;AdamISZ@protonmail.com>= 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-define= d message will reveal a secret'' and so are useless. I think this i= s wrong. If I hold a secret key for X and create a signature adaptor with s= ome encryption key Y with message m and do not create any further signature= s (adaptor or otherwise) on m, then any signature on m that is published ne= cessarily reveals the secret on Y to me. This is very useful and has alread= y 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' = =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 t= hat 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 publi= sh s =3D 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 otherwi= se 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 ap= pears under your key would not reveal y to you. This is an useful property = in theory and in practice.
=C2=A0

I think the poin= t of confusion is maybe about the DLC construct? I referenced that in Secti= on 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 si= ngle key Schnorr, I was saying that's what's missing, and thereby m= aking them useless.

=C2=A0
I was not referencing the DLC oracle attestation protocol - I am poi= nting out that DLC client implementations have been using single signer ada= ptor signatures as signature encryption in practice for years for the trans= action signatures. There are even channel implementations using them as wel= l as atomic swaps doing this iirc. It's a pretty useful thing!

Cheers,

LL
--00000000000008e69805fb273555--