📅 Original date posted:2022-05-22
📝 Original message:Jonas,
Many thanks for getting the BIP draft out. Particularly appreciate the reference code!
I have a question about identical pubkeys (including how it relates to MuSig2* optimization):
What is the purpose of allowing this? Isn't it always the case that N equal keys combined with M non-equal keys is logically equivalent to 1+M keys? It non trivially complicates certain aspects of the algorithm to allow it and I guess I must be missing something in my previous statement because, otherwise, isn't it pointless (and pretty unwise, considering how likely it is to come from an error)? The whole 'second key' thing in MuSig2 is a sorty of icky side effect.
A valid point about this is already made in the BIP and enunciated clearly and in detail: that MuSig2 is designed to discover lying at the partial sig verify stage, so it's not really that I'm saying that what's in the BIP is logically or mathematically wrong; it just seems unwise and needlessly complex. The case of 2 keys being identical does not imply an attacker; it is far more likely to be a busted implementation by counterparties where they're accidentally using P1, P1 instead of their intended P1, P2.
I suppose the key word is 'needlessly' - is there a need for this that I'm overlooking?
Cheers,
waxwing/AdamISZ
Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, April 5th, 2022 at 17:57, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would like
> to propose to the community for discussion. The BIP is compatible with BIP340
> public keys and signatures. It supports tweaking, which allows deriving BIP32
> child keys from aggregate keys and creating BIP341 Taproot outputs with key and
> script paths. You can find the BIP draft at:
> https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
>
> The draft is in a state where it should be possible to write an implementation
> based on the BIP that passes the basic test vectors (as, e.g., demonstrated by
> [0]). The draft BIP also contains a reference implementation in python. Please
> be aware that this is only a draft and that it may still be necessary to make
> small tweaks to the algorithms and test vectors.
>
> [0] https://github.com/btcsuite/btcd/pull/1820
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
AdamISZ [ARCHIVE] /
npub1nv…kqw2t
2023-06-07 23:09:56
in reply to nevent1q…u728
Author Public Key
npub1nv7tjpn2g8tvt8qfq5ccyl00ucfcu98ch998sq4g5xp65vy6fc4sykqw2tPublished at
2023-06-07 23:09:56Event JSON
{
"id": "18590d0f81c43af446321d83b1a9198fe1dd39fbba06fee51b172aa941cd4b59",
"pubkey": "9b3cb9066a41d6c59c090531827defe6138e14f8b94a7802a8a183aa309a4e2b",
"created_at": 1686179396,
"kind": 1,
"tags": [
[
"e",
"fbc301a8701a363e71bd586f5c5625ea83d991fcb7c25f51abb36ba7ede688cb",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-05-22\n📝 Original message:Jonas,\n\nMany thanks for getting the BIP draft out. Particularly appreciate the reference code!\n\nI have a question about identical pubkeys (including how it relates to MuSig2* optimization):\n\nWhat is the purpose of allowing this? Isn't it always the case that N equal keys combined with M non-equal keys is logically equivalent to 1+M keys? It non trivially complicates certain aspects of the algorithm to allow it and I guess I must be missing something in my previous statement because, otherwise, isn't it pointless (and pretty unwise, considering how likely it is to come from an error)? The whole 'second key' thing in MuSig2 is a sorty of icky side effect.\n\nA valid point about this is already made in the BIP and enunciated clearly and in detail: that MuSig2 is designed to discover lying at the partial sig verify stage, so it's not really that I'm saying that what's in the BIP is logically or mathematically wrong; it just seems unwise and needlessly complex. The case of 2 keys being identical does not imply an attacker; it is far more likely to be a busted implementation by counterparties where they're accidentally using P1, P1 instead of their intended P1, P2.\n\nI suppose the key word is 'needlessly' - is there a need for this that I'm overlooking?\n\nCheers,\nwaxwing/AdamISZ\n\n\nSent with ProtonMail secure email.\n------- Original Message -------\nOn Tuesday, April 5th, 2022 at 17:57, Jonas Nick via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would like\n\u003e to propose to the community for discussion. The BIP is compatible with BIP340\n\u003e public keys and signatures. It supports tweaking, which allows deriving BIP32\n\u003e child keys from aggregate keys and creating BIP341 Taproot outputs with key and\n\u003e script paths. You can find the BIP draft at:\n\u003e https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki\n\u003e\n\u003e The draft is in a state where it should be possible to write an implementation\n\u003e based on the BIP that passes the basic test vectors (as, e.g., demonstrated by\n\u003e [0]). The draft BIP also contains a reference implementation in python. Please\n\u003e be aware that this is only a draft and that it may still be necessary to make\n\u003e small tweaks to the algorithms and test vectors.\n\u003e\n\u003e [0] https://github.com/btcsuite/btcd/pull/1820\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",
"sig": "9f6948548822de207fbfd3a0434b6ae4bc5dcb3b15c188e77d6aba53339a17b303d6558d648c6b166336f02a63c89212688d5481df7e32a02956d1b161258016"
}