From: Tom Trevethan <tom@commerceblock.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Date: Mon, 24 Jul 2023 16:57:41 +0100 [thread overview]
Message-ID: <CAJvkSsdStaiFOTCXRvPegGoQ9_VqsR7JmsKoSwx2_DnrCxvBrg@mail.gmail.com> (raw)
In-Reply-To: <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]
Hi ZmnSCPxj,
Yes, you are correct - the full scheme (
https://eprint.iacr.org/2020/1261.pdf) should have two or more nonces (and
also compute b). I don't think this changes the approach to blinding
however.
On Mon, Jul 24, 2023 at 11:50 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Tom,
>
> Would this allow party 2 to itself be composed of N >= 2 parties?
>
> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
> `R` points, not just one each, which are finally aggregated by first
> combining them using the MuSig() public key compose function.
> This prevents party 2 from creating an `R` that may allow it to perform
> certain attacks whose name escapes me right now but which I used to know.
> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
> requires at least 2 `R` nonces per signatory)
>
> Your scheme has only one `R` per party, would it not be vulnerably to that
> attack?
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
> it can hold a private key that is required to generate an aggregate
> signature on an aggregate public key, but that it does not learn either: 1)
> The aggregate public key 2) The aggregate signature and 3) The message (m)
> being signed.
> >
> > In the model of blinded statechains, the security rests on the
> statechain server being trusted to report the NUMBER of partial signatures
> it has generated for a particular key (as opposed to being trusted to
> enforce rules on WHAT it has signed in the unblinded case) and the full set
> of signatures generated being verified client side
> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
> >
> > Given the 2-of-2 musig2 protocol operates as follows (in the following
> description, private keys (field elements) are denoted using lower case
> letters, and elliptic curve points as uppercase letters. G is the generator
> point and point multiplication denoted as X = xG and point addition as A =
> G + G):
> >
> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
> and a2 = KeyAggCoef(L,X2).
> >
> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
> >
> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
> >
> > The final signature is then (R,s1+s2).
> >
> > In the case of blinding this for party 1:
> >
> > To prevent party 1 from learning of either the full public key or final
> signature seems straightforward, if party 1 doesn't not need to
> independently compute and verify c = H(X||R||m) (as they are blinded from
> the message in any case).
> >
> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
> to party 2.
> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1
> to party 2.
> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
> compute s1 = c.a1.x1 + r1
> >
> > Party 1 never learns the final value of (R,s1+s2) or m.
> >
> > Any comments on this or potential issues would be appreciated.
> >
> > Tom
>
[-- Attachment #2: Type: text/html, Size: 4543 bytes --]
next prev parent reply other threads:[~2023-07-24 15:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 7:46 [bitcoin-dev] Blinded 2-party Musig2 Tom Trevethan
2023-07-24 10:50 ` ZmnSCPxj
2023-07-24 14:25 ` Erik Aronesty
2023-07-24 16:08 ` Tom Trevethan
2023-07-24 15:57 ` Tom Trevethan [this message]
2023-07-24 14:12 ` Jonas Nick
2023-07-24 14:40 ` Erik Aronesty
2023-07-24 15:40 ` Jonas Nick
2023-07-24 16:51 ` AdamISZ
2023-07-25 14:12 ` Erik Aronesty
2023-07-25 16:05 ` Tom Trevethan
2023-07-26 4:09 ` Erik Aronesty
2023-07-26 17:40 ` Andrew Poelstra
2023-07-26 19:59 ` Jonas Nick
2023-07-26 20:35 ` Tom Trevethan
2023-07-26 22:06 ` Erik Aronesty
2023-07-27 2:54 ` Lloyd Fournier
2023-07-27 8:07 ` Jonas Nick
[not found] ` <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
2023-07-27 13:25 ` [bitcoin-dev] Fwd: " Tom Trevethan
2023-08-07 0:55 ` [bitcoin-dev] " Tom Trevethan
2023-08-08 17:44 ` moonsettler
2023-08-09 15:14 ` Tom Trevethan
2023-08-10 3:30 ` Lloyd Fournier
2023-08-10 11:59 ` Tom Trevethan
2023-08-14 6:31 ` Lloyd Fournier
2023-08-30 10:52 ` Tom Trevethan
2023-07-24 15:39 ` Jonas Nick
2023-07-24 16:22 ` Tom Trevethan
2023-07-26 9:44 ` moonsettler
2023-07-26 14:59 ` Jonas Nick
2023-07-26 19:19 ` AdamISZ
2023-07-26 19:28 ` moonsettler
2023-07-27 5:51 ` AdamISZ
[not found] <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-26 16:32 ` Tom Trevethan
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=CAJvkSsdStaiFOTCXRvPegGoQ9_VqsR7JmsKoSwx2_DnrCxvBrg@mail.gmail.com \
--to=tom@commerceblock.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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