From: Gregory Maxwell <greg@xiph•org>
To: Erik Aronesty <erik@q32•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
Date: Tue, 11 Sep 2018 17:51:01 +0000 [thread overview]
Message-ID: <CAAS2fgTRmsws4y7yz=584QXvjsVawY84je=jOEoXm2RK_jieXQ@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgK9UdavrGnKum43dx+DXe+LakHXuVU6bNhMFtEoy2U3Og@mail.gmail.com>
On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty <erik@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 prev parent reply other threads:[~2018-09-11 17:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 18:08 Pieter Wuille
2018-07-06 21:05 ` Russell O'Connor
2018-07-06 22:00 ` Gregory Maxwell
2018-07-06 22:01 ` Gregory Maxwell
2018-07-08 14:36 ` Russell O'Connor
2018-07-14 15:42 ` Sjors Provoost
2018-07-14 21:20 ` Pieter Wuille
2018-08-04 12:22 ` Russell O'Connor
2018-08-05 14:33 ` Russell O'Connor
2018-08-06 8:39 ` Anthony Towns
2018-08-06 14:00 ` Russell O'Connor
2018-08-06 21:12 ` Tim Ruffing
2018-08-12 16:37 ` Andrew Poelstra
2018-08-29 12:09 ` Erik Aronesty
2018-09-03 0:05 ` Andrew Poelstra
2018-09-05 12:26 ` Erik Aronesty
2018-09-05 13:05 ` Andrew Poelstra
2018-09-05 13:14 ` Erik Aronesty
2018-09-05 15:35 ` Gregory Maxwell
2018-09-11 16:34 ` Erik Aronesty
2018-09-11 17:00 ` Gregory Maxwell
2018-09-11 17:20 ` Erik Aronesty
2018-09-11 17:27 ` Gregory Maxwell
2018-09-11 17:37 ` Erik Aronesty
2018-09-11 17:51 ` Gregory Maxwell [this message]
2018-09-11 18:30 ` Erik Aronesty
2018-09-13 18:46 ` Andrew Poelstra
2018-09-13 20:20 ` Erik Aronesty
2018-09-14 14:38 ` Andrew Poelstra
2018-09-20 21:12 ` Russell O'Connor
2018-07-07 2:47 Артём Литвинович
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgTRmsws4y7yz=584QXvjsVawY84je=jOEoXm2RK_jieXQ@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox