public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Lloyd Fournier <lloyd.fourn@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Composable MuSig
Date: Mon, 02 Dec 2019 02:05:01 +0000	[thread overview]
Message-ID: <tvK5ZI4GmQzBkGfcYFOaUI4kgLBv7N615LV-yvyUOeYU49Ig2krXbyPOrTSwiiYNZpPYNv6GtLrSRTQf_MRwqmYeXY1VTLzinq93wNW9ex8=@protonmail.com> (raw)
In-Reply-To: <CAH5Bsr2rsiU9gV6VsGH3ZCWGRoTz=g5hXNq37P3P6HB+MmxUAA@mail.gmail.com>

Good morning Lloyd, and list,

> 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?


-------


Some number of people have noted, including at least one MuSig author, that in the ElGamal case it would be possible to prove your knowledge of the `q` behind `q * G`, and thus prevent the cancellation attack shown.
We already have a general proof-of-knowledge-of-secret-key, the Schnorr signature signing algorithm itself.

Thus, together with `q * G` in the ElGamal commitment, we could include a Schnorr signature using `q * G`, either of the target message itself, or any constant string.

This seems highly appropriate, yo dawg, I heard you like MuSig, so I put an aggregate in your aggregate, so you could sign (singly) while you sign (multiply).

In terms of a *composable* MuSig, e.g. MuSig(MuSig(A, B), C), both A and B will select `q[a]` and `q[b]` and will generate a shared `q[ab] * G` as the MuSig of `q[a] * G` and `q[b] * G`.
Since they know the corresponding `q[a]` and `q[b]` they will also known the contributions they each will need to generate `q[ab] * H`, but note that there is no proof of this until they reveal `q[a]` and `q[b]`, which may lead to further attacks, this time on `q[ab] * H` instead.
So at least for `q` it seems not to be a good idea, though I have not put much thought into this.

Indeed, it seems to me that signatures using the contributions `R[a]` and `R[b]` as public keys seems to be another way to commit to `R` while ensuring that your own `R` cannot have cancelled the other participant `R`.
You would have to exchange the (single) signatures of `R[a]` and `R[b]` first, however, otherwise a Wagner attack may be possible if you exchange `R[a]` and `R[b]` first (i.e. the signatures replace the `R` commitment phase of 3-phase MuSig).

The complexity of either sign-while-you-sign idea, however, is much greater.
Your signing algorithm now requires delegating to another signing algorithm, which while at least fair in that you are now signing while you sign because you aggregated while you aggregated, is more complicated to implement practically.



Regards,
ZmnSCPxj


  reply	other threads:[~2019-12-02  2:05 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 [this message]
2019-12-02  3:30     ` Lloyd Fournier
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='tvK5ZI4GmQzBkGfcYFOaUI4kgLBv7N615LV-yvyUOeYU49Ig2krXbyPOrTSwiiYNZpPYNv6GtLrSRTQf_MRwqmYeXY1VTLzinq93wNW9ex8=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lloyd.fourn@gmail$(echo .)com \
    /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