public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Trevethan <tom@commerceblock•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Blinded 2-party Musig2
Date: Mon, 24 Jul 2023 08:46:11 +0100	[thread overview]
Message-ID: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

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: 2685 bytes --]

             reply	other threads:[~2023-07-24  7:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24  7:46 Tom Trevethan [this message]
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
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='CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com' \
    --to=tom@commerceblock$(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