ㅤ

[Symmetrick]

ㅤ

[NotATether]

I think that even if MuSig2 ends up getting merged into Bitcoin, for compatibility reasons it’s not going to replace MuSig1 in newer releases, it’ll just be added alongside it. Most of the whitepaper was too advanced for me to understand, but the OP mentions that MuSig2 reduces transaction fees, which means transaction data structures have to change. You can’t push an update that makes existing multisig wallets send a different transaction structure without making a hard fork, so I think that what will most likely happen is that an option to choose the type of multisig signature will be added to wallets.

This would still be a soft fork though, and unless there’s a way to “wrap” a MuSig2 transaction inside a MuSig1, it’ll take a while post-deployment before people sending MuSig2 transactions to each other becomes as common as MuSig1.

[ysangkok]

I think that even if MuSig2 ends up getting merged into Bitcoin, for compatibility reasons it’s not going to replace MuSig1 in newer releases, it’ll just be added alongside it. Most of the whitepaper was too advanced for me to understand, but the OP mentions that MuSig2 reduces transaction fees, which means transaction data structures have to change. You can’t push an update that makes existing multisig wallets send a different transaction structure without making a hard fork, so I think that what will most likely happen is that an option to choose the type of multisig signature will be added to wallets.

This would still be a soft fork though, and unless there’s a way to “wrap” a MuSig2 transaction inside a MuSig1, it’ll take a while post-deployment before people sending MuSig2 transactions to each other becomes as common as MuSig1.

Why is there even any talk of forking? All Musig variants are compatible with Schnorr, AFAIK.

[NotATether]

Why is there even any talk of forking? All Musig variants are compatible with Schnorr, AFAIK.

Right. Now that Taproot has been activated I think this topic deserves another review.

Musig-DN would be the ideal way of getting multisig signatures from all the co-signers, but some of it's security measures are unnecessary.

zero-knowledge proofs so that attacker's can't modify the state: This most likely cannot happen if you only transmit your signature already encrypted such as PGP, and I only see this as beneficial if bitcoin core one day supports establishing a multisig wallet using only network communication between nodes instead of real people sharing their ypubs, a crazy idea which won't even exit the design stage.

However their nonce-generating library Purify works internally, if at the very least seems too much to shove in a single batch of PRs and expect it to be ready by the next version. I am not even sure if Musig1 is used in the protocol yet. More importantly there will be trouble finding people skilled enough to contribute code for this as it relies on a bunch of different elliptic curves, arithmetic gates, quadratic twists, etc etc which still makes my head wrap even today. And my previous reply was written 3 months ago!

How many people are running Bitcoin Core in a container or VM where snapshots and therefore musig state can be saved and restored?

If there's one thing I learned during development, it's that simpler schemes such as Musig2 have fewer avenues for vulnerabilities and bugs (which in a cryptocurrency sometimes are just as bad as vulnerabilities) in their implementation than more complex schemes that may be more secure theoretically. I always bring up Heartbleed as an example at this point.

[gba]

Is it possible to consider Winternitz One Time Signature based Ring Signature Scheme instead of Two Round Schnorr Signature to reduce the digital footprint of Multisig 2 with the additional benefit of better privacy.

[NotATether]

Is it possible to consider Winternitz One Time Signature based Ring Signature Scheme instead of Two Round Schnorr Signature to reduce the digital footprint of Multisig 2 with the additional benefit of better privacy.

For one thing, although WOTS is quantum-resistant, there are 32 signatures that now need to be included in the transaction hash and his will enormously increase the transaction size and therefore fees. Also there is A LOT of hashing done for each signature to verify a WOTS signature (and also signing a WOTS signature) as opposed to Schnorr. Now hashing's got to be done N*32 times for all public keys, where 1 <= N <= 255 is different for each signature byte! And of course this has to be done for each transaction, so you'll be hashing SHA256 on average 32* say 128 = 4096 times per transaction which is prohibitively slow when you take into account that there are hundreds of transactions in a block.

Whereas all Schnorr has to do to verify signatures is perform two group exponentiations and a hash.