Ian Miers: Board elections, the foundation's mission, and making usable privacy a reality

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.

I agree with all of this.

3 Likes

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)?

6 Likes

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.

3 Likes

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.

4 Likes

Great post, Ian. And thank you - this really does help clarify some things for me relating to your candidacy.

“Adoption, adoption, adoption”

If there is no one shouting that out, there will be no one to shout anything to…

2 Likes

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.

6 Likes

there ARE light clients, ElectrumX supports Zcash, there are DEX clients that use it, etc and mobile ones using it on the backend for taddr’s only

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

There’s no Electrum client that does z-addrs though right (and that’s the important part)?

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.

5 Likes

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.

4 Likes

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

1 Like

the github link is in a browser tab on my other laptop tho!

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.

1 Like

ohhhh, nice, what branch has the windows rust build working, your mingw one in your repo or a diff one?

The mingw32 one (that you used for WinZEC 1.1.0). The first two commits fix the Rust compilation.

(We should probably get a moderator to shift these into another thread :sweat_smile:)

1 Like

I wrote my response to this here. In 2016:

whole thread is worth reading.

2 Likes