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>
In-Reply-To: <LGjk2u_f-UzBsQzz3ZNHt4EeBrf33soxaQMXpmR5-10_zPBirPJhcNvHpNReC9JUAi806J9b4-4Gb1c7I8y77AT9KFwBC8yD2An0mh1mhUQ=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 8 May 2023 12:37:48 +0800
Message-ID: <CAH5Bsr0wQVqi1+r6z0vk8X9UpKyYVAfB_87giUpV=FesmPitrg@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000008e69805fb273555"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On adaptor security (in protocols)
Precedence: list

--00000000000008e69805fb273555
Content-Type: text/plain; charset="UTF-8"

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

--00000000000008e69805fb273555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Waxwing,<br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, 2 May 2023 at 02:37, AdamISZ &=
lt;<a href=3D"mailto:AdamISZ@protonmail.com">AdamISZ@protonmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px"></div><span>Hi Lloyd,</s=
pan><div><span>thanks for taking a look.</span></div><div><br></div><div><s=
pan>&gt; I think your view of the uselessness of single signer adaptors is =
too pessimistic. The claim you make is that they &quot;don&#39;t provide a =
way to create enforcement that the publication of signature on a pre-define=
d message will reveal a secret&#39;&#39; 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.</span></div><div><br></div><di=
v><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></div><div><span>What do you mean in saying &quot;any signature on m t=
hat is published reveals y&quot;? Clearly you don&#39;t mean any signature =
on any key (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 publi=
sh s =3D k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor=
 s&#39; as defined above, right?</span></div></blockquote><div><br></div><d=
iv>Yes but suppose you do *not* create another signature adaptor or otherwi=
se on m. Since you&#39;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.<br></div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><br></div><div><span>I think the poin=
t of confusion is maybe about the DLC construct? I referenced that in Secti=
on 4.2, parenthetically, 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 fixing R &quot;by definition&quot;. When I was talking about si=
ngle key Schnorr, I was saying that&#39;s what&#39;s missing, and thereby m=
aking them useless.</span></div><div><br></div></blockquote><div>=C2=A0</di=
v><div>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&#39;s a pretty useful thing!<br></div=
><div><br></div><div>Cheers,</div><div><br></div><div>LL<br></div></div></d=
iv>

--00000000000008e69805fb273555--