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
<bitcoin-dev@lists.linuxfoundation.org> 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