Improve multiple signer UX for protobuf signing over SIGN_MODE_DIRECT

[sahith-narahari]

Problem Definition

The current implementation of multisig in stargate uses legacy_amino Sign mode, as sign_mode_direct requires all the signers to be set beforehand.

There were a couple of solutions proposed before (check #6078 (comment)), but no consensus was reached.

Proposal

I propose to revisit the options, as to improve the multisig design for the next versions

cc\ @alessio @aaronc @zmanian

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[robert-zaremba]

I'm advocating to use Schnorr MultiSig to implement in SDK. It's much more efficient in terms of interactions and preserves privacy. I created an issue to document the motivation and proposed implementation: #7315

[clevinson]

Now that ADR028 is implemented, should we revisit this conversation?

I understand that group module is where we want to move for many multisig uses cases, but htere are still valid reasons for sometimes wanting off-chain multisig. Having an discussion about how we plan to address this (and whether Schnorr sigs play a role in a solution) IMO would be valuable.

[robert-zaremba]

Can anyone recall the problem with current, legacy multisig? It doesn't support sign_mode_direct, but is it a pain?
The only pain out of my head is that we need to construct the signature in a specific order (but signing can be done in any order).

[robert-zaremba]

Note that, both Schnorr signatures and x/group works with sign_mode_direct:

• for Schnorr, on the chain we have only one signature (instead of a collection of signatures aggregated in multisig). This still requires interaction (someone will need to aggregate signatures, but doesn't have a pain of doing it in a right order).
• for x/group - all votes for a message posted to x/group are done as a messages by individual participants (so, there is no multisig on a message level). So all of this is done in sign_mode_direct.

[robert-zaremba]

So, I would propose on finalizing x/group and implementing Schnorr and deprecating the legacy multisig (let it die) rather than trying to fix the latter.

[alessio]

In my view, it's just a question of support. As long as legacy multisig support is guaranteed, I'm fine with both Schnorr sigs and x/group. In other words: we just can't just drop legacy multisig support. There are loads of funds held behind those keys.

(CC'ing also @zmanian and @alexanderbez for visibility)

[aaronc]

I am very much in favor of a migration path from legacy multisig -> group

[anilcse]

I am very much in favor of a migration path from legacy multisig -> group

+1

[clevinson]

Closing this in favor of #9406, which will resolve the issue

[poiug07vsys]

Note that, both Schnorr signatures and x/group works with sign_mode_direct:

• for Schnorr, on the chain we have only one signature (instead of a collection of signatures aggregated in multisig). This still requires interaction (someone will need to aggregate signatures, but doesn't have a pain of doing it in a right order).

Sorry, is there any way of using Schnorr signing for multisig, currently? I found another issue, but not sure if it just related to Cosmos SDKs implementation only or there is no available implementation in general.

[robert-zaremba]

@poiug07vsys currently, Schnorr based multisig is not implemented. The issue you linked is the tracking issue.