Composable MuSig [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2020-02-24T16:56:06+00:00


Summary:

The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure.


Updated on: 2023-08-02T01:34:08.477767+00:00