MIME-Version: 1.0
References: <u1IeyK5A7zyklXzl26UpCliJrFEsDp5SXUGbtXGBCrEWw6Wi7vNcoy4HNv2WXUTG_SBuMURDLhvh3YCwL2r53rL0Yj19TZpumYFD5WqmYL8=@protonmail.com>
 <CAH5Bsr2rsiU9gV6VsGH3ZCWGRoTz=g5hXNq37P3P6HB+MmxUAA@mail.gmail.com>
 <tvK5ZI4GmQzBkGfcYFOaUI4kgLBv7N615LV-yvyUOeYU49Ig2krXbyPOrTSwiiYNZpPYNv6GtLrSRTQf_MRwqmYeXY1VTLzinq93wNW9ex8=@protonmail.com>
In-Reply-To: <tvK5ZI4GmQzBkGfcYFOaUI4kgLBv7N615LV-yvyUOeYU49Ig2krXbyPOrTSwiiYNZpPYNv6GtLrSRTQf_MRwqmYeXY1VTLzinq93wNW9ex8=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 2 Dec 2019 14:30:26 +1100
Message-ID: <CAH5Bsr07ZxxneRngGO=C56qODxu7FQ3r1c7NmcXYY3BZ2VEokA@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,

> > Just a quick note: I think there is a way to commit to a point properly with Pedersen commitments. Consider the following:
> > COM(X) = (y*G + z*H, y*G + X)  where y and z are random and the opening is (y,z,X).  This seems to be a  unconditionally hiding and computationally binding homomorphic commitment scheme to a point based on the DL problem rather than DDH.
>
> So the Pedersen commitment commits to a tweak on `X`, which is revealed later so we can un-tweak `X`.
> Am I correct in assuming that you propose to use `X` for the contribution to `R` for a participant?
> How is it different from using ElGamal commitments?

Yes. It's not significantly different. It is unconditionally hiding
rather than binding (ElGamal is unconditionally binding). I just
thought of it while reading your post so I mentioned it. The real
question is what properties does the commitment scheme need to be
appropriate for MuSig R coin tossing?
In the security proof, the commitment hash is modelled as a random
oracle rather than as an abstract commitment scheme. I wonder if any
MuSig author has an opinion on whether the H_com interaction can be
generalised to a commitment scheme with certain properties (e.g
equivocal, extractable). By the looks of it, the random oracle is
never explicitly programmed except with randomly generated values so
maybe there is hope that a non ROM commitment scheme can do the job. I
guess the reduction would then be to either breaking the discrete
logarithm problem OR some property of the commitment scheme.

Cheers,

LL