From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 38F21E92 for ; Fri, 20 Jul 2018 16:25:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8CED0466 for ; Fri, 20 Jul 2018 16:25:48 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id h9-v6so11870657wro.3 for ; Fri, 20 Jul 2018 09:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0+sSs017hVszbmw2y0Zp4g+iDdSAPgOobuwIMFD7SW0=; b=0qJbRPQpdVhg8mXPUhQQy0slOvTpgkMTN/85TQ//FmZhgEw1r1XZX4rsoE9wwfXiC5 HtQoKes+DSAO5KxtQtjjmxOWuOduS5fY+W33U4cGJgnTAEIkXbJw/BqMxj4afKNJnqjX 6MThcJvDKZ9yct3cyK6ghnV2fYNx8s7zSjB5WEnJf3et2GilYUWLQmZI0XEH9V9X9wFO h8FdN/CExEdqGfzgyUvLJfAaBUtIQaQmHOaaDvVMa0fIIqaCWJbtkS3ivsyqNz+2PVUa T9UBjc4xFxNihu+FChBpBeaC2pRdfyAbu51oaj2fVyZxsZShrm9MVG9CoOcNdhMdpSmX E+nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0+sSs017hVszbmw2y0Zp4g+iDdSAPgOobuwIMFD7SW0=; b=ZHpSSAkbekOdV1Giy+yRoVxbcLQ4x7lljH5yxAk3/EOXoYhmKt8jHwvksON4P3R20D aYIFYV/lUK8eieerKx5JdEoZEZddlWR9BdoOQNPsyrpbJ5CqiGk6G+yXhVEtP0Vnf8tg FtztKxHBLkzi3ZNnjcZCfBgG8CFmb7xYEMZmWZZTvTKNByINU85Oao+kbHczRaWXmegy QqMh6jKHnmZvGDplT7przejPuU1HBXp4hK96dSzeSeKqqWU1AvGM8j2801W78KVLmRI4 234+tBACg4h5ISCXfqeqFW5FYfGYT4I4PPloBxDw4Q74zkn0aug6wAWsqpYo+snYuoMd qINw== X-Gm-Message-State: AOUpUlFVmwYonQC2IE1oBttqfapCyNoykSEHICTTeVnDTMqT7XNPFaFH sBqmCe40oKK0DiU8EPNk+bUNbIcBzgSGLCn4ITe9Hyk= X-Google-Smtp-Source: AAOMgpe6ODrWVXg8RGLeE22geooSv3ZYphGK5IB76nDqggJkZ0qWNb2cGvNlkRdaKX56+vc8tGrOrvX+LaCOOzlEoUk= X-Received: by 2002:adf:9d1c:: with SMTP id k28-v6mr2062872wre.29.1532103947064; Fri, 20 Jul 2018 09:25:47 -0700 (PDT) MIME-Version: 1.0 References: <08201f2292587821e6d23f6cc201d95e6e5ad2cd.camel@timruffing.de> In-Reply-To: From: Erik Aronesty Date: Fri, 20 Jul 2018 12:25:34 -0400 Message-ID: To: "Russell O'Connor" Content-Type: multipart/alternative; boundary="0000000000008618e6057170bfaf" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 22 Jul 2018 12:50:59 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Multiparty signatures X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 16:25:49 -0000 --0000000000008618e6057170bfaf Content-Type: text/plain; charset="UTF-8" That's a great point. It's been solved in musig and that doesn't change the m of n multisig construction. You use the same musig construction where you hash all keys and sum the multiples....and use that when computing k ... the shared blinding factor.... you're still improving the system .... Getting a nice Shamir m of n multisig.... with a single signature...and all the same properties otherwise. On Thu, Jul 19, 2018, 9:11 AM Russell O'Connor wrote: > On Thu, Jul 19, 2018 at 8:16 AM, Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> you can't birthday attack something where there's only a single variable >> that you can modify. >> > > When engaging in a multiparty signature, the attacker can more than one > variable to modify. When you are party to a multi-party signature (for > example, in some sort of coin-join protocol) it could be that every other > participant in the multi-party signature is, in fact, the same single > attacker representing themselves as multiple participants. This is how the > attacker gets their hands on multiple variables. > > > --0000000000008618e6057170bfaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's a great point.=C2=A0 It's been solved in m= usig and that doesn't change the m of n multisig construction.

You use the same musig construction w= here you hash all keys and sum the multiples....and use that when computing= k ... the shared blinding factor.... you're still improving the system= .... Getting a nice Shamir m of n multisig.... with a single signature...a= nd all the same properties otherwise.


On Thu, Jul 19, 2018, 9:1= 1 AM Russell O'Connor <ro= connor@blockstream.io> wrote:
On= Thu, Jul 19, 2018 at 8:16 AM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=C2=A0you c= an't birthday attack something where there's only a single variable= that you can modify.

When engaging i= n a multiparty signature, the attacker can more than one variable to modify= .=C2=A0 When you are party to a multi-party signature (for example, in some= sort of coin-join protocol) it could be that every other participant in th= e multi-party signature is, in fact, the same single attacker representing = themselves as multiple participants.=C2=A0 This is how the attacker gets th= eir hands on multiple variables.


--0000000000008618e6057170bfaf--