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?
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.
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.
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.
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).
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.
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!?”.