Technical AMA w/ ECC team July 12, 2019 noon PDT

The Electric Coin Company is hosting an AMA on Friday, July 12th at 12:00 PT/15:00 ET/19:00 UTC. The team will be online taking questions for 2 hours.

This will be the thread which we will be taking and responding to your questions - please keep questions focused on technical topics related to Zcash.

We hope you can join us!

Our last AMA was in December 2018: Technical AMA w/ Zcash team December 14, 2018 noon PST

Edit: This AMA is now over. Thanks to all who participated!


Hello, any plans to switch to fully private addresses by default? If so when? If not why not? Thanks!


I hope this is a good opportunity to get expert eyes on @JKelley’s question!

As a project I want to extend both the Zcash protocol and implementation such that a new type of unshielded transaction is added which uses a different signature algorithm. Protocol design is complete but when it comes to the implementation I have problems finding out which parts should I change. I want to change both mining part to allow miners to accept this new kind of transaction and the client part so that users can make such transactions.Could you help me by pointing out the functions/classes to be modified in a general or a specific way?

Original thread: About extending Zcash implementation

What is the expected timeline on implementation of the full view key functionality?


If a user takes absolutely no action , say for 1, 5, or 10 years, except preserve their private key, will Ycash be available to them after the fork? How so?

1 Like

Would the future zcash bridge on polkadot increase zcash’s on-chain total payment volume?

1 Like

We all want to switch over to fully shielded addresses. Some concerns remain though:

  • shielded address adoption is not high enough yet in third party apps
  • interoperability isn’t good (i.e. transparent addresses generally can’t send to shielded, unless you’re running a full node).
  • there are regulatory concerns with shielded addresses in some parts of the world.

What we’re doing now is generally the following:

  1. work on interoperability between transparent and shielded transactions (the wallet team’s reference wallet just got shielded addresses to send to transparent addresses in a light client, we’re working on getting transparent addresses to send to shielded ones in some other capacities).
  2. generally, try to work to improve shielded addresses instead of transparent
  3. stop (or at least be very cautious about --edit by Daira) improving unshielded transactions
  4. provide resources for integrating transparent addresses

Until some of these concerns are addressed, it’s hard to say when we’ll switch to shielded being the default.


We’re still working on a timeline and there are a few other priorities ahead of it in the queue so I can’t give a really accurate estimate but I would expect viewing keys to be implemented this year.


This might help:


We would be happy if this would be the case. :slight_smile:


I think this is probably a question for the Ycash team.

EDIT FOR CLARITY: Zcash and Ycash are completely independent of each other. So anything that happens with Ycash after it forks from Zcash is entirely up to the Ycash development community.


As a starting point, look at src/pubkey.cpp which is where the main code calls into libsecp256k1. If you need more specific information I suggest filing a GitHub ticket; it’s too specific a question to answer in full here.

[Edit: this was filed as ]


If I interpreted @jmsjsph’s question correctly, he was asking if changes to Zcash would impact whether someone could claim their YEC 1 – 10 years from now. But that’s probably still difficult to answer without the Ycash team.


@daira Does spending a shielded output on YCash chain and on ZCash chain reveal anything - given that both transactions have the same input?


Yes, it is revealed that the two transactions are spending the same input. Whether that’s significant depends on other factors. I would recommend making both transactions fully shielded, to minimize the leakage. It may also be helpful to spend both inputs at the same time (so as to not reveal that you were online at two different times).

Also see and subsequent comments.


Yes, even in this case it’s still a question for the Ycash community.


True, but suppose we ask the same question of Zcash: in 10 years, we will almost certainly have removed t-addresses, and/or have gone through one or more circuit upgrades that would motivate deprecating previous shielded circuits. (See for a discussion on policy about invalidating existing funds. Summary: no firm policy has been decided on for that yet, but there would be a lengthy warning period.)

Therefore, I think it’s likely that the Ycash team would have to explicitly do something different from following upstream Zcash in order for the forked YEC to still be claimable in 10 years.


Inside ECC we’ve agreed that we’d like to stop supporting taddrs. However, there are a lot of tasks that would need to be done first to minimize disruption to the ecosystem and community. Realistically it would probably take about two years, and that’s after we prioritised it as our top priority.

Also, removing support for taddrs isn’t a good way to get third parties (like exchanges and wallets and so forth) to add support for zaddrs. Instead we’re working hard right now to help such parties adding zaddr support — you’ve seen a couple of public announcements already, and stay tuned for more and more wins! :slight_smile:

(Oh, I see that Linda also posted an answer to this question. See her answer above, too!)

I predict that Scalable Zcash will not support taddrs, because of technical issues, and because the community doesn’t value endless taddr support highly enough that they want to endanger Scalable Zcash for taddrs. Adding requirements into Scalable Zcash increase the risk that it won’t work (at both technical and business/ecosystem/strategic levels), and adding non-requirements (e.g. “This will not support taddrs.”) increases the chances we’ll succeed.

By the way, I love the PRINCE proposal!

That proposal is to start phasing out taddrs now, not by a flag day “On this day it will stop being supported”, which requires massive effort throughout the ecosystem to prepare for, but by instituting a modest fee for using taddrs and a modest bonus for using zaddrs! If the community really wants to see a widespread shift from taddrs to zaddrs over the next couple of years, the PRINCE proposal is — in my opinion — a lot more likely to succeed at that than any other proposal I’ve seen. Somebody oughta ZIP that!

PRINCE would also reduce the disruption of the eventual “Waitaminute Scalable Zcash isn’t going to work with my taddr!?”.