We are aiming to create a multisig wallet for zcash. One of the key reasons behind this is that we are power users of Electrum BTC & LTC. It’s one of the usage that we feel is lacking at the moment.
Rather than waiting for someone to do it. Thought we’ll just be the change we want to see.
Besides the addition of Frost multisig which as far as I understand relates to signatures, do you see an impact on the zk proof circuit? If so, does your team have the expertise in cryptography required?
We can understand and apply cryptographic logic on the application layer but if it involves something deeper then we may need to explore it before giving an answer.
Something like bitcoinjs-lib would be great. Otherwise we could leverage other existing libraries.
@tonychew1986 It probably goes without saying but just to be explicit: feel free to reach out to the ECC Wallet team if there’s anything we can do to support your efforts. The Zcash Community Discord channels prefixed with #public-community- are great places to go with any questions.
How about non-shielded multisig? Is it similar to the BTC implementation within bitcoinjs-lib? Would be great if there’s a JS library. I see that most implementation seem to be in Rust.
I couldn’t find any library either but transparent addresses use the same scripting language as bitcoin (with minor changes). You would just need to design an address encoding for p2sh since that’s how bitcoin wraps multisig redeem scripts.
If it’s similar to BTC then it should makes things similar since I’ve done it for LTC prior. That said though, is there any design document or other libraries (non-multisig) for ZEC?
Not as educated on the ZEC nuances as much as I would like to. Thus would be great to have some references on how to structure t-addr & z-addr implementation into a easy to use UI.
The vibe is have now is that t-address and z-address feels a bit disjointed. Therefore causing confusion on how best to use it for non-technical users.
T-addresses are similar to BTC but z-addresses are a completely different beast. I doubt there are any library other than librustzcash that you can use. I guess it’s because the zksnark system used in zcash is too cutting edge and complex to have been ported to js at this point.
However, you can either compile rust as a dyn library and use C FFI from node.js/electron; wrap as a native extension for react native/flutter/ndk, or compile as wasm and run it with wasmer.
None of this is as convenient as a pure js implementation, but I can’t think of any simpler solution.
That’s exactly I thought this grant app is for - multi-sig for shielded transactions. As developing multi-sig for T-addresses does not advance the usage of Zcash privacy features.
I still think providing option for t-addr multisig is a net good for Zcash. At least, would be useful for all the non-profit that accepts crypto donations. I agree though that it is not ideal and we should strive to create multisig for z-addr first.
I’m a bit confused by this statement. It was my understanding that you were aware that shielded multi-sig was not yet widely available in Zcash, and that’s what your proposal was going to assist in making happen, even at the protocol level.
Is this not the case? Or am I misunderstanding your position?
In the ZOMG meeting we read the grant proposal to mean that you’d dive into the technical details for how to implement FROST and build something that people can use—and this was definitely something we wanted to fund.
If it’s just for t-transactions that still might be interesting but it depends on the details. I think these questions can help us figure that out:
How will this work be useful to other wallets? (Same as @aiyadt’s question above). We’re always worried about how wallets will sustain themselves after the initial build out. So if this can help add multi-sig features to the underlying API, that’s great.
What’s your plan for working with ZF on this? If shielded work is part of the proposal at all, it seems like Chelsea Komlo @ ZF is the leader on this, and we’d want you to have a clear plan with ZF, and some understanding with ZF so that they can prioritize helping you with this. The Discord channel mentioned above or the Zcash R&D Discord channel (DM’ing you an invite now) would be great places to start.
What’s your plan for working with ECC? - The Discord and gmale are great resources here, and this will be important for figuring out how this supports other wallet work.
How does this work with Zecwallet? - Most Zcash users at the moment are using Zecwallet Lite. It uses a separate SDK from the ECC’s SDK. How will this work on multisig be usable in Zecwallet? ( @adityapk00 is the creator of Zecwallet)
Security audits? - To reduce the risks for eventual users, we’d like this work to be audited by an outside party eventually. We’re working on ways to help grantees with this, but since we haven’t really figured out how that will work yet, anything you can do to fit an outside audit into the proposal will be helpful. (For example, this could be as simple as saying you’ll seek outside bids, and apply again for funding for the security audit, and for mitigation work coming out of the audit.) We’re happy to discuss this more with you, too!
References? We’re wondering if there is someone from the Algorand project who could provide a positive reference. That would be really helpful for us.
Thanks! I have a few more questions but I’ll post those in a follow up.