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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
