Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2018-09-05 📝 Original message:On Wed, Sep 5, 2018 at ...
📅 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.
📝 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.