Basically you're just replacing addition with interpolation everywhere in the musig construction.

But maybe I just don't understand how Wagner's algorithm is relevant here.



On Mon, Jul 9, 2018, 1:59 PM Erik Aronesty <erik@q32.com> wrote:
 - Adaptive r choice shouldn't be possible since r is derived from the original threshold prf and it's not possible for a party to have any adaptive impact on the value of r
 - I'm guess I don't see how an attacker can use adaptive key choice in this context either.   Any modification of the key should be useless
AH!

I forgot to include some assumptions.   The important part here is that each party only has a share of the private key and publishes a share of the public key.

This hopefully should preclude any sort of adaptive key attack.

From scratch:

1. Has a public g^x'
2. Computes and broadcasts g^k' ... where k' is a random number
3. Computes r = g^k using lagrange interpolation (see  http://crypto.stanford.edu/~dabo/papers/homprf.pdf)
4. Computes H(r || M), as per standard schnorr
5. Computes s' = k' - xe , as per standard schnorr .. except k' is a "share"
6. Publish (s', e, g^x')

Verification:

With m of n share-signatures:

1. Interpolation on m of n s' shares to get s
2. Interpolation on m of n g^x' shares to get g^x
3. Standard schnorr verification

The actual public key of the "set of signers" is interpolated.   



On Mon, Jul 9, 2018 at 12:58 PM, Gregory Maxwell <greg@xiph.org> wrote:
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.