Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA942C0032 for ; Thu, 27 Jul 2023 02:54:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 983DF404C3 for ; Thu, 27 Jul 2023 02:54:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 983DF404C3 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=OjHWwNKD 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJZZYCoC-mBe for ; Thu, 27 Jul 2023 02:54:45 +0000 (UTC) Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by smtp2.osuosl.org (Postfix) with ESMTPS id 7D81B40134 for ; Thu, 27 Jul 2023 02:54:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7D81B40134 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-5768a7e3adbso24684417b3.0 for ; Wed, 26 Jul 2023 19:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690426484; x=1691031284; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qp9Qm38gclfbH0pqF/GNPxUKMk06s9SRCPKTm9SzQiQ=; b=OjHWwNKDlgCv4f4JfFg12bXwa+Rq/8bMl8OXkHM638fy5Yes5bgy4JhIKOLSlZvePm uk5PoabDF4m3nOH4JuLczXx9uO5RXpp7ORGyAJJVll2elVy64c1oVo7eLJH1qFGEdCOx hkgq+CD4CHaHo1gU5oWdC7nFCbHPloICuAHu6NPy4RB2kd9C2F2HsTEpx+FGN4M/heov 2r60h+yga5/tY+7FxQSnIPEsxHLiagLVi5WtoNq1vIMMF+IIloq73aGAsPAN4rL/XgcM 4zHGSNKKkKBJGGhTmBWSTkwpa44FgY4r0hzZzdlCQZSBqXDm7RL833CvuprZptm7JGyK 5fAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690426484; x=1691031284; 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=Qp9Qm38gclfbH0pqF/GNPxUKMk06s9SRCPKTm9SzQiQ=; b=XA1cA+BeFidK+Y7xnhhmZkmf4K6zzmVEVzc6AroLuo1d1GHpbNpyDFSByNdok7/0/p MRQNqlDiq0GmEM0r5ODm25TXX8CKLx39Zam8/ePXyhRiOVMqiaPeIw6kji1GtLjA7e6R 3ljga255FsX2rm7GgOXSNG4CY+QXWmObuIzxYlZ71E3ZJKJ9L+L1uCC3jgtcpRezz032 IOfzPq24+zaznKzXCQXPpl//BfFA5mIjTzZmBvB3SuOGRHN3g+qBKUBxbssdi5tfn/Ht 8qYheO0mCKvBhFo6Lt2iQKefUTBlCKF556N0gQdOV6RL5Gwmb9i94S5MUsmn6xT6MIIt PZjg== X-Gm-Message-State: ABy/qLaAkFoWHtOyAMRCxF8NnaoR00drQ/mpEmAyDmOamzT3emX/LfNO BAscFACU49qyLvqZJK7DXALKWEU8rdCZ3vr6hkzX0Lqs3Uc= X-Google-Smtp-Source: APBJJlGULI6vnGOpQ325JYirWNZNE4HbD5wIOK+SYwwpNmlJJfruXB14CODcnBStvj/+hCHBUECTFZ4GZ+RODQFmW/E= X-Received: by 2002:a25:c7d3:0:b0:cec:2bed:f7da with SMTP id w202-20020a25c7d3000000b00cec2bedf7damr2150668ybe.5.1690426484111; Wed, 26 Jul 2023 19:54:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lloyd Fournier Date: Thu, 27 Jul 2023 10:54:17 +0800 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001abd1c06016f163c" X-Mailman-Approved-At: Thu, 27 Jul 2023 08:29:00 +0000 Cc: Tom Trevethan 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: Thu, 27 Jul 2023 02:54:47 -0000 --0000000000001abd1c06016f163c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, 1. No proof of knowledge of each R does *NOT* prevent wagner's attack. 2. In my mind, A generic blind signing service is sufficient for doing blinded MuSig, Muig2, FROST or whatever without the blind signing service knowing. You don't need a specialized MuSig2 blind singing service to extract MuSig2 compatible shares from it. You can just add the MuSig tweak (and/or BIP32 etc) to their key when you do the blind signing request (this seemed to be what the OP was suggesting). Making the server have multiple nonces like in MuSig2 proper doesn't help the server's security at all. I think the problem is simply reduced to creating a secure blind schnorr signing service. Jonas mentioned some papers which show how to do that. The question is mostly about whether you can practically integrate those tricks into your protocol which might be tricky. LL On Thu, 27 Jul 2023 at 08:20, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > correct. you cannot select R if it is shipped with a POP > > On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan wrote= : > >> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of >> knowledge of the r values used to generate each R used prevents the Wagn= er >> attack, no? >> >> On Wed, Jul 26, 2023 at 8:59=E2=80=AFPM Jonas Nick wrote: >> >>> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned >>> an >>> attack on the nonces, I mentioned an attack on the challenge c) can be >>> prevented >>> by proving knowledge of the signing key (usually known as proof of >>> possession, >>> PoP). >>> >> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000001abd1c06016f163c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

1. No proof of kn= owledge of each R does *NOT* prevent wagner's attack.
2. In m= y mind, A generic blind signing service is sufficient for doing blinded MuS= ig, Muig2, FROST or whatever without the blind signing service knowing. You= don't need a specialized MuSig2 blind singing service to extract MuSig= 2 compatible shares from it. You can just add the MuSig tweak (and/or BIP32= etc) to their key when you do the blind signing request (this seemed to be= what the OP was suggesting). Making the server have multiple nonces like i= n MuSig2 proper doesn't help the server's security at all. I think = the problem is simply reduced to creating a secure blind schnorr signing se= rvice. Jonas mentioned some papers which show how to do that. The question = is mostly about whether you can practically integrate those tricks into you= r protocol which might be tricky.

LL

On T= hu, 27 Jul 2023 at 08:20, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
correct.=C2=A0 you cannot select R if it is shipped w= ith a POP=C2=A0

On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan <tom@commerceblock.com&g= t; wrote:
Not 'signing' but 'secret' i.e. the r values (ep= hemeral keys). Proof of knowledge of the r values used to generate each R u= sed prevents the Wagner attack, no?

On Wed, Jul 26, 2023 at 8:59=E2=80=AFPM = Jonas Nick <jonasdnick@gmail.com> wrote:
None of the attacks mentioned in this = thread so far (ZmnSCPxj mentioned an
attack on the nonces, I mentioned an attack on the challenge c) can be prev= ented
by proving knowledge of the signing key (usually known as proof of possessi= on,
PoP).
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000001abd1c06016f163c--