Future of Zcash

General
22

Gemini supports sending to Z-address, but doesnt support me receiving as a shielded Z-address, which is why (obviously) I also can’t use the shielded memo features.

It is very nice that Gemini supports sending to Z-address, they’re the only US broker that does. Sadly, I’m in the situation like the vast majority of other crypto users… I had to trust somebody with my Pii and bank info in order to open the account and begin making purchases :frowning: eventually I hope we get to a point of reasonably trustless non-KYC broker services.

T-addresses always seem to prove themselves as a blessing and a curse haha. You’re spot on in noting that many brokers haven’t axed ZEC yet because they’ve only interacted with T-address types.

1 Like
23

Priority #1 I keep saying this but seems no one listens? Where did all the funding go to?

We need mainstream shielded address, easy to use wallets for hodlers. Period. This should be priority #1!!! At least let people hodl large amounts in shielded address in peace while we are down 99.99% !!!

Shielded pool numbers will skyrocket, people will realize there is actually adoption and that it’s safe here and not just a VC vaporware marketing coin. Price will pump as inflation comes down, adoption goes up, THEN we talk about developing all sorts of fancy tech when zcash is at $1k.

Why don’t we create our own hardware wallet to compete with ledger and tezor? I would if I could but I am not technical and I don’t know how. Please do this.

2 Likes
24

I just feel we are stretched too thin in too many areas, trying to think of ideas to fund and try pump the price, meanwhile regarding the most basic function that retail adoption would need.
(Easy to use Shielded address hardware wallets for retail to hodl in)

2 Likes
25

Welcome to the forums @Mikecryptolife!

Priority #1 I keep saying this but seems no one listens? Where did all the funding go to?

I think this is all in the transparency report the entities receiving funds release quarterly. The more eyes there, the better!

You make a great point here.

My impression is that the different wallet teams are competing against each other over basic functionality and that’s not helping creating an overall experience that people (users) can relate to.

When you think of using BTC, ETH or SOL, users do have a more or less uniform expectation on how things go.

We need to improve how we combine our efforts towards bigger goals. We have 3 teams dedicated to fix syncing with three different approaches: Warp Sync, Blaze Sync and DAG Sync. None of them are interchangeable or usable by others. It’s a inefficient allocation of effort. I also have doubts on hardware wallet support in the works. Would that be modular enough so that other wallets can benefit from it? Or would the other wallets be obliged to commit resources to “get on-par”? Will Ywallet and Zingo! be able to use DAGSync?

We can see this pattern around many features in different point in time. Like the amount of effort the Zingo Labs folks had to put into bringing ZecWallet code into being compatible with public Lightwalletd infrastructure and librustzcash main branch. They had the vision and purpose of doing that great deed. They turn it around but at big cost as well.

what if the base layer was so feature rich that effort could be invested in other things that make wallets UX better, more focused to their audiences, worrying about being better to their public instead of worrying about basic stuff like implementing ZIPs for themselves?

This leads to the way we Zcash developers build and how it feels.

I believe that Zcash’s weakest point is developer experience. Blockchains that have a lot of users like Bitcoin, Ethereum or Solana, also have a thriving developer community, great amount of resources dedicated to building tooling and resources that are articulated to get people in and capture the attention of developers that “want to get into crypto” but don’t know where to start…

What’s the “reference UX” for ZEC? If a student wants to build a Zcash wallet, what are the interface guidelines and resources at their disposal to get that project to completion?

If a multi-coin wallet wanted to bring Zcash into their applications, what should they do? what are the expected things they would have to consider? Is that easily available to Engineering Managers making those decisions?

It would be awesome! But I think this is too much of a stretch. Ledger and Trezor a backed by Millions of dollars of funding and are huge companies. We are currently in a situation where our founding company reduced it’s staff because it couldn’t afford it. Building software is hard, building hardware is even harder.

Most of the public use crypto through custodial means like Exchanges, which are hugely VC funded. The LUNA implosion and the FTX explosion revealed many of those VC backed exchanges to have shady management. Unfortunately for us, the average crypto used does not seem to care about “VC vaporware marketing” products, because if that was the case, ZEC would be skyrocketing and currently it isn’t :frowning:

Thank you for your thoughtful insights! I how we see more of them!

Cheers!

4 Likes
26

I seem to remember hanh offering to add Warp-Sync to librustzcash crate and ECC rebuffed him. Were you at that time advocating for implementing it or not?

1 Like
27

I’m not aware of such “rebuff”. Could you point out the situation and provide more details?

Me personally, always advocated for spinning the virtuous wheel of open source collaboration and always worked towards that. Even putting after hours and spinning up working groups towards that goal.

I’d love that Hahn’s work would be available in all wallets. First because is great work from a great developer. Secondly because It was funded with dev funds and everyone in zcash should benefit from it, :smiling_face:

Ps: Also, let’s try to keep the discussion constructive :slightly_smiling_face:

4 Likes
28

I think this example is constructive and instructive of the past and future of Zcash, and the people that work at ECC and ZF that make tech development decisions.

Lets start with Hanhs first Ywallet grant from July 2022:

In the grant he offered to integrate Warp-Sync into librustzcash including full documentation:

‘’ I offer to integrate Warp Sync into librustzcash.‘’

‘‘These parts would be put into librustzcash and wallet devs would be able to use them. There would be some small work to integrate. But documentation and help will be provided.’’

‘‘In librustzcash repo, we would have zcash-warp (or something similar). It should follow the same API as the current synchronization API (but with some deviations when necessary)’’

‘‘Warp Sync is optional and the current synchronization mechanism in librustzcash will not be removed.’’

‘‘As the maintainers of librustzcash, the ECC devs have the final say in accepting/rejecting the PR. Though, we will work together to make the PR successful.’’

But we learn later from ZCG committee member Aditya in ZCG meeting minutes; that there was no interest from ECC to integrate Warp-Sync, as they were all in in DAG-sync:

‘‘Aditya said that the ZCG has received feedback from wallet developers about the potential of incorporating warp-sync in other wallets, and it turns out there is no interest. The Zcash wallet developers are working towards implementing DAG-sync’’

The grant was ultimately approved to the benefit of the whole Zcash eco-system. But without the Warp-Sync integration.

Hanh also provided developer documentation YWallet & Warp Sync - #75 by hanh.

What I find most interesting is a post from you in May 2022 where there was a discussion about wallet UX: Zcash UX Feedback - #7 by pacu

‘‘I must admit that all of the Zcash wallet developers have failed to collaborate with each other and bringing better sync times to everyone. We have Blaze Sync, and Warp Sync. None of those were contributed back to the Zcash Rust Crates. I’m not blaming anyone. It just didn’t happen. we all failed our users. Blaze and Warp sync are both incredible breakthroughs. They prove that there’s a better world out there, that a faster Zcash is possible.’’

It seems that you wanted Warp-Sync and Blaze-Sync to be integrated back into Zcash Main at that time; but you didnt comment or have anything significant to say when Hanh actually offered to integrate it.

Even as recently as February this year when discussing the positive feedback loop of the Dev Fund Nighthawk Wallet & Public Infrastructure - #44 by pacu
You posted this:

‘‘A real example of what I’m talking about has been the battle for the fastest syncing wallet. Let’s think about it and question ourselves:
Did that contribute to improving the overall well-being of the Zcash community?
How can others benefit from Blaze or Warp Sync if they don’t want to fork the whole wallet code?
How do other developers benefit from the breakthroughs that wallet teams funded from “the Dev Fund” produce?’’

Seemingly forgetting that Hanh himself offered to integrate Warp-Sync into back into Zcash Main and provided documentation, and that it was ECCs decision to not integrate Warp-Sync.

So, As one of the main wallet devs, were you at the time advocating and supporting internally for Hanh integration or not?

I think this story is extremely enlightening because it highlights ECCs attitude to outside devs. Not very welcoming (to say the least).

5 Likes
29

@gottabeJay I apologize for not replying to you sooner. I wanted to take time to read your thoughtful and dedicated response and be respectful of the time you dedicate to it and not just provide a quick answer.

We might be sharing some hopes and dreams my dear Zcasher!

You don’t have the obligation to know so I’ll explain something about that. My heartfelt hopes about bringing enhancements back to the upstream work were well known both publicly and internally at ECC. But they are just that. Intentions, positive thoughts, a work philosophy. Often software engineering has other plans! That’s the most difficult part of this beautiful discipline.

Software is far more much complicated than what one could hope when it comes to accommodating everyone’s stake. There are requirements that have to be reconciled, code that needs to be repurposed, some things will possibly be empowered by those changes and some others won’t ever be possible to do after. There are always trade-offs. Software is malleable, yes, but it’s really hard and time-consuming to do.

Again, you can quote those opinions of mine because that’s what they are. My opinions, my feelings, my philosophy.

When you work within a company and a team, all the work done is mostly within that framework and context, it’s not about what individuals think, it’s about the company and the teams.

For the Warp-Sync integration, I didn’t have much to say other that what you read. Since I was not part of the core team, I was not a maintainer of librustzcash or zcashd. I did the eventual contributions here and there but in those terms I was just as anyone else contributing and sending pull requests.

It’s not for me to say anything about what ECC as a company and the core team ended up deciding. I fully trust the technical abilities and the integrity of the members of the ECC Core Team on their technical assessments. I think it’s for them to say what was possible or not at the time. They are the best developers I’ve ever known and I know very good ones. So I don’t doubt their judgement at all.

ECC developers have a really good track of supporting contributors and their pull requests so it’s not accurate to say or imply that they are not welcoming or anything like that. On the contrary, they go above and beyond to support the Zcash community and we shall all be grateful to them.

Edit: poor grammar on my part :melting_face:

6 Likes