š
Original date posted:2023-07-24
šļø Summary of this message: The text discusses the implementation of a version of 2-of-2 Schnorr Musig2 for statechains, where the server is fully blinded. The security relies on the server reporting the number of partial signatures generated and verifying the full set of signatures client-side. The protocol involves generating private and public keys, aggregating the public keys, and signing a message using nonces.
š Original message:
as long as all parties provide a proof of secret key along with their
public key, that should not be possible
or you can do it as a two-step process where all parties provide a
commitment to the public key and nobody reveals a public key until that
commitment is received
or if you want to be paranoid you can do both
On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/d9ef0309/attachment.html>;
Erik Aronesty [ARCHIVE] /
npub1y2ā¦5taj0
2023-07-24 15:55:40
in reply to nevent1qā¦s3r3
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-07-24 15:55:40Event JSON
{
"id": "b186f63cf3d07272c8e0d0aa5753b97d679b5df70f121f3dd075b83a068ea2fb",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1690214140,
"kind": 1,
"tags": [
[
"e",
"86a87258a295f0e8a6ce06957ce368a6146cf45a73137d0af6fcc0729ce599a0",
"",
"root"
],
[
"e",
"43d55005c93ae8c626455f2ff6730a4d9fe684e1de8ffe3936ca770e634fb87f",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2023-07-24\nšļø Summary of this message: The text discusses the implementation of a version of 2-of-2 Schnorr Musig2 for statechains, where the server is fully blinded. The security relies on the server reporting the number of partial signatures generated and verifying the full set of signatures client-side. The protocol involves generating private and public keys, aggregating the public keys, and signing a message using nonces.\nš Original message:\nas long as all parties provide a proof of secret key along with their\npublic key, that should not be possible\n\nor you can do it as a two-step process where all parties provide a\ncommitment to the public key and nobody reveals a public key until that\ncommitment is received\n\nor if you want to be paranoid you can do both\n\nOn Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Tom,\n\u003e\n\u003e Would this allow party 2 to itself be composed of N \u003e= 2 parties?\n\u003e\n\u003e MuSig2 (as opposed to MuSig1) requires that signatories provide multiple\n\u003e `R` points, not just one each, which are finally aggregated by first\n\u003e combining them using the MuSig() public key compose function.\n\u003e This prevents party 2 from creating an `R` that may allow it to perform\n\u003e certain attacks whose name escapes me right now but which I used to know.\n\u003e (it is the reason why MuSig1 requires 3 round trips, and why MuSig2\n\u003e requires at least 2 `R` nonces per signatory)\n\u003e\n\u003e Your scheme has only one `R` per party, would it not be vulnerably to that\n\u003e attack?\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e Sent with Proton Mail secure email.\n\u003e\n\u003e ------- Original Message -------\n\u003e On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\n\u003e \u003e We are implementing a version of 2-of-2 Schnorr Musig2 for statechains\n\u003e where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that\n\u003e it can hold a private key that is required to generate an aggregate\n\u003e signature on an aggregate public key, but that it does not learn either: 1)\n\u003e The aggregate public key 2) The aggregate signature and 3) The message (m)\n\u003e being signed.\n\u003e \u003e\n\u003e \u003e In the model of blinded statechains, the security rests on the\n\u003e statechain server being trusted to report the NUMBER of partial signatures\n\u003e it has generated for a particular key (as opposed to being trusted to\n\u003e enforce rules on WHAT it has signed in the unblinded case) and the full set\n\u003e of signatures generated being verified client side\n\u003e https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations\n\u003e \u003e\n\u003e \u003e Given the 2-of-2 musig2 protocol operates as follows (in the following\n\u003e description, private keys (field elements) are denoted using lower case\n\u003e letters, and elliptic curve points as uppercase letters. G is the generator\n\u003e point and point multiplication denoted as X = xG and point addition as A =\n\u003e G + G):\n\u003e \u003e\n\u003e \u003e Party 1 generates private key x1 and public key X1 = x1G. Party 2\n\u003e generates private key x2 and public key X2 = x2G. The set of pubkeys is L =\n\u003e {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The\n\u003e shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)\n\u003e and a2 = KeyAggCoef(L,X2).\n\u003e \u003e\n\u003e \u003e To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2\n\u003e generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.\n\u003e \u003e\n\u003e \u003e Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1\n\u003e \u003e Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2\n\u003e \u003e\n\u003e \u003e The final signature is then (R,s1+s2).\n\u003e \u003e\n\u003e \u003e In the case of blinding this for party 1:\n\u003e \u003e\n\u003e \u003e To prevent party 1 from learning of either the full public key or final\n\u003e signature seems straightforward, if party 1 doesn't not need to\n\u003e independently compute and verify c = H(X||R||m) (as they are blinded from\n\u003e the message in any case).\n\u003e \u003e\n\u003e \u003e 1) Key aggregation is performed only by party 2. Party 1 just sends X1\n\u003e to party 2.\n\u003e \u003e 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1\n\u003e to party 2.\n\u003e \u003e 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to\n\u003e compute s1 = c.a1.x1 + r1\n\u003e \u003e\n\u003e \u003e Party 1 never learns the final value of (R,s1+s2) or m.\n\u003e \u003e\n\u003e \u003e Any comments on this or potential issues would be appreciated.\n\u003e \u003e\n\u003e \u003e Tom\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/d9ef0309/attachment.html\u003e",
"sig": "ac9108c05d383889e1707b0f8a24bdae79954611ffe7265cd8f500027c88e0de59d09e386caa478b7980ea5a38af0b31141181274ca8f87a2970d85c61c813c7"
}