Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BA260C0032 for ; 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 ; 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 ; 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 ; 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 ; 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: <7eae57c9-be42-ae07-9296-ae9e8e03c1b8@gmail.com> <_0pQDclrnsXGHY3tg0IBQSCFoRdiIqHOY1-_KRyqpB99wlrZ30pOdhU753DusijZ0v8uBin1EQOFPfYhRDYekyFK_BoZILHflvLRDvfa86I=@protonmail.com> In-Reply-To: From: Lloyd Fournier Date: Mon, 14 Aug 2023 14:31:42 +0800 Message-ID: To: Tom Trevethan Content-Type: multipart/alternative; boundary="000000000000cc04bc0602dc3887" X-Mailman-Approved-At: Mon, 14 Aug 2023 07:01:22 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 >>> 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 >>>> wrote: >>>> >>>>> >>>>> On Thu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick >>>>> 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
Hi Tom,

Thanks for the expla= nation. There's one remaining thing that isn'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't apply.

LL

On Thu, 10 Aug 2023 at = 20:00, Tom Trevethan <tom@comme= rceblock.com> wrote:
HI=C2=A0Lloyd,

Y= es, the blind signatures are for bitcoin transactions (these are timelocked= =C2=A0'backup txs' if the server disappears). This is not standard = 'Schnorr blind signature' (like=C2=A0https://suredb= its.com/schnorr-applications-blind-signatures/) 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

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
On T= hu, Aug 10, 2023 at 4:30=E2=80=AFAM Lloyd Fournier <lloyd.fourn@gmail.com> wrote:=
Hi Tom,

These questions might be wrongheade= d 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 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't be able to en= force 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 fu= nds 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 b= lind signing in the statechain protocol under each key. With that you don&#= 39;t have the problem of wagner's attack.

LL

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

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 = 'breaking the chain' by signing something incorrectly=C2=A0simply c= annot=C2=A0then send that coin on.=C2=A0

The secon= d point is important. All the 'transfer data' (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 'statchain addres= s' would then be composed of 2 separate pubkeys 1) for the shared tapro= ot address and 2) for server authentication.=C2=A0

Thanks,

Tom=C2=A0

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 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,
moonsettler

------- Original Message -------
On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:

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.
https://gi= thub.com/commerceblock/mercury/blob/master/layer/protocol.md
=
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.

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's R1 value. This = way, the owner cannot choose the value 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 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.

On Thu, Jul 27, 2023= at 2:25=E2=80=AFPM Tom Trevethan <tom@commercebloc= k.com> wrote:

=
On T= hu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick <jona= sdnick@gmail.com> wrote:
No, proof of knowledge of the r values used to generate ea= ch R does not prevent
Wagner's attack. I wrote

> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that<= br> > c[0] + ... + c[K-1] =3D c[K].

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'= ;t make
sense if he didn't.

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000cc04bc0602dc3887--