path: root/71/ee19820392bc5d1fde5ee2fe6b1003d0b13e99

Return-Path: <tom@commerceblock.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7F93DC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 12:00:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 333A861201
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 12:00:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 333A861201
Authentication-Results: smtp3.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=lH6i4JUn
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NeO-vRDIXDWI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 12:00:06 +0000 (UTC)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [IPv6:2a00:1450:4864:20::632])
 by smtp3.osuosl.org (Postfix) with ESMTPS id D8A5F60D73
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 12:00:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D8A5F60D73
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-99bf91956cdso116611166b.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 05:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1691668804;
 x=1692273604; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=PwBvG3Z/a8vmNKgyVac+usWP9+diqbH4RZ0EdaAVHDg=;
 b=lH6i4JUnCH17Pje6BikMVipgRbBxh9O/8ej0Tc6EjbgN604FivLbU9Koq6NBZhBneX
 /rsPvU4BIKD1AgDSn31Hft0YXE1aJCcPxnJUrGn7Jyp1la8FNooSIy4pxF9T4uoV5GYw
 BfAcgeD9srezancVPngQCvUH/rstqqyB/xTRpo495+hyHtqbhhSp+Z7CaF7g8Jpf/bl5
 p0aJxjkI8sXuEBnZ8BFeud3IfQsKHxEya/Rqpyjc/EXJTfIHk+3lvEJj95+/UZpSvHj9
 6eJCNw5c4r7wQv7yplO7WNV8oK2yj9DauZEcso3PxcX1ANcZdxItQIzNC1lqiWK8qwqI
 PM6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691668804; x=1692273604;
 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=PwBvG3Z/a8vmNKgyVac+usWP9+diqbH4RZ0EdaAVHDg=;
 b=ZcbuhM0LYY62M5I7sgx6VytSuDhAGwHnN2y2N4SQ4qzGNtnCbuk8qaRV9MdanyTin4
 +IFGIIOGaxy4a/6W8cS6PneT+cJjV8LOo03cftyQ88V3Ov7RBw/OwkXFsRpOO8kc/6LP
 rjmD86rD08BTO5MOI/5TJtgo0y6V74OaJxJOZCQI73idHogdPWS4AlEsRom50VvI2a6M
 9W0yytbPzO9/qolWMQ3le5SMkHhfZJZI6ez3nX0aRO1LBnEBfrFNsjYDhVsbXrswdNMC
 gnAAQ/SwB1Q7OY09GMsm9F6JyJA/ey6fEpLasWrycHXLOy7YTINhQb+/SV7ThocclEEN
 dyuQ==
X-Gm-Message-State: AOJu0Ywc7F2gMN7l6jTKLTfG5Ei9rXcOelORXZ/zKmktE1+iAHvTnzz5
 ac6Hu2bpSBb4Ze8eHFd5Qtlag2TwOBfRXw9o++Dq
X-Google-Smtp-Source: AGHT+IHr3Wp6EV/1FAkddbMGlZHMCqGn02I7XPz4O4AojM9sigJ8+NfqMzwbWo52/lEVwb8rSxuvqkO8q039SwoEoVA=
X-Received: by 2002:a17:906:1041:b0:99b:d440:bf0b with SMTP id
 j1-20020a170906104100b0099bd440bf0bmr1829053ejj.67.1691668803797; Thu, 10 Aug
 2023 05:00:03 -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>
In-Reply-To: <CAH5Bsr1-zTrYNFcSKRf_nVX5LJ6goT8ccDjipWFb6KbSpSq7-A@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Thu, 10 Aug 2023 12:59:52 +0100
Message-ID: <CAJvkSsdCeOvKgh2B0rxZu1Hv92Ap8k_92v5ViKKigSOVAeH4hA@mail.gmail.com>
To: Lloyd Fournier <lloyd.fourn@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000020e24c06029056e5"
X-Mailman-Approved-At: Thu, 10 Aug 2023 13:35:57 +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: Thu, 10 Aug 2023 12:00:09 -0000

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

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, message (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 ALL
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 backup
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.c=
om>
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 the=
y
> 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 tri=
ck
> above would help you here. I can fully verify that the state chain
> signatures were all produced non-maliciously but then there may be anothe=
r
> hidden forged signature that can take the on-chain funds that were produc=
ed
> by malicious signing sessions I was never aware of (or how can you be sur=
e
> 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) the=
y
>> 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 ow=
ner
>> 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 als=
o
>> 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 sec=
ond
>> 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 authenticati=
on.
>>
>> Thanks,
>>
>> Tom
>>
>> On Tue, Aug 8, 2023 at 6:44=E2=80=AFPM moonsettler <moonsettler@protonma=
il.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 curr=
ent
>>> 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 t=
he
>>> 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
>>> that the blinded challenge (c) value it has been sent by the user has b=
een
>>> computed honestly (i.e. c =3D SHA256(X1 + X2, R1 + R2, m) ), however th=
is 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 o=
n
>>> a backup tx, the server will require that the owner send a commitment t=
o
>>> their R2 value: e.g. SHA256(R2). The server will store this value befor=
e
>>> responding with it's R1 value. This way, the owner cannot choose the va=
lue
>>> 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 th=
e
>>> 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 wa=
s
>>> 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@commercebloc=
k.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick <jonasdnick@gmail.c=
om>
>>>> 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
>>
>

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

<div dir=3D"ltr"><div>HI=C2=A0Lloyd,</div><div><br></div><div>Yes, the blin=
d signatures are for bitcoin transactions (these are timelocked=C2=A0&#39;b=
ackup txs&#39; if the server disappears). This is not standard &#39;Schnorr=
 blind signature&#39; (like=C2=A0<a href=3D"https://suredbits.com/schnorr-a=
pplications-blind-signatures/">https://suredbits.com/schnorr-applications-b=
lind-signatures/</a>) but a 2-of-2 MuSig where two keys are required to gen=
erate the full signature, but one of them (the server) does not learn of ei=
ther the full key, message (tx) or final signature.=C2=A0</div><div><br></d=
iv><div>The server is explicitly trusted to report the total number of part=
ial signatures it has generated for a specific key. If you can verify that =
ALL the signatures generated for a specific key were generated correctly, a=
nd 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 sta=
techain 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 s=
ignature count before accepting it.=C2=A0</div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 10, 2023 at 4:30=E2=80=
=AFAM Lloyd Fournier &lt;<a href=3D"mailto:lloyd.fourn@gmail.com">lloyd.fou=
rn@gmail.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 Tom,</div><div><br></div><div>These qu=
estions might be wrongheaded since I&#39;m not familiar enough with the sta=
techain protocol. Here goes:</div><div><br></div><div>Why do you need to us=
e schnorr blind signatures for this? Are the blind signatures being used to=
 produce on-chain tx signatures or are they just for credentials for transf=
erring ownership (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 y=
ou here. I can fully verify that the state chain signatures were all produc=
ed non-maliciously but then there may be another hidden forged signature th=
at can take the on-chain funds that were produced by malicious signing sess=
ions I was never aware of (or how can you be sure this isn&#39;t the case).=
<br></div><div><br></div><div>Following on from that point, is it not possi=
ble to enforce sequential blind signing in the statechain protocol under ea=
ch key. With that you don&#39;t have the problem of wagner&#39;s attack.</d=
iv><div><br></div><div>LL<br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, 9 Aug 2023 at 23:34, Tom Treveth=
an via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</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><a class=3D"gmail_plusreply" id=3D"m_-7240174161672840276m_-70716641=
33923700227plusReplyChip-0">@</a><span style=3D"font-family:Arial,sans-seri=
f;font-size:14px">moonsettler</span><br></div><div><br></div><div>When anyo=
ne receives=C2=A0a coin (either 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 missing, then the verification will fail. So =
anyone &#39;breaking the chain&#39; by signing something incorrectly=C2=A0s=
imply cannot=C2=A0then send that coin on.=C2=A0</div><div><br></div><div>Th=
e second point is important. All the &#39;transfer data&#39; (i.e. new and =
all 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 enabl=
e it to compute the full coin pubkey and identify it on-chain. Currently, t=
he server identifies individual coins (shared keys) with a statechain_id id=
entifier (unrelated to the coin outpoint), which is used by the coin receiv=
er to retrieve the transfer data via the API. But this means the receiver m=
ust be sent this identifier out-of-band by the sender, and also that if any=
one else learns it they can corrupt the server key share/signature chain vi=
a the API. One solution to this is to have a second non-identifying key use=
d only for authenticating with the server. This would mean a &#39;statchain=
 address&#39; would then be composed of 2 separate pubkeys 1) for the share=
d taproot address and 2) for server authentication.=C2=A0</div><div><br></d=
iv><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@prot=
onmail.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;b=
order-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; wit=
h an unverifiable new state by a previous owner? Can the current owner prov=
e 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-f=
amily: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,s=
ans-serif;font-size:14px">moonsettler<br></div><div style=3D"font-family:Ar=
ial,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>
</blockquote></div></div>

--00000000000020e24c06029056e5--