path: root/9e/bdfff268cf599927076e3e80ea65676a4e2ef6

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 599FBC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 03:30:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 170F883B83
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 03:30:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 170F883B83
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=GKI+gHW2
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iLFCtjfOnZkC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 03:30:30 +0000 (UTC)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com
 [IPv6:2607:f8b0:4864:20::1135])
 by smtp1.osuosl.org (Postfix) with ESMTPS id A376A83B61
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 03:30:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A376A83B61
Received: by mail-yw1-x1135.google.com with SMTP id
 00721157ae682-583d63ca1e9so6701607b3.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 09 Aug 2023 20:30:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1691638229; x=1692243029;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=j6RnSYoZQIgy0W9+NFLholNeYvXLma01Yk6rvGI6xwk=;
 b=GKI+gHW2f5JLe6ZiDVyShjxaeF9hgaC6qoLn/6gvm2K13R6mfM7rnZ7FgARD66y+b9
 Kvdye79vBowpzUxlpVgOj6qoPUMUsP3DBp4+2P51GjZLoSxYo0KvsRUdYXl8Nca5/lPV
 vdXWhdo9U14jHP3EWyUy+y7qmZY42tCFi1cnG39Cx3PZhpQDYeYwyFhMQV/aBSTIBtX4
 OiYP645YGHk/dhYyuaQ4t5jMQHiRsLgzGZDlXeCxVVlSWbZ/53x6F1MGFHU4+EmoFfDS
 203s8BmbbFNJ1of8MgnBwcUU3UJKnaLY0MoyB/kGJ8Fgp8a1uIoX2v8pRlStAbsfB1Us
 /cDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691638229; x=1692243029;
 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=j6RnSYoZQIgy0W9+NFLholNeYvXLma01Yk6rvGI6xwk=;
 b=e6iGC8So3gCmQkelt3cB/OCq2Wl0cx2tUS5O7HPsetIVJivjutiytrX3f+dAvNPN7t
 pQHhC9Kqw4BN06FwVcDBt61i7lZu4IzuSPjZd25wa8usEcQu5nIoyp1hVJSuasu8RaG7
 FxOP3veP5Uof8/zljhVvgMs/M64EicpNEzkcW/RZIGslFQCDLY4O9JF+7cgHTIcJFger
 A7zMOTlcI6zr3c2H9KoS8hjiXfJhtE5Cls3oVXUErFTcBA8l695/OwhB7rwSGwV6MqEd
 1dHDx6d9XFEy1Yo4RYXlTX97hQSTcxaXzi+xwwawzv2FP/Hv3Hg4OqvPDZjUtY2M3R+m
 wC0g==
X-Gm-Message-State: AOJu0YwQ1eejTNh7O5mhrNjeHBpkAPtOfe9dMgIjN66Dw/MU/SXBXgc7
 rzeIQ1PJOs2s8+hno1enYrM5LQlR4nqv8u7stLLNXxM3Jmc=
X-Google-Smtp-Source: AGHT+IFhFyW0ECCeXkQtG+QdxYj4QUye5yx8urpjZCjYSrBZVp8i2QJDx2JyF1PFOdqfuNWKE0fy40I4FNvTy1gKaU0=
X-Received: by 2002:a25:428b:0:b0:d5c:4d20:6245 with SMTP id
 p133-20020a25428b000000b00d5c4d206245mr1385770yba.21.1691638229477; Wed, 09
 Aug 2023 20:30:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <CAJvkSsdAVFf44XXXXhXqV7JcnmV796vttHEtNEp=v-zxehUofw@mail.gmail.com>
 <CAJowKgJFHzXEtJij4K0SR_KvatTZMDfUEU40noMzR2ubj8OSvA@mail.gmail.com>
 <c5ae9d75-e64f-1565-93d0-e2b5df45d3f4@gmail.com>
 <CAJvkSsdRCHA6pB0mMY-7SE4GbDodAR34_RMgPrhEZAAq_8O2Aw@mail.gmail.com>
 <7eae57c9-be42-ae07-9296-ae9e8e03c1b8@gmail.com>
 <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
 <CAJvkSsea+aKJFkNpNxHPAGCxrYwU+8wXOzV-8yH=qacGta++ig@mail.gmail.com>
 <CAJvkSsduvkdhpi=KtTpzXan-wdZrCu9AMbfeZUjuZmfCY774mA@mail.gmail.com>
 <_0pQDclrnsXGHY3tg0IBQSCFoRdiIqHOY1-_KRyqpB99wlrZ30pOdhU753DusijZ0v8uBin1EQOFPfYhRDYekyFK_BoZILHflvLRDvfa86I=@protonmail.com>
 <CAJvkSsexn06j843+54tyt6P_sypx_bRJN46e4kUYg+uHdcNJeQ@mail.gmail.com>
In-Reply-To: <CAJvkSsexn06j843+54tyt6P_sypx_bRJN46e4kUYg+uHdcNJeQ@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Thu, 10 Aug 2023 11:30:02 +0800
Message-ID: <CAH5Bsr1-zTrYNFcSKRf_nVX5LJ6goT8ccDjipWFb6KbSpSq7-A@mail.gmail.com>
To: Tom Trevethan <tom@commerceblock.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c1acf906028937cc"
X-Mailman-Approved-At: Thu, 10 Aug 2023 06:21:08 +0000
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
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, 10 Aug 2023 03:30:32 -0000

--000000000000c1acf906028937cc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tom,

These questions might be wrongheaded since I'm not familiar enough with the
statechain protocol. Here goes:

Why do you need to use schnorr blind signatures for this? Are the blind
signatures being used to produce on-chain tx signatures or are they just
for credentials for transferring ownership (or are they for both). If they
are for on-chain txs then you won't be able to enforce that the signature
used was not generated maliciously so it doesn't seem to me like your trick
above would help you here. I can fully verify that the state chain
signatures were all produced non-maliciously but then there may be another
hidden forged signature that can take the on-chain funds that were produced
by malicious signing sessions I was never aware of (or how can you be sure
this isn't the case).

Following on from that point, is it not possible to enforce sequential
blind signing in the statechain protocol under each key. With that you
don't have the problem of wagner's attack.

LL

On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> @moonsettler
>
> When anyone receives a coin (either as payment or as part of a swap) they
> need to perform a verification of all previous signatures and
> corresponding backup txs. If anything is missing, then the verification
> will fail. So anyone 'breaking the chain' by signing something
> incorrectly simply cannot then send that coin on.
>
> The second point is important. All the 'transfer data' (i.e. new and all
> previous backup txs, signatures and values) is encrypted with the new own=
er
> public key. But the server cannot know this pubkey as this would enable i=
t
> to compute the full coin pubkey and identify it on-chain. Currently, the
> server identifies individual coins (shared keys) with a statechain_id
> identifier (unrelated to the coin outpoint), which is used by the coin
> receiver to retrieve the transfer data via the API. But this means the
> receiver must be sent this identifier out-of-band by the sender, and also
> that if anyone else learns it they can corrupt the server key
> share/signature chain via the API. One solution to this is to have a seco=
nd
> non-identifying key used only for authenticating with the server. This
> would mean a 'statchain address' would then be composed of 2 separate
> pubkeys 1) for the shared taproot address and 2) for server authenticatio=
n.
>
> Thanks,
>
> Tom
>
> On Tue, Aug 8, 2023 at 6:44=E2=80=AFPM moonsettler <moonsettler@protonmai=
l.com>
> wrote:
>
>> Very nice! Is there an authentication mechanism to avoid 'breaking the
>> chain' with an unverifiable new state by a previous owner? Can the curre=
nt
>> owner prove the knowledge of a non-identifying secret he learned as
>> recipient to the server that is related to the statechain tip?
>>
>> BR,
>> moonsettler
>>
>> ------- Original Message -------
>> On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> A follow up to this, I have updated the blinded statechain protocol
>> description to include the mitigation to the Wagner attack by requiring =
the
>> server to send R1 values only after commitments made to the server of th=
e
>> R2 values used by the user, and that all the previous computed c values =
are
>> verified by each new statecoin owner.
>> https://github.com/commerceblock/mercury/blob/master/layer/protocol.md
>>
>> Essentially, the attack is possible because the server cannot verify tha=
t
>> the blinded challenge (c) value it has been sent by the user has been
>> computed honestly (i.e. c =3D SHA256(X1 + X2, R1 + R2, m) ), however thi=
s CAN
>> be verified by each new owner of a statecoin for all the previous
>> signatures.
>>
>> Each time an owner cooperates with the server to generate a signature on
>> a backup tx, the server will require that the owner send a commitment to
>> their R2 value: e.g. SHA256(R2). The server will store this value before
>> responding with it's R1 value. This way, the owner cannot choose the val=
ue
>> of R2 (and hence c).
>>
>> When the statecoin is received by a new owner, they will receive ALL
>> previous signed backup txs for that coin from the sender, and all the
>> corresponding R2 values used for each signature. They will then ask the
>> server (for each previous signature), the commitments SHA256(R2) and the
>> corresponding server generated R1 value and c value used. The new owner
>> will then verify that each backup tx is valid, and that each c value was
>> computed c =3D SHA256(X1 + X2, R1 + R2, m) and each commitment equals
>> SHA256(R2). This ensures that a previous owner could not have generated
>> more valid signatures than the server has partially signed.
>>
>> On Thu, Jul 27, 2023 at 2:25=E2=80=AFPM Tom Trevethan <tom@commerceblock=
.com>
>> wrote:
>>
>>>
>>> On Thu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick <jonasdnick@gmail.co=
m> wrote:
>>>
>>>> No, proof of knowledge of the r values used to generate each R does no=
t
>>>> prevent
>>>> Wagner's attack. I wrote
>>>>
>>>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>>>> > c[0] + ... + c[K-1] =3D c[K].
>>>>
>>>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1]
>>>> and
>>>> define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack would=
n't
>>>> make
>>>> sense if he didn't.
>>>>
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi Tom,</div><div><br></div><div>These questions migh=
t be wrongheaded since I&#39;m not familiar enough with the statechain prot=
ocol. Here goes:</div><div><br></div><div>Why do you need to use schnorr bl=
ind signatures for this? Are the blind signatures being used to produce on-=
chain tx signatures or are they just for credentials for transferring owner=
ship (or are they for both). If they are for on-chain txs then you won&#39;=
t be able to enforce that the signature used was not generated maliciously =
so it doesn&#39;t seem to me like your trick above would help you here. I c=
an fully verify that the state chain signatures were all produced non-malic=
iously but then there may be another hidden forged signature that can take =
the on-chain funds that were produced by malicious signing sessions I was n=
ever aware of (or how can you be sure this isn&#39;t the case).<br></div><d=
iv><br></div><div>Following on from that point, is it not possible to enfor=
ce sequential blind signing in the statechain protocol under each key. With=
 that you don&#39;t have the problem of wagner&#39;s attack.</div><div><br>=
</div><div>LL<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div><a class=3D"gmail_plusr=
eply" id=3D"m_-7071664133923700227plusReplyChip-0">@</a><span style=3D"font=
-family:Arial,sans-serif;font-size:14px">moonsettler</span><br></div><div><=
br></div><div>When anyone receives=C2=A0a coin (either as payment or as par=
t of a swap) they need to perform a verification of all previous signatures=
 and corresponding=C2=A0backup txs. If anything is missing, then the verifi=
cation will fail. So anyone &#39;breaking the chain&#39; by signing somethi=
ng incorrectly=C2=A0simply cannot=C2=A0then send that coin on.=C2=A0</div><=
div><br></div><div>The second point is important. All the &#39;transfer dat=
a&#39; (i.e. new and all previous backup txs, signatures and values) is enc=
rypted with the new owner public key. But the server cannot know this pubke=
y as this would enable it to compute the full coin pubkey and identify it o=
n-chain. Currently, the server identifies individual coins (shared keys) wi=
th a statechain_id identifier (unrelated to the coin outpoint), which is us=
ed by the coin receiver to retrieve the transfer data via the API. But this=
 means the receiver must be sent this identifier out-of-band by the sender,=
 and also that if anyone else learns it they can corrupt the server key sha=
re/signature chain via the API. One solution to this is to have a second no=
n-identifying key used only for authenticating with the server. This would =
mean a &#39;statchain address&#39; would then be composed of 2 separate pub=
keys 1) for the shared taproot address and 2) for server authentication.=C2=
=A0</div><div><br></div><div>Thanks,</div><div><br></div><div>Tom=C2=A0</di=
v><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Aug 8, 2023 at 6:44=E2=80=AFPM moonsettler &lt;<a href=3D"ma=
ilto:moonsettler@protonmail.com" target=3D"_blank">moonsettler@protonmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div>Very nice! Is there an authentication mechanism to avoid &#39;breaki=
ng the chain&#39; with an unverifiable new state by a previous owner? Can t=
he current owner prove the knowledge of a non-identifying secret he learned=
 as recipient to the server that is related to the statechain tip?<br></div=
><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div =
style=3D"font-family:Arial,sans-serif;font-size:14px">BR,</div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">moonsettler<br></div><div =
style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>A follow up to this, I have updated the b=
linded statechain protocol description to include the mitigation to the Wag=
ner attack by requiring the server to send R1 values only after commitments=
 made to the server of the R2 values used by the user, and that all the pre=
vious computed c values are verified by each new statecoin owner. </div><di=
v><a href=3D"https://github.com/commerceblock/mercury/blob/master/layer/pro=
tocol.md" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://gi=
thub.com/commerceblock/mercury/blob/master/layer/protocol.md</a></div><div>=
<br></div><div>Essentially, the attack is possible because the server canno=
t verify that the blinded challenge (c) value it has been sent by the user =
has been computed honestly (i.e. c =3D SHA256(X1 + X2, R1 + R2, m) ), howev=
er this CAN be verified by each new owner of a statecoin for all the previo=
us signatures. </div><div><br></div><div>Each time an owner cooperates with=
 the server to generate a signature on a backup tx, the server will require=
 that the owner send a commitment to their R2 value: e.g. SHA256(R2). The s=
erver will store this value before responding with it&#39;s R1 value. This =
way, the owner cannot choose the value of R2 (and hence c). </div><div><br>=
</div><div>When the statecoin is received by a new owner, they will receive=
 ALL previous signed backup txs for that coin from the sender, and all the =
corresponding R2 values used for each signature. They will then ask the ser=
ver (for each previous signature), the commitments SHA256(R2) and the corre=
sponding server generated R1 value and c value used. The new owner will the=
n verify that each backup tx is valid, and that each c value was computed c=
 =3D SHA256(X1 + X2, R1 + R2, m)  and each commitment equals SHA256(R2). Th=
is ensures that a previous owner could not have generated more valid signat=
ures than the server has partially signed. </div><div><br></div><div class=
=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Thu, Jul 27, 2023=
 at 2:25=E2=80=AFPM Tom Trevethan &lt;<a href=3D"mailto:tom@commerceblock.c=
om" rel=3D"noreferrer nofollow noopener" target=3D"_blank">tom@commercebloc=
k.com</a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_qu=
ote"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div><br>=
</div><div class=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"ltr">On T=
hu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick &lt;<a href=3D"mailto:jonasd=
nick@gmail.com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">jona=
sdnick@gmail.com</a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote">No, proof of knowledge of the r values used to generate ea=
ch R does not prevent<br>
Wagner&#39;s attack. I wrote<br>
<br>
 &gt;   Using Wagner&#39;s algorithm, choose R2[0], ..., R2[K-1] such that<=
br>
 &gt;    c[0] + ... + c[K-1] =3D c[K].<br>
<br>
You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and<=
br>
define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack wouldn&#39=
;t make<br>
sense if he didn&#39;t.<br>
</blockquote></div></div>
</div></div>
</blockquote></div></div>

        </blockquote><br>
    </div></blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c1acf906028937cc--