path: root/a1/3de350d8035e6e4dbd671da0cc89aa1dcabec7

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BA260C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Aug 2023 06:32:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 8D90360FAB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Aug 2023 06:32:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8D90360FAB
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=Qyf8SOtm
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Djo7N_HiP7x5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Aug 2023 06:32:10 +0000 (UTC)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com
 [IPv6:2607:f8b0:4864:20::b34])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 55FB560FA4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 14 Aug 2023 06:32:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 55FB560FA4
Received: by mail-yb1-xb34.google.com with SMTP id
 3f1490d57ef6-d3563cb41e9so2754543276.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Aug 2023 23:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1691994729; x=1692599529;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=H5b+uxLKbUCieFgwqZmL2qMw2ZIQcT1vit8Rr4lqTO8=;
 b=Qyf8SOtmVATUfg8KlRd+gun8CzvR0keYyWDFjy1kM0srXhsVaOh3bopJ+7CAt9DgZ8
 JrMU/in/pRjNMETaquSXJYvMQFLAbVafpstBJBMeIGtYEFfFfh/ykQsDHRxSVI9XqgKo
 paxLOWOKOT57Rmxpcpt0FE+PGNSWSCOjQiEqUn1ZQVz1UWKMt29cH7Ja+z2yqk8NDzUF
 GHeytM5hatxUm3P0J+FGrn4DhtbtFmJn7DCaZWyO278v/P0aPhS3NI2AZhwHh9xw5KVE
 NTee8311FK4I+jLD5N/Q/cnaS+JR9Hik7J6MFtVx3jHQSRrK2s1gfq5B3RnJKutjvbx7
 TG5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691994729; x=1692599529;
 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=H5b+uxLKbUCieFgwqZmL2qMw2ZIQcT1vit8Rr4lqTO8=;
 b=f3zJeR4ZnHOH3vKb3GyZIDQwIg3oJ+5STMhrm997NX4BYcv2RtcgQs6Ok1RKxAdd9N
 8PTiGxFbM+dQHlnk8O/6xZSVbdLzVJ5sHe8LsjVUkBFgywhWB/QtPdClVnE4srAXRUfT
 1yGkrLrBLWMjcAQL5fFcaXnINXxxg+9ef+Y0C43rNW6dU9F98mxRz68b0wADNRJuEFwc
 40v3pt2jCW826fUQNBjHwBAmolYlwCs0+b/KkWIBlcgux19ZK/hHWsFXXLrpbzXai7Xh
 Plii8UptDC1vz4zQRUon9DRaeyL5HJi4S3LCmI9kc7w1E88epmsB/Nemru2XWHLwwUII
 DuBA==
X-Gm-Message-State: AOJu0YwiN9cdeVz5gRKjNCCXzkAm+ZiWDY8GflR3YTzi89oLiA2yorc8
 ba0j59rizIa5wrtq+SmJcT1stqIwsgMZ083HdLo=
X-Google-Smtp-Source: AGHT+IET49AqzlUiGAJvpjnruWXG1vtmM0ZEzDXRFNdUsHJMIJjs46SOZ/xjQ2nLnki2E4MY9fBCiv9QTVXdZGYzisI=
X-Received: by 2002:a25:6993:0:b0:d63:5e7:4e1b with SMTP id
 e141-20020a256993000000b00d6305e74e1bmr7234825ybc.26.1691994729217; Sun, 13
 Aug 2023 23:32:09 -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>
 <CAH5Bsr1-zTrYNFcSKRf_nVX5LJ6goT8ccDjipWFb6KbSpSq7-A@mail.gmail.com>
 <CAJvkSsdCeOvKgh2B0rxZu1Hv92Ap8k_92v5ViKKigSOVAeH4hA@mail.gmail.com>
In-Reply-To: <CAJvkSsdCeOvKgh2B0rxZu1Hv92Ap8k_92v5ViKKigSOVAeH4hA@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 14 Aug 2023 14:31:42 +0800
Message-ID: <CAH5Bsr07j38wyUnteuofGiBCWEyrtvnc=yArr1G=6Rg-ji2Cag@mail.gmail.com>
To: Tom Trevethan <tom@commerceblock.com>
Content-Type: multipart/alternative; boundary="000000000000cc04bc0602dc3887"
X-Mailman-Approved-At: Mon, 14 Aug 2023 07:01:22 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Mon, 14 Aug 2023 06:32:12 -0000

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

Hi Tom,

Thanks for the explanation. There's one remaining thing that isn't clear:
do you actually require parallel signing requests under the same key. It
seems to me that the protocol is very sequential in that you are passing a
utxo from one point to another in sequence. If so then the Schnorr blind
sigs problem doesn't apply.

LL

On Thu, 10 Aug 2023 at 20:00, Tom Trevethan <tom@commerceblock.com> wrote:

> HI Lloyd,
>
> Yes, the blind signatures are for bitcoin transactions (these are
> timelocked 'backup txs' if the server disappears). This is not standard
> 'Schnorr blind signature' (like
> https://suredbits.com/schnorr-applications-blind-signatures/) but a
> 2-of-2 MuSig where two keys are required to generate the full signature,
> but one of them (the server) does not learn of either the full key, messa=
ge
> (tx) or final signature.
>
> The server is explicitly trusted to report the total number of partial
> signatures it has generated for a specific key. If you can verify that AL=
L
> the signatures generated for a specific key were generated correctly, and
> the total number of them matches the number reported by the server, then
> there can be no other malicious valid signatures in existence. In this
> statechain protocol, the receiver of a coin must check all previous backu=
p
> txs are valid, and that the total number of them matches the server
> reported signature count before accepting it.
>
> On Thu, Aug 10, 2023 at 4:30=E2=80=AFAM Lloyd Fournier <lloyd.fourn@gmail=
.com>
> wrote:
>
>> 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 th=
ey
>> are for on-chain txs then you won't be able to enforce that the signatur=
e
>> used was not generated maliciously so it doesn't seem to me like your tr=
ick
>> above would help you here. I can fully verify that the state chain
>> signatures were all produced non-maliciously but then there may be anoth=
er
>> hidden forged signature that can take the on-chain funds that were produ=
ced
>> by malicious signing sessions I was never aware of (or how can you be su=
re
>> 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 al=
l
>>> previous backup txs, signatures and values) is encrypted with the new o=
wner
>>> 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, th=
e
>>> 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 al=
so
>>> 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 se=
cond
>>> 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 authenticat=
ion.
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>> On Tue, Aug 8, 2023 at 6:44=E2=80=AFPM moonsettler <moonsettler@protonm=
ail.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 cur=
rent
>>>> 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 requirin=
g 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 previous computed c value=
s 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
>>>> 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 t=
his 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 commitme=
nt to
>>>> their R2 value: e.g. SHA256(R2). The server will store this value befo=
re
>>>> responding with it's R1 value. This way, the owner cannot choose the v=
alue
>>>> 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 th=
e
>>>> server (for each previous signature), the commitments SHA256(R2) and t=
he
>>>> corresponding server generated R1 value and c value used. The new owne=
r
>>>> will then verify that each backup tx is valid, and that each c value w=
as
>>>> computed c =3D SHA256(X1 + X2, R1 + R2, m) and each commitment equals
>>>> SHA256(R2). This ensures that a previous owner could not have generate=
d
>>>> more valid signatures than the server has partially signed.
>>>>
>>>> On Thu, Jul 27, 2023 at 2:25=E2=80=AFPM Tom Trevethan <tom@commerceblo=
ck.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.
>>>>>>
>>>>>
>>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>

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

<div dir=3D"ltr"><div>Hi Tom,</div><div><br></div><div>Thanks for the expla=
nation. There&#39;s one remaining thing that isn&#39;t clear: do you actual=
ly require parallel signing requests under the same key. It seems to me tha=
t the protocol is very sequential in that you are passing a utxo from one p=
oint to another in sequence. If so then the Schnorr blind sigs problem does=
n&#39;t apply.</div><div><br></div><div>LL<br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 10 Aug 2023 at =
20:00, Tom Trevethan &lt;<a href=3D"mailto:tom@commerceblock.com">tom@comme=
rceblock.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>HI=C2=A0Lloyd,</div><div><br></div><div>Y=
es, the blind signatures are for bitcoin transactions (these are timelocked=
=C2=A0&#39;backup txs&#39; if the server disappears). This is not standard =
&#39;Schnorr blind signature&#39; (like=C2=A0<a href=3D"https://suredbits.c=
om/schnorr-applications-blind-signatures/" target=3D"_blank">https://suredb=
its.com/schnorr-applications-blind-signatures/</a>) but a 2-of-2 MuSig wher=
e two keys are required to generate the full signature, but one of them (th=
e server) does not learn of either the full key, message (tx) or final sign=
ature.=C2=A0</div><div><br></div><div>The server is explicitly trusted to r=
eport the total number of partial signatures it has generated for a specifi=
c key. If you can verify that ALL the signatures generated for a specific k=
ey were generated correctly, and the total number of them matches the numbe=
r reported by the server, then there can be no other malicious valid signat=
ures in existence. In this statechain protocol, the receiver of a coin must=
 check all previous backup txs are valid, and that the total number of them=
 matches the server reported signature count before accepting it.=C2=A0</di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, Aug 10, 2023 at 4:30=E2=80=AFAM Lloyd Fournier &lt;<a href=3D"mailto:ll=
oyd.fourn@gmail.com" target=3D"_blank">lloyd.fourn@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div>Hi Tom,</div><div><br></div><div>These questions might be wrongheade=
d since I&#39;m not familiar enough with the statechain protocol. Here goes=
:</div><div><br></div><div>Why do you need to use schnorr blind signatures =
for this? Are the blind signatures being used to produce on-chain tx signat=
ures or are they just for credentials for transferring ownership (or are th=
ey for both). If they are for on-chain txs then you won&#39;t be able to en=
force 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 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 fu=
nds that were produced by malicious signing sessions I was never aware of (=
or how can you be sure this isn&#39;t the case).<br></div><div><br></div><d=
iv>Following on from that point, is it not possible to enforce sequential b=
lind 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<b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-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 rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><a class=3D"gmail_pl=
usreply" id=3D"m_-2042205675039869504m_-7240174161672840276m_-7071664133923=
700227plusReplyChip-0">@</a><span style=3D"font-family:Arial,sans-serif;fon=
t-size:14px">moonsettler</span><br></div><div><br></div><div>When anyone re=
ceives=C2=A0a coin (either as payment or as part of a swap) they need to pe=
rform a verification of all previous signatures and corresponding=C2=A0back=
up txs. If anything is missing, then the verification will fail. So anyone =
&#39;breaking the chain&#39; by signing something incorrectly=C2=A0simply c=
annot=C2=A0then send that coin on.=C2=A0</div><div><br></div><div>The secon=
d point is important. All the &#39;transfer data&#39; (i.e. new and all pre=
vious backup txs, signatures and values) is encrypted with the new owner pu=
blic 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 serv=
er identifies individual coins (shared keys) with a statechain_id identifie=
r (unrelated to the coin outpoint), which is used by the coin receiver to r=
etrieve 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 els=
e learns it they can corrupt the server key share/signature chain via the A=
PI. 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 addres=
s&#39; would then be composed of 2 separate pubkeys 1) for the shared tapro=
ot address and 2) for server 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 moonsettler &lt;<a href=3D"mailto:moonsettler@protonmail=
.com" target=3D"_blank">moonsettler@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>Very nice! Is there =
an authentication mechanism to avoid &#39;breaking the chain&#39; with an u=
nverifiable new state by a previous owner? Can the 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-se=
rif;font-size:14px">moonsettler<br></div><div style=3D"font-family:Arial,sa=
ns-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>
</blockquote></div></div>
</blockquote></div>

--000000000000cc04bc0602dc3887--