So, this is my take on the shielded transactions piece:
I think Zcash Foundation is super busy for the coming months on Zebra and the network upgrade.
it sounds like FROST itself as a proposed scheme for shielded multisig is still getting outside review? (not sure about this, but that’s my impression.)
it sounds from what you’re saying that you don’t have the expertise necessary to implement FROST from scratch (which is fine!!)
shielded multisig seems like something that won’t be possible within the timeline of the grant.
It’s not just something that happens with Halo, it’s more like ZF won’t even be able to work on this until the next upgrade, and then there might be other priorities.
You should reach out to ZF and confirm all of this, and we can help connect you, but I think that’s where things stand.
If you end up working on transparent multisig, I think that could be cool, but the value will be in paving the way for shielded multisig. For example, figuring out the UX and what the API calls are for transparent multisig could be helpful so that when shielded multisig is possible, it’s just about wiring it all up and most of the user-facing bits (and the developer-facing bits) are already in place.
That said, I’m not sure if you’re going this route that it makes sense as a soup-to-nuts new wallet.
If you were jazzed about diving into the basic crypto implementation and working with ZF to get shielded multisig (FROST) working, and the way you preferred to approach it was to make a new wallet, that would be so overwhelmingly awesome we’d want to fund it, even if we weren’t totally convinced that a new wallet made sense as part of this work.
But if the core work of getting shielded multisig working isn’t part of the grant, I’m not sure if we’d be as into funding a new wallet.
I think we’d be more into paving the way for shielded multisig support in one or more existing wallets by getting transparent multisig working. Does that make sense?
Also, I should be clear that I’m speaking for myself here and guessing at what others on the committee think. Others might feel differently.
As you can see, this is far from trivial. I think the same approach can be adapted to FROST and it will not require a change of the sapling circuit either.
I think the key idea is here.
We ended up changing the lowest level of the key tree: ask is no longer the result of key derivation from sk but computed in distributed manner between untrusted parties.
I was unsure if z-addr multisig is available yet and somewhat seeking confirmation on it. Regardless I personally find that multisig is a better cold storage than hardware wallet thus pushing for it with z-addr or not.
Ideally it would be great if it can be be useful to other wallets. I believe the implementation would probably more like a library in this case.
2 & 3. I’m unsure of the work flow between ZF, ECC, ZOMG so would probably need some advice here.
Would probably need to check out Zecwallet’s github but this question might be better suited for @adityapk00 to answer.
Sure
Sure. There’s the official link of the project provided under Algorand articles within the grant proposal.
You pretty much described my doubts regarding the readiness of the implementation. Personally I feel that the UX portion would be drastically different from most existing wallet thus the proposal to do a new wallet.
I can understand if transparent multisig is not a priority of ZF.
If it comes to it perhaps i could just do a transparent multisig wallet for my own use and wait for FROST to be upgraded to the protocol. The proposed idea comes from my own cold storage needs.
If so, would it happen in the course of things that you’d submit a PR for adding multisig support to these libraries? Or is that not how it would go?
(Anything that makes the underlying Zcash libraries more useful to other developers makes the proposal stronger and funding more likely, in my view.)
If it helps lay the groundwork for shielded multisig, by figuring out the UX and other details, that makes the proposal stronger and an easier decision to fund, in my view.
Also, I think it’s a good sign that you personally would use this, even if it just supported transparent transactions, for keeping funds safe.
If you can persuade us that there’s a broader set of users who like you would benefit from transparent multisig for cold storage, that also makes the proposal stronger and funding more likely, in my view.
(Though shielded multisig is the thing we’re the most excited about.)
Have been doing quite a bit of research on my end the past few days, I think it may make more sense to make a shielded multisig after the FROST upgrade is done. Especially so since ZF & ECC seems to be more focused on increasing shielded transactions in the network.
Will do us some good too since it gives us time to research and prepare for it. Don’t fully grasp some of the technical implementation as of yet.
The cool thing is that they behave just like normal sapling addresses. Unlike multisig t-addr, the sender does not need to change at all. For instance, the testnet faucet works fine.
Of course for spending, there are few more steps but they can be done offline too.
I just watched the video and it’s exciting that this is possible! I had no idea that shielded multisig was this close to ready.
Even if it’s just a prototype and not ready for primetime as @hanh says in the video, it seems possible that it’s enough to start building on.
@hanh it’s really cool that you put this together and I hope we can fund your work! If we fund your work on coldwallet, would you want to work on multisig next?
It’s possible you could collaborate with tonychew, and it’s also possible that you could help Zcash Foundation with implementing multisig.
Also, this is a random question that doesn’t relate directly to funding, but @hanh, is it currently possible to create shielded multisig transactions of the kind proposed in the Bitmarkets paper?
This is the basic idea:
The seller puts up 1x price of item as a deposit and buyer puts up 1x for deposit + 1x for payment. These can only be released when both agree on payment or refund. This keeps incentives aligned without the need for escrow agents or reputation systems.
The cool thing about this design is it’s a coherent proposal for doing trustless marketplaces, i.e. without the need for third party arbiters.
I like how Electrum has support for 3rd party hardware wallets. Even though support is sometimes terminated with not much notice, they try to support the best hardware wallets, plug and play style.
I think this should be possible. The only issue I can see is the need of Distributed key generation - Wikipedia
if the two parties don’t want to involve a trusted setup.
The paper mentions a couple of solutions but it is not implemented yet afaik.
I like the powers of tau and perpetual powers of tau. A trustless setup would cool but I don’t (and logically no one who believes what they read about Zcash) consider it a deal breaker