{"type":"rich","version":"1.0","title":"Tom Trevethan [ARCHIVE] wrote","author_name":"Tom Trevethan [ARCHIVE] (npub1ax…wyw7n)","author_url":"https://yabu.me/npub1axshsyxsl3vasj4z9549rvwdvhjmh52fw0ayj3ghtmdezx8cnuxqlwyw7n","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-24\n🗒️ Summary of this message: A version of 2-of-2 Schnorr Musig2 is being implemented for statechains, where the server is fully blinded and does not learn certain information. The security relies on the server reporting the number of partial signatures generated and verifying the signatures client-side. The protocol operates by generating private and public keys, aggregating the public keys, generating nonces, computing challenges, and creating the final signature. In the case of blinding for party 1, key aggregation and nonce aggregation are performed by party 2, and party 1 does not learn the final signature or the message being signed.\n📝 Original message:\nWe are implementing a version of 2-of-2 Schnorr Musig2 for statechains\nwhere the server (party 1 in the 2-of-2) will be fully 'blinded' - in that\nit can hold a private key that is required to generate an aggregate\nsignature on an aggregate public key, but that it does not learn either: 1)\nThe aggregate public key 2) The aggregate signature and 3) The message (m)\nbeing signed.\n\nIn the model of blinded statechains, the security rests on the statechain\nserver being trusted to report the NUMBER of partial signatures it has\ngenerated for a particular key (as opposed to being trusted to enforce\nrules on WHAT it has signed in the unblinded case) and the full set of\nsignatures generated being verified client side\nhttps://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations\n\nGiven the 2-of-2 musig2 protocol operates as follows (in the following\ndescription, private keys (field elements) are denoted using lower case\nletters, and elliptic curve points as uppercase letters. G is the generator\npoint and point multiplication denoted as X = xG and point addition as A =\nG + G):\n\nParty 1 generates private key x1 and public key X1 = x1G. Party 2 generates\nprivate key x2 and public key X2 = x2G. The set of pubkeys is L = {X1,X2}.\nThe key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The shared\n(aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1) and a2 =\nKeyAggCoef(L,X2).\n\nTo sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2\ngenerates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.\n\nParty 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1\nParty 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2\n\nThe final signature is then (R,s1+s2).\n\nIn the case of blinding this for party 1:\n\nTo prevent party 1 from learning of either the full public key or final\nsignature seems straightforward, if party 1 doesn't not need to\nindependently compute and verify c = H(X||R||m) (as they are blinded from\nthe message in any case).\n\n1) Key aggregation is performed only by party 2. Party 1 just sends X1 to\nparty 2.\n2) Nonce aggregation is performed only by party 2. Party 1 just sends R1 to\nparty 2.\n3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to\ncompute s1 = c.a1.x1 + r1\n\nParty 1 never learns the final value of (R,s1+s2) or m.\n\nAny comments on this or potential issues would be appreciated.\n\nTom\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/9454c8c8/attachment.html\u003e"}