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
I have completed the Cold Wallet and BTCPay Server integration grants for Zcash
and I am the primary developer for ZWallet.
Multisignature transactions have unique use-cases not covered by regular
- 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
The ZF has published the FROST scheme that allows the creation of multi party
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
- 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
- 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
Each of the points mentioned in the previous section must be addressed before
- 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
- 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.
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
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
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.
Users can use transparent multisignatures but will not benefit from the privacy
associated with shielded transactions.
- 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
- ZIP may take longer than expected
- How multisignature addresses fit with UA is TBD
- 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
- Design Documentation
- API documentation
- Implementation as a rust crate
- Support in ZWallet
The project is split equally between the design and specification phase and the
- 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
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%