- Online parties who run the actual MPC threshold signing protocol, and can interact all with each other simultaneously, and
- Offline parties who provide approval, or authorization, of the transaction, but don’t actually participate in the MPC threshold signing protocol itself. The offline parties should be able to work “asynchronously” which means that each party can send its approval independently of the others (as is needed for humans that provide manual verification of the transaction). In addition, in order to enable this approval step to be practically carried out by a cold device, it should involve a single message to the approver and a single reply back.
Asynchronous Approval in Threshold Signing
[caption id="attachment_3501" align="alignnone" width="800"] Asynchronous Approval in Threshold Signing[/caption] This is the fifth blog in a series aimed at explaining the growing use of MPC and threshold signing to protect cryptocurrencies. Brief recap In the first four blog posts in this series (Shamir Secret Sharing and Quorums, Threshold Signature Schemes, Additional Properties of Threshold Signing, and MPC Compared to Other Approaches) I described how MPC and threshold signing can be used to protect against fraudulent key usage, which is the primary problem for cryptocurrency protection. Beyond the basic ability to achieve cryptographically enforceable quorum authorization, I described additional properties like “refresh” to prevent gradual theft of shares, and the ability to replace users in threshold signature schemes as is required in business uses. Finally, in the previous post, I compared this approach to other existing ones. In this post, I will discuss an important feature – asynchronous approval. Simultaneous interaction and MPC Most protocols for secure multiparty computation require all participants to interact in multiple rounds, and thus be online at the same time. This is true also of the threshold signing protocols known for ECDSA, EdDSA, Schnorr and so on, which require multiple messages to be sent between parties. In the context of cryptocurrency protection, simultaneous interaction is not a problem if all of the participants are servers, and no human involvement is needed (e.g., the participants are “bots”). Likewise, if at most one human needs to be involved, then it can interact with the servers. However, in many cases, approval from multiple humans is desired or required, and these humans must inspect the request and manually approve it. If the devices held by the humans also participate in the actual MPC (threshold signing) protocol, then this would require all of them to be online at the same time. This is a significant impediment to the ultimate goal of fast transaction time (e.g., consider people in different time zones, or someone being on a train or plane). In addition, in some cases, it is desired to have some cryptographic material in a cold device (i.e., disconnected and truly offline). This is not possible – or at least becomes extremely impractical – if multiple messages are needed to be received and sent by the cold device (since manual transfer of each message is needed). We therefore conclude that although threshold signing with arbitrary quorums is a very strong tool, it falls short in providing a practical solution in some important real use cases. Threshold signing with asynchronous approval In order to solve the aforementioned problem, we can add a step called “asynchronous approval” to the threshold signing MPC protocol. In this case, the participating parties are divided into two types: