MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAJowKgJjQ8EGgbCurOSjTh8ij42_BVeD6dE0y67tzN0Zop3pyg@mail.gmail.com>
References: <CAJowKgLrSe77sqO2iB7mYboo_HW=YjO4=AFdv7L5FUi2vygMiQ@mail.gmail.com>
	<08201f2292587821e6d23f6cc201d95e6e5ad2cd.camel@timruffing.de>
	<CAAS2fgSPUc7xRq36rZ9BVLjUTdd152Fgho4sjJXLhfrc71vPMw@mail.gmail.com>
	<CAJowKgL-nRcruXhWdGWrT4x+oV7i3jYST2Wa3bF5m6iT_mOyMw@mail.gmail.com>
	<CAPg+sBjdu4mnda-P0y7Ddu-rN7a1GiUt0hY_wYGsy_bJLKOYMA@mail.gmail.com>
	<CAJowKgLSQZ1LrZayDi7EFc-NSfK_AD+zBdyaF7jBeQRP7tOwYQ@mail.gmail.com>
	<CAPg+sBizrx20XShpeZRvZd4bfq1=E+MFUDmSC9X-xK1CSbV5kQ@mail.gmail.com>
	<CAJowKg+=7nS4gNmtc8a4-2cu1uCOPqxjfchFwDVqUciKNMUYWQ@mail.gmail.com>
	<CAJowKgJ3K=wmCEtoZXJZhrnnA8XJcHYg788KP+7MCeP4Mxf-0w@mail.gmail.com>
	<CAAS2fgSmA02s6Vdk_FYv6NJ4smLBgxnuT4jRYU44G7=bbzv2MA@mail.gmail.com>
	<CAJowKgJjQ8EGgbCurOSjTh8ij42_BVeD6dE0y67tzN0Zop3pyg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Mon, 9 Jul 2018 16:58:38 +0000
Message-ID: <CAAS2fgRrkzq6Fa5T_-YDwLDkwi30LpDtMObMEBE+Fmmj0LJpBw@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Multiparty signatures
Precedence: list

On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty <erik@q32.com> wrote:
>>> with security assumptions that match the original Schnorr construction more closely,
>> More closely than what?
> More closely than musig.

Musig is instructions on using the original schnorr construction for
multiparty signing which is secure against participants adaptively
choosing their keys, which is something the naive scheme of just
interpolating keys and shares is vulnerable to. It works as
preprocessing on the keys, then you continue on with the naive
protocol. The verifier (e.g. network consensus rules) is the same.

Now that you're back to using a cryptographic hash, I think what
you're suggesting is "use naive interpolation of schnorr signatures"
-- which you can do, including with the verifier proposed in the BIP,
but doing that alone is insecure against adaptive key choice (and
potentially adaptive R choice, depending on specifics which aren't
clear enough to me in your description). In particular, although it
seems surprising picking your interpolation locations with the hash of
each key isn't sufficient to prevent cancellation attacks due to the
remarkable power of wagner's algorithm.