{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-09-11\n📝 Original message:To answer points:\n\n- I switched to the medium article so that I could correct, edit and\nimprove things to make them more clear.\n- I responded to feedback by modifying the protocol to make it work - not\nby ignoring it.\n- I coded it up in python so I could be sure it worked, because I was\nconcerned that it was broken\n- Yes, coding it up showed me that it's definitely interactive, and no\ndifferent than a \"standard shnorr sig\" in any meaningful way regarding the\nsecurity\n- No special protocol support is needed over Schnorr signing itself.  The\ne, s version can be made at least as secure as schnorr + DLP.  I haven't\nresearched the R,s version.\n- An M-1 rogue-key attack would require the attacker would to either\n\n  - attack the hash function to produce a predictable R based on a known\nmesage\n  - attack the DLP to influence x or k\n\nNeither attack gives any particular advantage to someone who has M-1 keys.\n\nI haven't tested whether the R,s version is susceptible though.\n\n\nOn Thu, Sep 6, 2018 at 9:15 AM Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Detailed explanation with code snippets:\n\u003e \u003e\n\u003e \u003e https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip]\n\u003e\n\u003e This appears to be a repost of the broken scheme you posted about on\n\u003e Bitcointalk, but then failed to respond to the response.\n\u003e\n\u003e https://bitcointalk.org/index.php?topic=4973123.0\n\u003e\n\u003e \u003e The more I look into it and speak to professors about i, the more it\n\u003e seems \"so trivial nobody really talks about it\".\n\u003e\n\u003e I think you might be falling into the trap of ignoring feedback you\n\u003e don't like and and accepting that which sounds like \"yea yea,\n\u003e something like that\".\n\u003e\n\u003e Something \"like that\" does work: and is expressly and explicitly\n\u003e anticipated by the BIP but to be both secure and functional requires\n\u003e proper delineation (E.g. musig) _and_ interaction. What you're\n\u003e proposing is continually vague.  My best efforts at making sense of\n\u003e what you've written indicate that either it's non-interactive and\n\u003e not-actually functional at all,  OR it's interactive and just a less\n\u003e secure subset (no proper delinearization to prevent rogue key attacks)\n\u003e of what we already propose.\n\u003e\n\u003e When Poelstra suggests a CAS implementation he means something like\n\u003e this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage  This\n\u003e provides for a method of communicating in both directions which is\n\u003e completely precise.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/20ed54de/attachment-0001.html\u003e"}