MIME-Version: 1.0
References: <u1IeyK5A7zyklXzl26UpCliJrFEsDp5SXUGbtXGBCrEWw6Wi7vNcoy4HNv2WXUTG_SBuMURDLhvh3YCwL2r53rL0Yj19TZpumYFD5WqmYL8=@protonmail.com>
 <CAH5Bsr2rsiU9gV6VsGH3ZCWGRoTz=g5hXNq37P3P6HB+MmxUAA@mail.gmail.com>
 <tvK5ZI4GmQzBkGfcYFOaUI4kgLBv7N615LV-yvyUOeYU49Ig2krXbyPOrTSwiiYNZpPYNv6GtLrSRTQf_MRwqmYeXY1VTLzinq93wNW9ex8=@protonmail.com>
 <CAH5Bsr07ZxxneRngGO=C56qODxu7FQ3r1c7NmcXYY3BZ2VEokA@mail.gmail.com>
 <5JbfLKwbVsIev2M33s366qbyuAGqz-ydB4gZ2KTFR_nCWbgZ0vWMm5UOU19jNVeMfYD3A0GPTpbuuYINwOv_F6fJS3NdxuPgMm8hGUnjbB0=@protonmail.com>
In-Reply-To: <5JbfLKwbVsIev2M33s366qbyuAGqz-ydB4gZ2KTFR_nCWbgZ0vWMm5UOU19jNVeMfYD3A0GPTpbuuYINwOv_F6fJS3NdxuPgMm8hGUnjbB0=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Sun, 8 Dec 2019 17:10:00 +1100
Message-ID: <CAH5Bsr1rdbTw16+FVo0NC0zqv3EDHmEd=ef7k3baLaQ+HMn2Cg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Composable MuSig
Precedence: list

Hi ZmnSCPxj,

I think you're idea of allowing multiple Rs is a fine solution as it
would essentially mean that you were just doing a three party MuSig
with more specific communication structure. As you mentioned, this is
not quite ideal though.

> It seems to me that what is needed for a composable MuSig is to have a commitment scheme which is composable.

Maybe. Showing certain attacks don't work is a first step. It would
take some deeper analysis of the security model to figure out what
exactly the MuSig requires of the commitment scheme.

> To create a commitment `c[A]` on the point A, such that `A = a * G`, the committer:
>
> * Generates random scalars `r` and `m`.
> * Computes `R` as `r * G`.
> * Computes `s` as `r + h(R | m) * a`.
> * Gives `c[A]` as the tuple `(R, s)`.

This doesn't look binding. It's easy to find another ((A,a),m) which
would validate against (R,s). Just choose m and choose a = (s - r)
h(R||m)^-1.

Cheers,

LL