Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CD5AFB6 for ; Tue, 11 Sep 2018 16:34:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7ADD5716 for ; Tue, 11 Sep 2018 16:34:27 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id t25-v6so1672836wmi.3 for ; Tue, 11 Sep 2018 09:34:27 -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; bh=wm/1Ch6r+zTvO8Geqs0SsAy6qZGNk2RGbhVajCIp7Ds=; b=ce9Cs//G5D9FnXwoKyOABg8GdO+zPNgK17bvzmBTLEmnJZk6GmYoknKghbxKn5yjX9 mQZrF+62n30G4lAYvXxR98vNuh2xr4PG5w3wlHbiYVsMKwBwcntu9udbNSow9KUy9JeN phoiG46vMgnlscqr/mUaEg9bxm44nUt2NRZSLuBQqWYXuIL/zJLyWsxOeMQrScro9+E5 RlhHAgDWgj5VCE6QywluH9OTlith9NsI6YA/O61AcDII9FoKsPMNwswlFMoLONavuiyz Vb83omMNiJ2UysvGih8ysyvmKgrPSGSlsSpz+ySmsbHEu83KXrq7AVtQjd8XG/NzQ6kZ eEVw== 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; bh=wm/1Ch6r+zTvO8Geqs0SsAy6qZGNk2RGbhVajCIp7Ds=; b=grj0zO5slmGcYpqSP+YtdWR4uMNTGVFPALb8t4KFPS8691GV9hHn+p6snDxo8ee+AZ aPrF3VpYo15QS93em3xO9GU0bYhwq0f0fUXMeczqS28iIbu5PpVvE6/OkkXvMi8DUS2C SelbZa2WMoOPJ4nLHYPYplVQ4gv5qlcEJJjx9bknCAUnqlu2rqdUnEjlBAMl9wkY6KcL tNE68QRxUGWG8sZ5MVm80TqLObrn4PFgW62xlg76DA0YYZzU32WuRJ+BUGyYc0vmSw5k wVdvZQq3Ga6QmyqizLz17kaqpjwnk3/RZwO40dWdZ025dptkPeBtkfGvXy26a/Sm8djt 1AVQ== X-Gm-Message-State: APzg51Bhlt2NAd5GKbeTG7y25AYK9hMTZVLkmLDwQXLPQAuXUCLBiI7B F0tK49AiczTqrTYIihB8xCwuz3sZMkSx22eZ/xE9Vio= X-Google-Smtp-Source: ANB0VdblLTCjNhbAfmw1eLbgmNiEWejVl99QUr7QlxswVuv1qLXSzQPtY/ffR/2JuyFREFwvUxs0Nc6oM9PQ7ZwGzTg= X-Received: by 2002:a1c:1609:: with SMTP id 9-v6mr1979799wmw.12.1536683665674; Tue, 11 Sep 2018 09:34:25 -0700 (PDT) MIME-Version: 1.0 References: <2e620d305c86f65cbff44b5fba548dc85c118f84.camel@timruffing.de> <20180812163734.GV499@boulet.lan> <20180903000518.GB18522@boulet.lan> In-Reply-To: From: Erik Aronesty Date: Tue, 11 Sep 2018 12:34:11 -0400 Message-ID: To: Gregory Maxwell , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000000656ce05759b0ce0" 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: Wed, 12 Sep 2018 13:40:26 +0000 Subject: Re: [bitcoin-dev] Schnorr signatures BIP 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: Tue, 11 Sep 2018 16:34:29 -0000 --0000000000000656ce05759b0ce0 Content-Type: text/plain; charset="UTF-8" To answer points: - I switched to the medium article so that I could correct, edit and improve things to make them more clear. - I responded to feedback by modifying the protocol to make it work - not by ignoring it. - I coded it up in python so I could be sure it worked, because I was concerned that it was broken - Yes, coding it up showed me that it's definitely interactive, and no different than a "standard shnorr sig" in any meaningful way regarding the security - No special protocol support is needed over Schnorr signing itself. The e, s version can be made at least as secure as schnorr + DLP. I haven't researched the R,s version. - An M-1 rogue-key attack would require the attacker would to either - attack the hash function to produce a predictable R based on a known mesage - attack the DLP to influence x or k Neither attack gives any particular advantage to someone who has M-1 keys. I haven't tested whether the R,s version is susceptible though. On Thu, Sep 6, 2018 at 9:15 AM Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev > wrote: > > Detailed explanation with code snippets: > > > > https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip] > > This appears to be a repost of the broken scheme you posted about on > Bitcointalk, but then failed to respond to the response. > > https://bitcointalk.org/index.php?topic=4973123.0 > > > The more I look into it and speak to professors about i, the more it > seems "so trivial nobody really talks about it". > > I think you might be falling into the trap of ignoring feedback you > don't like and and accepting that which sounds like "yea yea, > something like that". > > Something "like that" does work: and is expressly and explicitly > anticipated by the BIP but to be both secure and functional requires > proper delineation (E.g. musig) _and_ interaction. What you're > proposing is continually vague. My best efforts at making sense of > what you've written indicate that either it's non-interactive and > not-actually functional at all, OR it's interactive and just a less > secure subset (no proper delinearization to prevent rogue key attacks) > of what we already propose. > > When Poelstra suggests a CAS implementation he means something like > this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage This > provides for a method of communicating in both directions which is > completely precise. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000000656ce05759b0ce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To answer points:

- I switched to the medium = article so that I could correct, edit and improve things to make them more = clear.
- I responded to feedback by modifying the prot= ocol to make it work - not by ignoring it.
- I coded it up in pyt= hon so I could be sure it worked, because I was concerned that it was broke= n
- Yes, coding it up showed me that it's definitely inte= ractive, and no different than a "standard shnorr sig" in any mea= ningful way regarding the security
- No special protocol support is needed over Schnorr signing itself.=C2=A0 T= he e, s version can be made at least as secure as schnorr + DLP.=C2=A0 I ha= ven't researched the R,s version.
- An M-1 rogue-key atta= ck would require the attacker would to either

=C2=A0 - attack the hash function to produce a predictable R based on a kn= own mesage
=C2=A0 - attack the DLP to influence x or k=C2=A0

Neither attack gives any particular advantage to someo= ne who has M-1 keys.

I haven't tested whether = the R,s version is susceptible though.=C2=A0=C2=A0


On Thu, Sep 6, 2018 a= t 9:15 AM Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> w= rote:
On Wed, Sep 5, 2018 at 1:49 P= M Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Detailed explanation with code snippets:
>
> https://medium.com/@simu= lx/an-m-of-n-bitcoin-multisig-scheme-[snip]

This appears to be a repost of the broken scheme you posted about on
Bitcointalk, but then failed to respond to the response.

https://bitcointalk.org/index.php?topic=3D4973123= .0

> The more I look into it and speak to professors about i, the more it s= eems "so trivial nobody really talks about it".

I think you might be falling into the trap of ignoring feedback you
don't like and and accepting that which sounds like "yea yea,
something like that".

Something "like that" does work: and is expressly and explicitly<= br> anticipated by the BIP but to be both secure and functional requires
proper delineation (E.g. musig) _and_ interaction. What you're
proposing is continually vague.=C2=A0 My best efforts at making sense of what you've written indicate that either it's non-interactive and not-actually functional at all,=C2=A0 OR it's interactive and just a le= ss
secure subset (no proper delinearization to prevent rogue key attacks)
of what we already propose.

When Poelstra suggests a CAS implementation he means something like
this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sa= ge=C2=A0 This
provides for a method of communicating in both directions which is
completely precise.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000000656ce05759b0ce0--