Adding comms to FROST demo: Phase 2 design

[mpguerra]

From #585:

In the first phase we added simple socket communication to the demo, with the coordinator acting as the server.

Design phase 2, which increments the previous phase somehow. This could involve, for example:

• Decoupling server from coordinator
• Integrating some other third-party library

@conradoplg has started a google doc with 2 alternative paths forward. This discussion will explore both alternatives.

[mpguerra]

Option A: Decoupling Server and Coordinator

In real world usage, the coordinator will not always be the server. Even in a restricted scenario like a single user using multiple devices, it’s unlikely that one device will be able to act as a server and the others will be able to connect to it. Thus, it makes sense to decouple the server from the coordinator.

Server Operations

• Create new session
  • Input: PublicKeyPackage, message, number of signers
  • Output: session ID
• Send commitment
  • Input: session ID, commitment
  • Output: acknowledgement
• Get session state?
  • Input: session ID
  • Output: session state (WaitingForCommitments, WaitingForSIgnatureShares, SignatureReady)
• Get SigningPackage
  • Input: session ID
  • Output: SigningPackage
• Send SignatureShare
  • Input: session ID, SignatureShare
  • Output: acknowledgement
• Get Signature
  • Input: session ID
  • Output: Signature

Coordinator flow

• Call “Create new session”, get session ID, send to participants (out of band)
• Call “Get session state” until SignatureReady, call GetSignature

Participant flow

• Get Session ID from Coordinator (out of band)
• Generate commitment, call “Send Commitment”
• Call “Get session state” until WaitingForSignatureShares
• Call “Get SigningPackage”, sign it, call “Send SignatureShare”

[mpguerra]

Comments from @conradoplg:

• Session IDs could be annoying to share, but this could be solved later on top of this with some user registration mechanism which would allow listing session IDs where you are involved
• Instead of “Get session state” the other “Get” operations could simply block. But it seems useful anyway.
• Later with usernames / public keys and encryption, the server will be totally unaware of what is going on (other than group metadata)

[mpguerra]

Option B: Communication over internet/non-local network

[conradoplg]

Option A kind of solves this, assuming the server will be run by us/someone (i.e. not by the user) and clients will connect to it

[mpguerra]

Option C: Making Phase 1 usable

• Create some sort of app that can run as Coordinator or Participant. (Maybe also support PC so it works with PC + Smartphone?).
• Optional: use some mechanism of device discovery to avoid entering IP addresses (e.g. mDNS, Google Nearby)
• Just like the regular demo, the app will allow signing a Zcash transaction together with Ywallet.

[conradoplg]

Closing this; we ended up going with Option A