Zcash does not have full fledged cross-platform support. I think the current state of the Zcash “product” is a travesty. In general, no single party is acting like Zcash is a user-facing product, and nobody is willing to own the experience of using it end to end. At the end of the day this has to be our highest priority: simply hoping that others will address this problem does not a strategy make. Zcash has an excellent reputation for its technology, but technology doesn’t matter if nobody can use it. We have to fix this.
This is a fantastic post and I am in complete agreement.
One question with regards to wallet development. I’m guessing most casual users really don’t want to have to download the blockchain to use a wallet and I’ve often wondered why we have never seen a light client developed for Windows/Mac (Electrum style). Is this still technically infeasible even post-Sapling (similar to the mobile issues you mention above)?
Me too, though I still equivocate on if the strategy to fix it should come from the Zcash company or the Foundation. Anything that enhances pragmatic application & usability of ZKPs (within Zcash as currency or otherwise) seems like a good place for the Foundation to lead, but driving adoption (a second order problem to usability) seems like something in which the Co should be incredibly invested. Having full time developers at the Foundation seems like an obvious win, the trick will be agreeing on the specific projects they should be working on.
I don’t think it’s infeasible, but it requires careful design to preserve privacy. It’s probably better to get it right rather than deploy an Electrum-style wallet and service right now, which would not have very good privacy. I think there may be increased interest (and development) in this area post-Sapling, because shielded transactions will finally become viable for mobile wallets, and they will want to avoid downloading the entire blockchain if possible. Certainly an area that the Foundation could move forward with R&D to recommend the best approach that maximises privacy when clients have constrained storage space.
Its feasible to do a light client, but it requires some protocol enhancements that may or may not need a hard fork. Thinking about this is how I first I came into the usability problems, and to address @amber’s point, where it intersects with almost any vision of the foundation advancing privacy preserving protocols.
To generate payments, you do not need to have the blockchain at all. You just need to keep the merkle tree path for your coins up to date. This requires you to only see the “live edge”/frontier of the merkle tree per block. Thats less than 20mb a month even if done naively.
The problem comes in when you want to be notified you were paid. Currently, to be notified you received a payment from someone else , you need to scan the blockchain and try and decrypt every transaction. If it decrypts, its yours. Obviously, if you can’t download every block, we need something else
There are a couple approaches. One option is to simply to reduce the amount of data you need to download to be e.g. 256 bits per TX. Another very simple one is to simply delegate detection to a third party. The party will learn you received a payment, but not from who or how much it was for. This isn’t ideal, but its simple. We can build on this to enhance the privacy of the user. Another option is to have payment notification be out of band, e.g. via some anonymous messaging mechanism.
A final and dead simple one is trusted hardware. That has the obvious limitations, but would be fast and at least better than simple delegation to a third party for detecton.
Zcash support has been in ElectrumX for over a year iirc, as forks wanted support and adding zcash was their first step, and then changed various protocol params depending on the coin
FWIW, I received a Foundation grant (2017Q4) to work on a Rust implementation of the Zcash client (validation-only to start with). This will open up many possibilities for cross-platform development (because Rust is great for this), including mobile and WebAssembly. The idea is that eventually we can move away from the extremely crusty Bitcoin/C++ codebase, with all its oddities and strange RPC commands, and move to something that is more developer-friendly. The Sapling work done by ZcashCo is already going somewhat in this direction, as it is mostly written in Rust, but ultimately I want to end up with a fully-fledged Rust implementation.
I agree that this needs to be massively improved. BTW, ZcashCo has published a great UX checklist for wallet developers, which is kept up-to-date as the protocol is developed, e.g. it now includes guidelines about transaction expiry.
Ironically, you have to TURN OFF rust support while its still optional to get zcash and many forks to build on non-linux or non-x86 platforms, because #reasons…
which is acting as an additional deterent to forks pulling in sapling related features, the rust requirement is being a hinderance
no there are not, although a group in Catalonia has developed a light client protocol to do them, as they intend to use Komodo asset chains and zaddrs with a voting protocol i designed to do elections, so they needed one
that work has not yet been made public, as my design needs a whitepaper co-author or two its a two to three page design notes i fleshed out on the chalkboard, and screenshots of that, during a closed door lecture to democracy activists at a uni in barcelona province
ground breaking anonymous and auditable election protocol due to a unique way of using various t and z addr txns in sequence
see at heart I REALLY am an unfunded researcher, I actually do not LIKE software engineering all that much any more to be frank, as I’m burned out after years of user support, sysadmin, dev ops and legacy financial system sw dev of truly mission critical stuff
That’s only because the Rust parts hadn’t been cross-platformed by anyone yet. I’ve done so for Windows (which will hit master once the cross-compile branch is merged), and non-x86 platforms can follow a similar path.