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?
Would the future zcash bridge on polkadot increase zcash’s on-chain total payment volume?
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:
- 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).
- generally, try to work to improve shielded addresses instead of transparent
- stop (or at least be very cautious about --edit by Daira) improving unshielded transactions
- 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.
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 https://github.com/zcash/zcash/issues/4070 ]
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 https://github.com/zcash/zcash/issues/4007#issuecomment-500139142 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 https://github.com/zcash/zcash/issues/2718 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!
(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! https://www.reddit.com/r/zec/comments/c70fzz/privacy_proposal_for_zec_incentives/
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!?”.
What barriers remain for getting reference wallet stuff; lightwalletd/Android RPC fully tested and ready for main-net? Any timeline to expect?
It would be nice for the main repo to not have so many big s https://github.com/zcash/zcash-android-wallet-poc
Technically, we have done the work for the reference wallet to be compatible for mainnet transactions. We need to test it and do the remaining android work to expose this option in GUI form.
The lightwalletd has issues when blocks are out of order, and we’re working on the fixes to that now. Technically, you can stand up your own lightwalletd server at the moment, but it’s brittle and unreliable.
These two things are on the wallet team list of things to do, near the top priority! We have the lightwalletd set to be addressed this sprint, and mainnet more or less blocked on us setting up a CI/CD system. The reference wallet will be in a much better state in a couple months.
We just wanted to be clear about the state of things, and are generally an emoji-happy team.
Ycash people are here!
@hloo would you like to answer some of these questions?