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

There’s been a lot of talk about governance, ballot proposals for some actions, but little about a concrete strategy for the Foundation. In this post I want to provide my vision for what that strategy should be, over the intermediate and long term. This is why I’m running for the board.

First, let me state my motivation. I am a cryptography researcher and one of the original developers of the Z(ero)cash protocol. More fundamentally: I believe in the promise of privacy-preserving technology and cryptocurrency. In many ways, the existence of private currencies like Zcash is the realization of a dream I’ve had for most of my life and nearly all of my research career. My candidacy for this board is predicated the idea that, despite the success we’ve had, that vision has not yet been fully realized.

Before I get to the main challenges I think our community faces, let me start with some of the successes. From a technology perspective, Zcash has done some amazing things. The fact that the Sprout release works and has been accepted by the community should be viewed as proof that the technology works and can scale, even though it isn’t the final result. Moreover, the work Zooko and the Foundation board and others have done to promote Zcash adoption (including approval of Zcash by NYDFS!) has been incredible.

While the work so far has been terrific, there are a number of important technical challenges facing the currency and platform. (I’m going to focus primarily on Zcash here, but I want to be clear that addressing these issues will benefit other downstream forks of Zcash, and potentially other coins as well.)

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 think some clear goals for the Foundation should be to build and package cross platform GUI clients:

On Windows, OSX, and Linux (in that priority order)
On mobile platforms
On the web (for example, post-Sapling it should be possible to generate shielded TXs efficiently in WebAssembly)

These packages should be clean, usable, and (post-Sapling) should default to shielded transactions. This involves both developing or modifying an existing GUI packaging it, and shipping it. For mobile, achieving privacy involves protocol enhancements that we still need to develop. While this is not strictly a board member duty, I intend to participate in and guide that activity.

How to go about this? The question is how to achieve this. In my view, the Foundation either needs to hire full time employees (my preference) or to engage a qualified contractor. The grant process just isn’t appropriate to achieve this sort of goal, as it doesn’t provide the right kind of technical management… And grants mean that nobody owns the result after the grant is up: they are mostly “fire and forget”.

As a board member I will support efforts to make Zcash into a quality cross-platform product with excellent UX and a regular release schedule. I will also support the development of a high-quality technical team within the Foundation, so that these things can happen – and so development will be decentralized. This will benefit downstream forks of Zcash, as well as other privacy coins that choose to adopt Zcash technology and usable security techniques.

Developing protocol capabilities. The current roadmap for the Zcash company includes the development of an extremely efficient new version of the Zcash protocol (Sapling). This is a good start. However, zk-SNARK proving technology is a constantly-evolving field. The development of these techniques provides an opportunity for the Foundation to investigate and to prototype implementations of emerging techniques which may improve performance, avoid “toxic-waste”, and improve code verifiability. Building on the flexibility of zk-SNARK proofs, it is also possible to extend the protocol with new capabilities, such as user-issued tokens and privacy-preserving smart contracts.

The Zcash community has led in the development of these tools. We should continue to lead. This means identifying individuals with experience in these areas and (ideally) bringing them in-house to lead an implementation and research effort so that Zcash (and all other private currencies) will have access to this technology when it is ready for deployment.

Summary: the role of the Foundation. The main role of the Foundation board, in my opinion, is to assemble a team that can address these key technical challenges in the short term. While this doesn’t preclude additional (future) missions for the Zcash foundation, building this team – with the buy-in of the Zcash community – is what I plan to do if I’m elected to the Foundation.

I’m posting this here both to explain the purpose of my candidacy, and also to start a discussion within the community about these priorities. I look forward to hearing the responses.


@secparam Once Sapling is released, are there any remaining technical barriers to being able to do shielded transactions on hardware wallets like the popular Ledger Nano S? And in your opinion, should shielded transactions on hardware wallets be a development priority for the Foundation? (It seems that a lot of ZEC will flow to shielded addresses once hardware wallets can support shielded transactions.)


@hloo Assuming you mean hardware wallets with an attached but untrusted computer, the protocol level support for delegated proving should be there post sapling. The computer generates the proof, but the hardware token needs to produce an ECDSA signature on it. It requires signatures under different curves. Depending on how specialized the hardware is , that could pose a problem. Things like pay to snark hash can fix that.

The larger problems are privacy preserving mobile wallets for bandwidth constrained devices. Payment detection and getting updated witnesses.


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.


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.


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…


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.


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.


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

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