path: root/df/2d89508fc141926b1e07f0de651397aeb4b8fb

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F2F56C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 11:41:42 +0000 (UTC)
Received: by mail-yw1-x112d.google.com with SMTP id
 00721157ae682-55d2e87048cso126088847b3.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com>
 <CAH5Bsr28mgcLjO43pJKmk7HYKqp9m2eJ0UcGfgOS+H4sFqcTYw@mail.gmail.com>
 <LGjk2u_f-UzBsQzz3ZNHt4EeBrf33soxaQMXpmR5-10_zPBirPJhcNvHpNReC9JUAi806J9b4-4Gb1c7I8y77AT9KFwBC8yD2An0mh1mhUQ=@protonmail.com>
 <CAH5Bsr0wQVqi1+r6z0vk8X9UpKyYVAfB_87giUpV=FesmPitrg@mail.gmail.com>
 <BQClOoj6CuBhYCAaLFZyoUvmKuiueRtp6Jv0y1GU85uP4WJyH6acQwceQpGFOSpihR135pTJx5aLFtr-EDA8LQWfkAmo9RS6UCJj5-H8cX8=@protonmail.com>
In-Reply-To: <BQClOoj6CuBhYCAaLFZyoUvmKuiueRtp6Jv0y1GU85uP4WJyH6acQwceQpGFOSpihR135pTJx5aLFtr-EDA8LQWfkAmo9RS6UCJj5-H8cX8=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Thu, 11 May 2023 19:41:14 +0800
Message-ID: <CAH5Bsr30dtyCNrkKc4UNecKspetJY_jFTXtZtp2NTXPXM12jQg@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000de020905fb69787b"
X-Mailman-Approved-At: Thu, 11 May 2023 11:54:39 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <AdamISZ@protonmail.com> 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 <https://proton.me/> 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 <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-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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, 11 May 2023 at 13:12, AdamISZ=
 &lt;<a href=3D"mailto:AdamISZ@protonmail.com">AdamISZ@protonmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">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-&gt;B) tx,=
 if he reveals his partial sig on the multisig. I don&#39;t think it&#39;s =
of practical interest (1 multisig instead of 2? meh), but .. I don&#39;t se=
e anywhere that potential variant being written down? Is there some obvious=
 flaw with that?<br></div></blockquote><div><br></div><div>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&#39;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.<br></d=
iv><div><br></div><div>LL<br></div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px">Cheers,<br></div><div style=3D"font-family:Arial,sans-serif;font-s=
ize:14px">waxwing/AdamISZ</div><div style=3D"font-family:Arial,sans-serif;f=
ont-size:14px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
        Sent with <a href=3D"https://proton.me/" rel=3D"noopener noreferrer=
" target=3D"_blank">Proton Mail</a> secure email.
    </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>Hi Waxwing,<br></div><br><div class=3D"gm=
ail_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Tue, 2 May 2023 at 02:3=
7, AdamISZ &lt;<a href=3D"mailto:AdamISZ@protonmail.com" rel=3D"noreferrer =
nofollow noopener" target=3D"_blank">AdamISZ@protonmail.com</a>&gt; wrote:<=
br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div style=3D"fo=
nt-family:Arial,sans-serif;font-size:14px"></div><span>Hi Lloyd,</span><div=
><span>thanks for taking a look.</span></div><div><br></div><div><span>&gt;=
 I think your view of the uselessness of single signer adaptors is too pess=
imistic. The claim you make is that they &quot;don&#39;t provide a way to c=
reate enforcement that the publication of signature on a pre-defined messag=
e will reveal a secret&#39;&#39; 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.</span></div><div><br></div><div><span>=
I&#39;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&#39; =3D k - y=
 + H(R|X|m)x with k the nonce and R the nonce point.</span></div><div><br><=
/div><div><span>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.</span></div><div><br></di=
v><div><span>What do you mean in saying &quot;any signature on m that is pu=
blished reveals y&quot;? Clearly you don&#39;t mean any signature on any ke=
y (i.e. not the key X). But I also can&#39;t parse it if you mean &quot;any=
 signature on m using key X&quot;, 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&#39; a=
s defined above, right?</span></div></blockquote><div><br></div><div>Yes bu=
t suppose you do *not* create another signature adaptor or otherwise on m. =
Since you&#39;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.<br></div><div> <br></div><blockquote style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" clas=
s=3D"gmail_quote"><div><br></div><div><span>I think the point of confusion =
is maybe about the DLC construct? I referenced that in Section 4.2, parenth=
etically, because it&#39;s analogous in one sense - in MuSig(2) you&#39;re =
fixing R via a negotiation, whereas in Dryja&#39;s construct you&#39;re fix=
ing R &quot;by definition&quot;. When I was talking about single key Schnor=
r, I was saying that&#39;s what&#39;s missing, and thereby making them usel=
ess.</span></div><div><br></div></blockquote><div> </div><div>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&#39;s a pretty useful thing!<br></div><div><br></div><div=
>Cheers,</div><div><br></div><div>LL<br></div></div></div>

        </blockquote><br>
    </div></blockquote></div></div>

--000000000000de020905fb69787b--