{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-09-05\n📝 Original message:On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Detailed explanation with code snippets:\n\u003e\n\u003e https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip]\n\nThis appears to be a repost of the broken scheme you posted about on\nBitcointalk, but then failed to respond to the response.\n\nhttps://bitcointalk.org/index.php?topic=4973123.0\n\n\u003e The more I look into it and speak to professors about i, the more it seems \"so trivial nobody really talks about it\".\n\nI think you might be falling into the trap of ignoring feedback you\ndon't like and and accepting that which sounds like \"yea yea,\nsomething like that\".\n\nSomething \"like that\" does work: and is expressly and explicitly\nanticipated by the BIP but to be both secure and functional requires\nproper delineation (E.g. musig) _and_ interaction. What you're\nproposing is continually vague.  My best efforts at making sense of\nwhat you've written indicate that either it's non-interactive and\nnot-actually functional at all,  OR it's interactive and just a less\nsecure subset (no proper delinearization to prevent rogue key attacks)\nof what we already propose.\n\nWhen Poelstra suggests a CAS implementation he means something like\nthis Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage  This\nprovides for a method of communicating in both directions which is\ncompletely precise."}