rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2018-09-05 📝 Original message:On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev <bitcoin-dev at 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.