[bitcoin-dev] Multiparty signatures
erik at q32.com
Tue Jul 10 11:46:17 UTC 2018
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 at 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
> 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
> 4. Computes H(r || M), as per standard schnorr
> 5. Computes s' = k' - xe , as per standard schnorr .. except k' is a
> 6. Publish (s', e, g^x')
> 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 at xiph.org> wrote:
>> On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty <erik at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev