path: root/71/fef3933013ed745e1e212892e1b825c79c170b

Return-Path: <tom@commerceblock.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 227F2C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 15:14:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0A062402E8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 15:14:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0A062402E8
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=commerceblock-com.20221208.gappssmtp.com
 header.i=@commerceblock-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=K7HdzfVQ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=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 44wlzPYU4TDL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 15:14:50 +0000 (UTC)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [IPv6:2a00:1450:4864:20::62d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 988D940469
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Aug 2023 15:14:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 988D940469
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-99bf9252eddso1023435866b.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 09 Aug 2023 08:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1691594087;
 x=1692198887; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=9VPX7TbteBuOwOfsgYc3/XlrLXIWjO/diSNfVaLen0U=;
 b=K7HdzfVQi8cUpf81omx/kJEOxYVL0DClCUrVXW51Bs/6y9tO5cuc/CwVBV6/a0Wo8C
 SNe0fEPl2sSBzCeiyIs554rSYa4fZIbhWJWO/ws6jAhEvQkLxDCnnyWP+v71oNjEeHm7
 9uv+B509IYKaap/98Q/0BdpmoL3P9Anrv3benjQ756IFMKFFARtczZ/T+VHUTTBloGuH
 vdwoAbPPcMTFI9cMFjRJjal6PPRegW90vwQIIEucdG9jAv9J/rZReteqn1rw+jMSVlCz
 uP/r8AN/F4Jmm/6i09Yk4r8TyoT/KNAvEJOwMHBUu0makcn1G//5kuiseD3s/tqpwhA6
 /+4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691594087; x=1692198887;
 h=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=9VPX7TbteBuOwOfsgYc3/XlrLXIWjO/diSNfVaLen0U=;
 b=AwxLDOmzAzU9NgFUnr+TeR9m5/WOMFlqbfPLY+TgeSao3o8RDWhRyG4s5NeCDkl5t8
 5IwtqBEnjD++zHe0qbwY4sRrxyRxI0SsEZmtPdDeHn1eb9wH/gD+Dhgld8Y2sw6xkYlS
 5Ek9YfTcNZ2STmmRJL9ezcNGnH3Vs4xB/xr6wmpJrsmDm/vtxhqWa5g2f8OsfCcOVgcC
 HR0OfXu3adiKmc9b6+4nDclIVMsiBg5UuIeVdzWMjPGNpCICZhANwI0JCoFUosq1L9Tv
 PMUhvUBFaSUUigD1uwlth/oSj/mscjQBoq/qqPheBlpJ7we44Y1Q1MWEDnuBQrIRgBiE
 xoOw==
X-Gm-Message-State: AOJu0YxlNYf8KhQ/j9PoSPXSN2cY8c238ElVbowEmLpdbesalo+ynmLt
 nMsf/1fLj7ChSJciTaaCsn8EAuhRt7bAoKhUENPKFF/GforvWzh69w==
X-Google-Smtp-Source: AGHT+IHt9PS59qIiEAt7oI66RK2oceWdJXS4cearByEPBvGC778C+gPWfTiCdJBfRcgiBixh/LlnwxBac18TR9KTvqE=
X-Received: by 2002:a17:906:2258:b0:99b:22dd:f83d with SMTP id
 24-20020a170906225800b0099b22ddf83dmr2338697ejr.55.1691594087309; Wed, 09 Aug
 2023 08:14:47 -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>
In-Reply-To: <_0pQDclrnsXGHY3tg0IBQSCFoRdiIqHOY1-_KRyqpB99wlrZ30pOdhU753DusijZ0v8uBin1EQOFPfYhRDYekyFK_BoZILHflvLRDvfa86I=@protonmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Wed, 9 Aug 2023 16:14:36 +0100
Message-ID: <CAJvkSsexn06j843+54tyt6P_sypx_bRJN46e4kUYg+uHdcNJeQ@mail.gmail.com>
To: moonsettler <moonsettler@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000adb52306027ef0ce"
X-Mailman-Approved-At: Wed, 09 Aug 2023 15:33:39 +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: Wed, 09 Aug 2023 15:14:52 -0000

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

@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 owner
public key. But the server cannot know this pubkey as this would enable it
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 second
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 authentication.

Thanks,

Tom

On Tue, Aug 8, 2023 at 6:44=E2=80=AFPM moonsettler <moonsettler@protonmail.=
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 curren=
t
> 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 t=
he
> server to send R1 values only after commitments made to the server of the
> R2 values used by the user, and that all the previous computed c values a=
re
> 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 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) ), however this=
 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 valu=
e
> 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.com=
> wrote:
>>
>>> No, proof of knowledge of the r values used to generate each R does not
>>> 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 wouldn=
't
>>> make
>>> sense if he didn't.
>>>
>>
>

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

<div dir=3D"ltr"><div><a class=3D"gmail_plusreply" id=3D"plusReplyChip-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 (eith=
er as payment or as part of a swap) they need to perform a verification of =
all previous signatures and corresponding=C2=A0backup txs. If anything is m=
issing, then the verification will fail. So anyone &#39;breaking the chain&=
#39; by signing something incorrectly=C2=A0simply cannot=C2=A0then send tha=
t coin on.=C2=A0</div><div><br></div><div>The second point is important. Al=
l the &#39;transfer data&#39; (i.e. new and all previous backup txs, signat=
ures and values) is encrypted with the new owner public key. But the server=
 cannot know this pubkey as this would enable it to compute the full coin p=
ubkey 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 dat=
a 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 cor=
rupt the server key share/signature chain via the API. One solution to this=
 is to have a second non-identifying key used only for authenticating with =
the server. This would mean a &#39;statchain address&#39; would then be com=
posed of 2 separate pubkeys 1) for the shared taproot address and 2) for se=
rver authentication.=C2=A0</div><div><br></div><div>Thanks,</div><div><br><=
/div><div>Tom=C2=A0</div><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 moonse=
ttler &lt;<a href=3D"mailto:moonsettler@protonmail.com">moonsettler@protonm=
ail.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-lef=
t:1ex"><div>Very nice! Is there an authentication mechanism to avoid &#39;b=
reaking the chain&#39; with an unverifiable new state by a previous owner? =
Can the current owner prove the knowledge of a non-identifying secret he le=
arned 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 st=
yle=3D"font-family:Arial,sans-serif;font-size:14px">moonsettler<br></div><d=
iv 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>

--000000000000adb52306027ef0ce--