Here are the unofficial minutes. I have also edited my earlier to add a seventh item to the list of follow up projects, RE Tor3 support for Zcash.
Community Brainstorm - Minutes (by Holmes)
Present:
- Zingo Labs (3 persons, including forum member @zancas)
- Ishan/@mrbabble (engineer)
- Hanh (projects funded by zomg: coldwallet, coinpayments. Also creator of zwallet)
- ECC: David Campbell (COO), Andre Serrano (BD). ZF: Teor (engineer). ZOMG: Michelle/ML_sudo, Holmes, Shawn/Minezcash, Hudson Jameson
Note: Aditya Zecwallet and Adi Nighthawk were registered but didn’t join due to coordination failures.
Hanh’s presentation (ZOMG - Google Slides)
DC echoes usefulness of making zcash easier to use in privacy focused distributions, and in Monero doing a good job at community.
Auto Senescence feature/limitation was a discussion
Discussion of improvements on speed increases
Discussion of difficulties using exchanges, and interest in Fiat onramps and exchanges for users in Canada. It’s difficult to sign up for international exchanges and it’s difficult to find Canadian exchanges in Canada. Gemini has almost no tech support and I have technical issues with them.
Ishan expressed interest in using Zcash on ecommerce websites using a privacy.com-like UI. We suggested being in touch with Zephyr.
Discussion re: prioritization of z-address vs. t-address.
Holmes expressed that it’s context dependent e.g. we would really want to fund z-transaction work in wallets, but might be okay with funding t-address work for DEX’s as long as privacy was considered, since those can be privacy preserving.
Andre and DC echoed this.
Documentation and developer experience (SDKs available for different popular languages) has come up a few times. Hanh brought it up and Andre echoed.
Holmes welcomed feedback on ZOMG’s grantmaking process from Hanh perhaps on a separate call.
Hanh expressed that it would be helpful to have more HALO 2 documentation.
DC answered Hanh’s specific question about smart contracts on HALO 2.
Hanh thought that ZSAs would have to be done by an internal Zcash team.
Hanh is interested in programmability and smart contracts.
DC says halo 2 introduces ability to add functionality without doing another parameter-generation ceremony. But what those look like and what they expose is up to the community to direct.
Zancas points out that there are features in Bitcoin that would be helpful in Zcash. “Our hope is that we can leverage features from Bitcoin in Zcash”.
Hanh points out that there are new opportunities opening up with Halo 2 to do some things that open up new functionality and that we might want to wait and see what kinds of things people apply for.
Hanh points out that it’s very hard to work on every aspect of the ecosystem, but that there are places for improvements.
There are some optimizations that would help light clients. Batch decryption. Hardware extensions? GPU usage? (See slides)
Zebra is batching most of our signatures so as long as there is appropriate cryptography that allows us to batch trial decryption we’d be able to batch trial decryption as well. I don’t know whether zcashd architecture would support that.
DC mentioned that zcashd is not working on optimization, but that there have been some changes for some specific things, e.g. diversified addresses for letting you check lots of transactions with one spending key.
Zcash is hard. It’s three coins in one. And the complexity of adding a new server implementation could keep growing.
Going between zcashd and rust is pretty hard because the structures are really different. Helping people approach this code.
DC isn’t sure if Bitcoin catchup is worth it, especially because of how attractive Rust. Zancas agrees re: working on Bitcoin code probably not being the highest priority.
How do we do big lifts of the scale that Hanh is pointing out?
Teor: can we make the lifts smaller?
Hanh: yes, it’s super hard to start from scratch, especially if you start with a language that doesn’t have any of the basics of Zcash.
Asks if reimplementation is a priority
Holmes asks about wrapping librustzcash, or zebra, or zecwalletlite
Holmes raises issue with chicken/egg.
DC reiterates that bindings for Zcash and lightclient everywhere. And there should be more lightwalletd’s. But he thinks it’s better to focus on that layer of bindings before focusing on backend.
Teor notes: this is Zebra’s network library, which has a Rust API based on microservices: init in zebra_network - Rust
Hanh points out that we’re using polling, even between zcashd and lightwalletd, instead of a streaming API for transactions.
More suggestions, from hanh slides
Integration of lightwalletd from Google or Apple services so that you can receive push notifications.
And it would be good to have more deployments.
DC: looking at how we can make the user experience better for syncing is great. And can we reward people for relaying transactions to the rest of the network. Can we incentivize people to run this infrastructure, so that we don’t have to keep writing grants.
Question about Zebra, whether Zebra is likely to become the prime implementation of Zcash. Is Zcashd already in the process of being phased out.
DC: there have not been any official decisions made, and the legacy code is a potential developer experience issue internally at ECC. It’s likely and possible that Zebra would become the official implementation. The ECC might fork it and build on top of it but there’s a lot of interest.
Teor: That’s not an official foundation position. We’d love for it to be the official implementation but it’s just not ready yet.
Zancas expresses value in improving zcashd.
DC: One area where we have pain right now with missing upstream changes is v3 onion support for Tor. Tor support is about to break in zcashd. It would be great to catch us up to v3 onion support and we would be able to offer help getting those accepted.
Holmes asks DC if there are any other priorities that they might not be aware of?
DC notes to Zancas that Larry Ruane is the person to talk to.
The good thing about librustzcash is that it’s a reference implementation. But it would be good to have this library usable from other languages. Also the API is agnostic of storage.
For librustzcash the documentation is basically the code. It’s not super easy to understand the API boundaries —hanh
So it would be great to have examples of how you do basic things. My hope is that eventually it would be easy to create multi currency wallets for Zcash without having so much knowledge of the Zcash protocol.
ECC’s one person on librustzcash is just working on Orchard/Halo 2
Holmes: Why don’t multicurrency wallets use the lightwallet SDK’s?
Right now these SDK’s are wrapping librustzcash so you have to wait until SDK opens up an API. lots of areas of librustzcash are simply not exposed. And if you look at what the SDK does it’s very close to the librustzcash API.
And these SDK’s target mobile. They don’t target browser extensions. Or desktop.
Other coins have done a good job with this. You have a lot of tools in python like pybitcoin, where in a couple of lines you can make a transaction or query your wallet status, or query the mempool. But right now that takes some work in zcash. It’s not like it’s not there but it takes a lot of work to get it.
As a newcomer I see a lot of people coming to the forums like how do I do this, but you start explaining it and they never come back. If the goal is to have more developers at different levels of knowledge. Or people who who to do a little experimental script. I don’t think ZOMG should give a grant to such a small project, but I think we should make it easier.
I’m keen on having simple scnarios doable in python because you reach a lot of tpopel.
Right now we have several developer teams working on zcash ecosystem and these people are working on it for a long time. It’s rare to have a new person and have them stick around. When they see they barrier to entry they get discouraged.
It’s cool when you can see that you can do this in ten lines and you’re not limited by knowledge but rather by their imagination.
Teor’s suggestion with this as someone who’s had to do the rampup over the past year is that there are a bunch of simple tasks, but often you’re using the zcashd RPC APIs or the command line or something like that instead of using these low level interfaces.
Zebra would love to know what the minimum set of RPC’s to support are.
Holmes says the RPC interface requires babysitting, more so than lower level libraries or bindings.
Hanh says that a lot of the stuff comes from a very old world of bitcoind. And it’s hard because if you want to use shielded you have to use one API where if you use transparent you have to use another API. So it may not be a good entry experience to users.
Also, this is the first level of programmatic access. If you’d rather do something more specific you’d rather have something linked to a lightwalletd. Before you even get started you have to wait 6 hours with a full node.
Suggestion, take people coming from other crypto projects and walk them through it and ask them what they’d like to improve, and I think you’ll see it’s not that easy.
Hanh notes on wallets. Performance improvements especially on synchronization.
Michelle solicits questions about stablecoins on Zcash. Hanh points out it’s easy if they’re transparent, and it depends on what your brand is, since it could come at a price in terms of image.
DC says it’s more about storing in shielded vs. t2t.
Michelle, if I want to do stuff in Defi with my Zcash, I have to liquidate.
DC points out you can do this with renzec.
Michelle asks whether Hanh would be interested in building the quick non-shielded version of tokens on Zcash. Both are interested in having another call.
Michelle wonders if anyone would be interested in working on a “Matering Zcash” book. Ishan expressed interest.
Michelle mentions docs for regulators on AECs, and joining up with privacy protection watchdogs. It might be good to join with privacy watchdogs, and make use of their reach and message.
Final one is partnerships with humanitarian organizations. Where people for safety require financial privacy.
Re: Weekly Zcash newsletter, Ishan says that kind of exists with the arborist calls, but that’s maybe 50-300 views on a weekly basis. But maybe the idea with a newsletter would be to broaden it to a wider audience.
(See slides)
DC thinks there’s a void around simple layperson messaging.
Michelle responds in addition to this simple information it’d be great to have in-depth but easily scannable pieces. The videos that are posted assume a lot of context.
A great example is the bitcoin videos But how does bitcoin actually work? - YouTube.
Hanh’s point, to be fair, if it took him 8 videos to explain bitcoin it’d take him 100 videos to explain Zcash.
Zingolabs (who?) said they’ve worked with media before and could reach out to people.
Holmes said that we would be able to find applicants for political work, and (in response to Teor concern) Holmes and Michelle said we thought they would be able to do this within 501c3 rules.
Hanh invited everyone to his Zcash gardening club presentation tomorrow.