Electric Coin Company 2019 Q1 Livestream


Thanks for joining us!

Unanswered questions:

  • current thoughts about asic resistance?
  • any plans for something like a lightning network for zcash?
  • do you see a long term shift to proof of stake?
  • Why did the 3 audits miss the vulnerability?
  • what makes rust a good language for crypto?

Feel free to add your own!

March 29, 2019 - Weekly update (Engineering)

A few questions from the Livestream chat:

How long until Mobile Wallets and hardware wallets support Z-addresses?

How long until Transparent addresses are depreciated?

  • what makes rust a good language for crypto?

Rust is a great language for building robust and secure software in general – this is actually its primary focus. It’s also very low-level (good performance) and so can serve as a substitute for C++ for many projects. I think for these reasons it is a natural fit for cryptographic engineering. It’s also much more recent so it can take advantage of the lessons learned by other languages in the last couple decades.

You can see many new projects in the crypto community using Rust and I think it’s for the same reasons. Zcash’s Sapling cryptography is written almost entirely in Rust, and I think moving more of our code into Rust will allow us to improve the quality and security of the software over time. Rust is therefore an important part of our engineering strategy going forward.


Over time I personally have been leaning more away from ASIC resistance. It’s hard, because having more distinct individuals mining is way better, IMO, to spread newly issued ZEC to more individuals and also to engage a larger userbase.

But I ultimately believe that economies of scale are pretty fundamental, so over long enough time spans PoW mining becomes centralized (regardless of whether ASICs are involved or not).

When Zcash started I imagined a 4-10 year timeframe for ASIC development assuming no changes to the mining algorithm. I was quite naive, and I was heavily influenced by David Vorick’s The State of Cryptocurrency Mining post.

I now believe the kind of approach Monero, for example, is taking with ~6mo or sometimes even faster rapid mining changes is actually detrimental to decentralization in multiple ways: first, I suspect ASIC developers (or FPGA or other entities with economies-of-scale edges) are able to react quickly and stealthily, so the end result is still mining centralization, just with less transparently. Secondly, it gives the developers powerful privileged insider information about mining, which increases the chances of corruption.

So I just don’t think that’s tenable for Zcash. Finally, I think if that were a goal for us, we’d spend a lot of effort on it, which would mean all other valuable goals would slow down in the meantime. I’d rather have mobile wallets and hardware wallets with strong privacy than a Zcash with the current adoption challenges and an uncertain mining decentralization outcome.


Copy/pasta of my comments in another thread:

" I think we are approaching a crucial window in time where once “everyone” offers privacy features in thier coin the winner will be who has the widest area of acceptance and the best user experience.

Reminds me of the Blu-ray vs HD-DVD war. HD-DVD had first mover advantage, and superior tech but ultimately Sony pushed Blu-ray into the most households via hardware like the PS3 and cheaper Blu-ray players. And just like that HD-DVD is lost to history.

Zcash is well into first-mover advantage and has the best tech, but the others are not sitting idle. We need to get UX and adoption of Z-addresses up, ASAP. "

I’m glad Nathan and the team are working on this.


The Sapling network upgrade removed the two primary blockers for shielded support in mobile and hardware wallets: performance, and spend authority control. The primary blocker since then has been library support: actually having production-ready code that can be picked up and used to integrate shielded addresses, in the same way that Bitcoin libraries are picked up and used (with relatively-minimal modifications) for transparent addresses. We are basically doing the same thing now that the Bitcoin community had to do 5-7 years ago: writing libraries from scratch to make the tech more widely usable.

The reference wallet project, over the past eight or so months, has generated a lot of code that will be useful in this regard:

  • The Android SDK and lightwalletd server will be usable pretty much directly by Android mobile wallet developers.
  • The Rust code backing the Android SDK is its own API and will be usable for mobile wallets on other OSs, as well as in the browser. Developers for a platform would need to write their own harnesses to leverage the Rust components (until we or someone else writes an SDK for the platform).
  • The Rust code may be usable by hardware wallet manufacturers, although this depends on their appetite for deploying Rust (even as a static dependency used via a C FFI). If they don’t want to do this, then they will need to rewrite the entire Sapling stack in C.

I can’t speak to timelines, but I can say that none of the above will happen before at a minimum the Rust code has been reviewed and merged into the librustzcash repository. This is ongoing; we have several open PRs currently being reviewed, covering the Sapling commitment tree and note encryption.


The Zcash protocol is made up of many components. There’s the consensus layer that provides an append-only ledger; there’s the transparent protocol inherited from Bitcoin (with changes); and there are two shielded protocols, Sprout and Sapling. These each use various cryptographic components, such as hashes, commitments schemes, signatures, encryption schemes, elliptic curve key exchange, zero-knowledge proving systems, and so on.

So, there’s really quite a lot to audit. The Sapling protocol spec is written very densely and it’s still 142 pages; this doesn’t even include the specifications of existing cryptographic components that we have reused. With the possible exception of the transparent parts, the vast majority of this is necessary complexity for a protocol that provides Zcash’s functionality.

The counterfeiting vulnerability was in one of the zero-knowledge proving systems, BCTV14, which had been published and peer reviewed several years before the development of Zcash. The audits necessarily, given the resources and time available, focused mainly on the new components that had not previously been peer reviewed.

The designers of Zerocash had selected BCTV14 as the zero-knowledge proving system. For many years, zero-knowledge proving systems had been too inefficient for practical deployment. BCTV14 and its predecessor, Pinocchio/PHGR, were breakthrough systems that provided order-of-magnitude performance increases; it was the development of these systems that made Zcash feasible. For technical reasons, we could not have deployed Pinocchio (that system depends on symmetric pairings which had been found to be less secure than desired). So at the time, BCTV14 was one of the only practical options available. Unfortunately, the changes that BCTV14 made to Pinocchio were only argued informally; it had no security proof. None of the audits included security analysis of the proving system; indeed, we probably couldn’t have found auditors with the expertise needed to analyse that system in the time available, at any price, since that expertise was only present in the academic community rather than in commercial auditing companies.


We don’t have explicit plans inside Electric Coin Company, but that’s partially because there are ongoing efforts elsewhere: Bolt Labs is developing the BOLT protocol which is similar to Lightning protocol with stronger privacy guarantees.

Lightning itself is close to working with Zcash t-addrs. To do so, Zcash could implement Bitcoin’s OP_CSV, and we may also need to figure out a malleability issue (since we use a different approach to that than Bitcoin’s segwit).

I’d love to see devs from outside ECC contributing ZIPs for BOLT or Lightning integration!


The Zcash Foundation has funded ongoing research into BOLT private payment channels. BOLT is similar to the Lightning Network but with privacy:


Also @nathan-at-least is BOLT integration anywhere on the Blossom or NU3 roadmaps?


I think it’s too late for NU2-Blossom. For NU3, if there’s a workable ZIP proposed by the end of April, there’s a fair chance it could get into NU3. Nobody at ECC is working on BOLT for NU3, though.


I see this as a possibility. I think internally to the company we don’t have a unanimous stance on PoS.

For my part, I’m less familiar with PoS, and also I’m a bit wary of both the economic implications (is it better/worse than PoW for economies of scale?) and security. The combination of both is even more worrisome to me, where I keep seeing claims that various existing systems are leading to oligopolies.

OTOH, I see a lot of potential benefits: lower energy consumption, faster / higher throughput consensus, an explicit roster of the players involved (unlike PoW’s potential for hidden miners).

Also, I clearly see how hybrid PoS/PoW schemes can potentially have stronger security than pure PoS against rollback attacks, so I’m much more comfortable with that class of designs.


Still working on Coda? If so, how is that going?


My current thinking is to head toward hybrid PoW/PoS. I think a hybrid of the two is likely to be better and stronger then either one alone, and it allows both miners and stakers to participate and to earn ZEC for supporting the network.


We don’t develop the Coda protocol. You mean this one, right?

However, it relies on zkSNARKs also, but for a different purpose, so we’re familiar with the tech behind it, and the overall design. That’s definitely an area we’re paying attention to that can potentially apply to the kinds of horizontal scalability improvments I mentioned in the live stream.

@daira specifically has spent some time understanding Coda and then also researching similar technological components for potential Zcash scaling, so ze could probably give you deeper and more thorough details.


Teaser: I’ll be doing a presentation about Coda-style scaling at Zcon1.


Thank you all for participating! I’ve got to run now, but I’ll keep an eye on these threads over the next week.


It’s also worth pointing out that in a sense, our auditing did find the BCTV14 flaw, since Ariel Gabizon was working for Zcash at the time. We just didn’t find it in time for the Zcash/Sprout launch.


Tatanka nass​ asked:

what is the difference between mimble wimble and z snarks ?

Mimblewimble uses Pedersen commitments (the same primitive we use to chain Sapling inputs and outputs together, but used in a slightly different way) so that transactions do not reveal values, leverage a really neat trick for addresses which I won’t go into, and can be “merged” in a block (so if Alice pays Bob, and then Bob pays Charlie before the next block is mined, the block would show Alice’s coin being spent and Charlie’s coin being created, with Bob’s actions dropped completely). This provides some scalability and privacy benefits, but it does not hide the transaction graph. The graph visible in the block chain is certainly a reduced view, so some information will not be visible to a lazy adversary, but a global passive adversary will collect every transaction that is broadcast over the network and see the full transaction graph pre-merge.

zk-SNARKs OTOH enable the transaction graph to be completely hidden, because transactions do not refer specifically to any earlier transaction. All you learn is that the input to a transaction is some note created in the past. Thus another way to think about this is that the traceability set for a zk-SNARK-based block chain like Zcash is larger than for a Mimblewimble-based block chain.

The flipside is that Mimblewimble-based transactions are significantly cheaper to create and verify than zk-SNARK-based transactions.


There have been a couple of papers on block chain analysis that have heavily influenced my thinking and raised the priority of removing t-addresses; in particular one by George Kappos, Haaroon Yousaf, Mary Maller, and Sarah Meiklejohn. I don’t think there’s any significant disagreement within ECC at this point that they need to be removed. The obstacles to removing them are described in one of my previous forum posts. Since then we’ve made some progress on designing shielded multisig, but otherwise the issues are roughly the same.