Published on: 2023-08-30T10:52:05+00:00
The email discusses the limitations and challenges associated with using Proof of Secret Key (POSK) in the MuSig protocol. It highlights the difficulty of producing POSKs in various contexts and the lack of an established key serialization format for them. The email also mentions the difficulties in publishing POSKs. The email discusses the use of MuSig1 and MuSig2 for avoiding signature forgery and blinding challenges in the signing process. It suggests integrating a "proof of secret key" (posk) into low-level protocols to prevent vulnerabilities. The email raises concerns about the proposed solution not addressing the issue of client-controlled challenge e' and proposes exploring alternative approaches such as commitments and Zero-Knowledge Proofs (ZKPs). The email further discusses the v=2 nonces signing protocol of musig2 and emphasizes the need to blind the challenge value c for confidentiality. It outlines the steps involved in the Keygen and Signing processes and suggests a verification process for statecoin transfers. Additionally, the email addresses concerns about party 1 not learning the final values of (R, s1+s2) or m and proposes an additional step for the server to obtain necessary information without compromising security. The email suggests that all parties involved in a transaction should provide a proof of secret key along with their public key to ensure security. It highlights potential vulnerabilities in a proposed scheme for blind music and the effectiveness of MuSig2 in preventing certain attacks. In conclusion, the email provides a detailed summary of the discussions around blinding challenges and signature forgery in the context of MuSig1 and MuSig2 protocols. It emphasizes the importance of integrating posk, blinding values, and implementing secure verification processes to enhance security in statecoin transfers.
Updated on: 2023-08-31T01:55:43.561462+00:00