Shielded Multi Signature Transactions

If you have any doubts about the questions below, please reach out to Zcash Foundation's Ecosystem Relations Manager, decentralistdan, on the Zcash forums.

Applicant background

I am a software engineer who worked for several major projects including: Windows (OS kernel), .NET framework (compiler and code generation) and SQL Server (Engine / query execution). I was also the CTO of startups and listed companies.

I have completed the Cold Wallet and BTCPay Server integration grants for Zcash and I am the primary developer for ZWallet.

Description of Problem or Opportunity

Multisignature transactions have unique use-cases not covered by regular transactions.

• 1 of n: Multiple people sharing the same account and any person can spend. The accountant wants to keep a record of who did the spending
• 2 of 2: Every party must sign to approve spending
• 2 of 3: Escrow account where two counterparties can agree to spend but in case of a disagreement they can engage of third party.
• n of n: High security vault

Proposed Solution

The ZF has published the FROST scheme that allows the creation of multi party Schnorr signatures.

I propose to use it as a foundation for Zcash shielded transactions. There are several outstanding design points to complete:

• Derivation of the nullifier keys, viewing keys, etc in the context of a multisig account,
• Encoding of multisig keys
• The Zcash protocol rerandomizes the authorization signature. This is not supported in FROST yet.
• FROST has several rounds. The exact definition of the message protocol has to be specified.
• The protocol also depends on whether we have an aggregator or not.
• Currently, signing is a regular function. Because of the multiple rounds involved, it needs to be refactored so that it can run in stages
• Signers must be able to safely check that the request they receive is legitimate.

Solution Format

Each of the points mentioned in the previous section must be addressed before implementation.

• I will work with the ZF/ECC to validate and audit the design, especially regarding the cryptographic aspects.
• I will write and submit ZIPs as fit,
• I will define an API with input from the wallet owners who are interested in this feature
• I will implement a library in rust for distributed key generation and multisignatures (client and server)
• I will implement a (trustless) server that orchestrates the signing protocol and the distributed key generation
• I will add test vectors and unit tests for both client and servers
• I will write the documentation to help wallet owners. It remains their choice and responsibility to integrate.
• I will add multisignature to ZWallet

This project is for NU-5.

Technical approach

Key Generation

Users participate in a distributed key generation protocol with assistance from a server (hosted in the cloud or on premises). After which, they are given a secret key share, a group viewing key and an address.

Alternatively, if they want to do everything off line, they can use a command line tool and transmit the data manually. Due to the nature of the protocol, this means sending a file to each other party and therefore receiving N-1 files. Then the secret share and public key / viewing key are calculated. This is similar to multi sig in Bitcoin which uses xprv and xpub keys to derive joint address.

Signing a transaction

To spend from the multisig account, the initiator wallet generates a session QR code. He/She sends it to each co-signer who then can connect to the multisig server.

contacts the server passing the transaction data (inputs/outputs), encrypted for each of the other parties. Other signers retrieve the signing request and calculate their signature share (after confirmation from the user). The shares are aggregated to produce the final transaction and is transmited to the network. The server only knows the IP and the timestamp of the transaction.

How big of a problem would it be to not solve this problem?

Users can use transparent multisignatures but will not benefit from the privacy associated with shielded transactions.

Execution risks

• Though the low-level cryptographic protocol (FROST) is well defined and studied, there is a need for adaption to the Zcash protocol
• The high-level protocol between signers needs to be designed, reviewed and implemented
• ZIP may take longer than expected
• How multisignature addresses fit with UA is TBD

Unintended Consequences

• Multisig accounts work differently than regular accounts and users need to be aware of it, specifically regarding the handling of their keys
• The aggregator server must be up and running or multisig accounts will not be able to spend. However, a private entity can always deploy their own instance

Evaluation plan

• Design Documentation
• ZIP
• API documentation
• Implementation as a rust crate
• Support in ZWallet