From: Lloyd Fournier <lloyd.fourn@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Composable MuSig
Date: Mon, 2 Dec 2019 14:30:26 +1100 [thread overview]
Message-ID: <CAH5Bsr07ZxxneRngGO=C56qODxu7FQ3r1c7NmcXYY3BZ2VEokA@mail.gmail.com> (raw)
In-Reply-To: <tvK5ZI4GmQzBkGfcYFOaUI4kgLBv7N615LV-yvyUOeYU49Ig2krXbyPOrTSwiiYNZpPYNv6GtLrSRTQf_MRwqmYeXY1VTLzinq93wNW9ex8=@protonmail.com>
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
next prev parent reply other threads:[~2019-12-02 3:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-25 11:00 ZmnSCPxj
2019-11-29 5:50 ` Lloyd Fournier
2019-12-02 2:05 ` ZmnSCPxj
2019-12-02 3:30 ` Lloyd Fournier [this message]
2019-12-08 1:15 ` ZmnSCPxj
2019-12-08 6:10 ` Lloyd Fournier
2020-02-23 7:27 ` Erik Aronesty
2020-02-24 11:16 ` Tim Ruffing
2020-02-24 15:30 ` Erik Aronesty
2020-02-24 16:56 ` Tim Ruffing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH5Bsr07ZxxneRngGO=C56qODxu7FQ3r1c7NmcXYY3BZ2VEokA@mail.gmail.com' \
--to=lloyd.fourn@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox