State minimization in MuSig2 signing sessions

State minimization in MuSig2 signing sessions

Original Postby real-or-random

Posted on: March 7, 2024 07:04 UTC

The discussion revolves around the method of generating random numbers (rand_{i,j}) from a root random number (rand_root) by using the $(i,j)$ pair as input to the NonceGen function.

It's noted that while this approach does not align with the exact methodology of CounterNonceGen, it is nonetheless a valid strategy. From a theoretical standpoint, the most suitable cryptographic tool for this purpose seems to be a Random Number Generator (RNG), such as ChaCha20, rather than opting for a more resource-intensive hash function. However, utilizing a hash function is deemed acceptable since it effectively functions as an RNG, despite its higher computational costs. This practice is likened to nonce generation methods in BIP327 and BIP340, where SHA256 is employed mainly because it is already required for generating challenge hashes in signatures, even though it might be considered somewhat excessive.

The term rand_root is suggested to be replaced with more commonly used terms like seed, psbt_seed, or rand_seed to better reflect its purpose and usage. Additionally, there is a proposition to extend this nonce generation method to accommodate multiple parallel signing sessions. This could be achieved by assigning a unique session_id to each session, derived from hashing specific information that practically guarantees uniqueness for the transaction being signed. This information could include a commitment to both the transaction ID (txid) of the unsigned transaction within the PSBT and the wallet policy utilized for signing. However, concerns are raised about the potential risks associated with hashing the txid and wallet policy together, particularly in scenarios where a second PSBT for the same transaction might be received, suggesting a need for caution in this approach.