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 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 wrote: > >> On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty 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. >> > >