Published on: 2022-11-03T14:43:22+00:00
The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python.
Updated on: 2023-08-02T06:03:24.136194+00:00