[bitcoin-dev] Schnorr signatures BIP

[Erik Aronesty]

>  That approach has its uses but I think that in any case where
delinearization can be used it's a better option.

I agree, communication efficiency is a concern for some applications, and I
can think of cases where delinearization is the better option as well.

For users that want an "M of N" scheme that

a) doesn't cost more to send funds
b) allows them to lose a device and keep their coins
c) allows them to establish and validate the scheme safely

...  a simple, "verified signer" threshold scheme is probably the best
solution.




On Tue, Sep 11, 2018 at 1:51 PM Gregory Maxwell <greg at xiph.org> wrote:

> On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty <erik at q32.com> wrote:
> >
> > - Musig, by being M of M, is inherently prone to loss.
>
> M of M is a particular threshold.   If you want M of M (there are
> plenty of cases where M of M _must_ be used) then you get the
> consequences of M of M, which presumably you want.
>
> This has nothing to do with musig.  If you want a threshold other than
> M of M then you use a threshold other than M of M.
>
> No one is under the impression that M of M is somehow a replacement
> for other thresholds.  We've spent more time talking about M of M in
> some writeups in the past because it's exactly the case you need for
> signature aggregation in Bitcoin and because it's a simpler case to
> explain.
>
> > - Having the senders of the G*x pubkey shares sign their messages with
> the associated private key share should be sufficient to prevent them from
> using wagner's algorithm to attack the combined key.
>
> Yes, that is one possibility which is described in the musig paper,
> but it requires users communicate an extra signature per key.  So, for
> example, if used with aggregate signature it would completely
> eliminate the communications efficiency gains from aggregation, making
> aggregation worse than pointless.  It also has somewhat worse failure
> properties than delinearization, because a signer that fails to
> validate other's share signatures behaves behaves exactly the same as
> a correct one, on honest inputs.  That approach has its uses but I
> think that in any case where delinearization can be used it's a better
> option.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/28f34718/attachment.html>