Improved multisig handling

[zmanian]

At the moment, multisig is a bit of a usability nightmare.
The user flow is

1. Generate an unsigned tx.
2. Share an unsigned tx with the signer set
3. Each signer signs.
4. Share the individual signatures
5. Combine the signatures
6. Broadcast signed tx.

Transport for the unsigned tx and individual sigs are external and require users to bring their own transport.

Here is a proposed alternative.

Incorporate golang magic wormhole into gaia.

1. Start up the process with a proposed tx and a set of signers.
2. Print a set of outgoing wormholes one for each signer.
3. On each signer, start a process that accepts an incoming wormhole and signs it.
4. Print an outgoing wormhole on each signer.
5. Enter the incoming wormholes on each signer in the original process.
6. Combine the incoming signatures and broadcast.

For Admin Use

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

[alexanderbez]

Neat! Is the e2e encryption just an add-on bonus? We don't technically need the transfer to be encrypted, but it's nice.

Also, step (6), who does the actual broadcasting? It needs to be a single entity. Is that agreed upon during step (1)?

[alexanderbez]

Being that this logic (command) is actually in the SDK, I'll move the issue there.

[noandrea]

Hello, we have been looking into this issue before and we consider the same technology as @zmanian proposed. After some thinking we came out with a solution
(here the original WIP specs) that I am going to paste here in the current version:

The proposal is to use a modified magic-wormhole implementation as an input to the SPAKE2 protocol and as a network transport layer to provide a more convenient transport layer for exchanging unsigned transactions and their signatures.

Execution

The multisigning session initiator shares a weak session key to all signing peers. The weak session key looks like this: revolver (OpenIssue #1).

A Cosmos address and a generated channel id will be transparently added to this session key before deriving the stronger session key for communication with the signing peer via SPAKE2.

This allows the multisigning session initiator to keep track of only 1 weak session key, but still have different weak session keys per signing user.

It also helps distinguish between multisigning sessions in the unlikely event that two signing parties initiate multisigning sessions independently.
One caveat is that all signing parties must be online and use the same SPAKE2 method of signing the multisignature transaction.

Interaction

Given the accounts C1^k^p, C2^k^p, C3^k^p and the multisig account CM^k^p, and assuming that CM^k^p initiates the process for multisig we have the following interaction:

CM^k^p requests the multisignature generation using the command line client:

$ gaiacli tx multisign tx.json CMk C1p C2p C3p 

multisig session id: bookseller
channel 312  open with C1p
channel 1241 open with C2p
channel 634  open with C3p
...

the commmand will create 3 channels (as much as public keys are required for the multisig), and will print the session ID for this interaction.

the actual communication string will be composed of:

CHANNEL_ID-SESSION_ID-CXp

where

• CHANNEL_ID is a random number generated using the signer key + the random selected word as a seed for a random number generator with range restricted to 65536 (Open Issue not enough arguments in call to eyes.NewClient #1)
• SESSION_ID random world choosen from the wormhole wordlist
• CXp public key for the account CX

The SESSION_ID must be communicated by the CM to the CX and it is the actual weak password.

The signers (CX) will on the other side have to run the command line client for signing a transaction providing the SESSION_ID:

$ gaiacli tx sign sendtx2.json --from $ALICE --multisig=$MULTI --chain-id=$CHAINID --session-id=bookseller

do you want to inspect the tx? [no]
signature executed successfully 
do you want to save the signed tx? [no]

$

at this point the intiator of the multisig process will receive confirmations from the signer and will be able to verify the signatures:

$ gaiacli tx multisign tx.json CMk C1p C2p C3p 

multisig session id: bookseller
channel 312  open with C1p
channel 1241 open with C2p
channel 634  open with C3p
...
got valid signature from C1p
got valid signature from C3p
got valid signature from C2p

Required infrastructure

The partecipant to the multisig need to connect to lighthouse/relay to communicate to each other. The lighthouse has to be hosted as a centralized service and provides websocket connectivity to the parties (Open Issue #2).

OPEN ISSUES

1. How to choose the channel id and what is the format of the pre-shared password?
   the channel id is equivalent to a tcp port, it must be unique for each key exchange but for ease-of-use it needs to be deterministic so both parties can derive it. it cant be based only on the receiver public key since will preclude the possibility to have multiple sessions running. maybe CMp + CXp ?

2. where to host the lightouse service?
   explore the possibility to use lambda functions for this service. the urls could be something like: lighthouse.multisig.cosomos.network

Resources

• PAKE protocol
• magic wormhole original, python
• magic wormhole go implementation

what do you think about it?

[alexanderbez]

@zmanian do you have thoughts on the rough protocol stated above? I'm also a bit uneasy about introducing such complexities directly into the SDK. What are your thoughts on wallet providers enabling such a protocol instead?

[zmanian]

Maybe it doesn't belong directly in the SDK but in a stand alone binary that uses the SDK as dependency.

I think a more usable multisig is an imperative.

[noandrea]

I understand that to include a somewhat complex component in the SDK is always a delicate choice and delegate the functionality seems a more safe approach. On the other end in my experience there is a trade off to be considered by delegating certain functionalities to the "clients", since, for example, they might choose different approaches that will create confusion and incompatibilities.

We can start with a standalone implementation, also to evaluate whenever the proposed solution works well and improve significantly the multisig experience, but, if it does, it would have to be included in the SDK eventually, since to add another tool it will go against the very goal to make it easier (from my point of view).

could this be a safer way to approach the issue @alexanderbez @zmanian ?

[jackzampolin]

@noandrea I would say a standalone implementation would be great. The relayer has some of this functionality and you should see some code examples in there.

https://github.com/cosmos/relayer

[alessio]

@zmanian dixit:

Maybe it doesn't belong directly in the SDK but in a stand alone binary that uses the SDK as dependency.

I think a more usable multisig is an imperative.

I fully agree. A better multisig UX is needed, whilst additional complexity should not be put on the SDK. A standalone tool seems the most sensible solution.

[randomshinichi]

@noandrea I would say a standalone implementation would be great. The relayer has some of this functionality and you should see some code examples in there.

https://github.com/cosmos/relayer

Hi, I'm working together with @noandrea on this. I couldn't find multisig functionality in the relayer. Did you mean the general structure of a off-chain CLI program that connects with a node?

[okwme]

I also hesitate a bit on the complexity of this solution as being maybe unnecessary. Having e2e encryption is a nice to have, but these messages will all be published publicly as soon as the interaction is complete, so i'm not sure it's actually needed.

The problem this solution seems to address the most is the actual transport of messages instead of the actual composition and coordination of multiple signatures within a single multisig transaction. This seems to be the part that is the currently the most difficult, manually opening a JSON file and adding a signature that was manually created previously is the painful part, isn't it?

Just a command which can properly assess a JSON object that may already contain signatures, and properly add new ones (or check that it would not be a redundant signature) would be clear improvements that don't even require networking work.

Getting all signers online at the same time is also a potential problem I see. I would imagine asynchronous emails with JSON attachments is actually preferable to getting everyone online at the same time. It also avoids the problem of running a server that needs to be used as the lighthouse in this scenario. However, if there was a way to use something like a dedicated signing server for asynchronous signature sharing I could see the benefit. Maybe if the CLI was able to reference the JSON object from a remote URL as well as locally it would already create a better user flow than email. Maybe the ability to post it to IPFS? Ensure it stays pinned?

I imagine an ideal userflow could be something like:

gaiacli tx send $(gaiacli keys show me -a) $(gaiacli keys show you -a) 1000uatoms --generate-only > multi.json
# multi.json generated with no signatures
gaiacli tx add-sig multi.json --from me
# multi.json modified to include signature from me
gaiacli tx add-sig multi.json --from me
# Error: Signature from <cosmosaddress> already included
# At this point the multi.json  file can be sent via email, published via IPFS or on a publicly available URL
gaiacli tx add-sig https://pastebin.com/raw/abcdefg123 --from him > multi.sig
# after confirming this is the correct transaction signing a remote JSON object could be saved locally
gaiacli tx broadcast multi.json

I don't do multisig transactions terribly often though, @zmanian @ebuchman what do you all think?

[alessio]

I like this idea @okwme, I'll prepare a POC ASAP

[zmanian]

I think e2e encryption is actually pretty important here. Concealing the identity of the participants in the multisig from a server which is easily compromised is pretty key to making this a safe solution.

You can't remove e2e from the requirements. The current best practice is to use Signal attachments for assembling signatures.

[alessio]

@zmanian dixit:

I think e2e encryption is actually pretty important here.

It surely is! It'd be out of scope of gaia binaries to handle it though. gaiacli should assist users to package/rebuild tx+sigs transmitted securely. gaiacli does most of it already, it's just that the UX is fairly suboptimal (for history's sake, most work was carried out in #3264)