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.
- 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
Schedule and Milestones
The project is split equally between the design and specification phase and the
implementation phase
- M1 Design: Adaptation of FROST to zcash
- M2 Design: Key/Share derivation and encoding
- M3 Design: Co/Signer workflow and message protocol
- M4 Design: Client (Wallet)/Server API
- M5 Design: Transaction Builder for multisig
- M6 Implementation: FROST for Zcash
- M7 Implementation: Key Generation and utilities
- M8 Implementation: Transaction Builder
- M9 Implementation: Client/Server
- M10 Integration: ZWallet
Budget
Each milestone is roughly of equal size and takes 10% of the overall budget for
a duration of ~1-2 month.
- M1 Design: 10%
- M2 Design: 10%
- M3 Design: 10%
- M4 Design: 10%
- M5 Design: 10%
- M6 Implementation: 10%
- M7 Implementation: 10%
- M8 Implementation: 10%
- M9 Implementation: 10%
- M10 Integration: 10%