Edge and Unstoppable are both built on the ECC SDK, so they’re in the same category as Nighthawk (and Zashi) with respect to this change. However, you’re correct that the hardware wallets, and other transparent-only wallets and exchanges, would need to update their address parsing code.
This is why I think it’s a good idea to choose Alternative 2 of ZIP 320, linked in my previous post; we should only ask these partners to upgrade once, to unified address parsing. This is exactly the sort of thing that unified addresses were intended to make easier.
Well, it seems to imply that wallet developers only need to update once to UA to get all the benefits.
To clarify, whenever there is an addition to the UA features, wallets have to upgrade. And it’s not only upgrading librustzcash, its API will likely change to accommodate the new features.
I find the amount of changes made to the librustzcash API troublesome.
Furthermore, I doubt that you will get the transparent wallet ecosystem to upgrade to UA because of Binance.
Edit:
Both solutions require transparent wallets to upgrade.
Option 1: Is less than 10 lines of code using standard crypto libraries (from Bitcoin)
Option 2: depends on librustzcash and has zcash specific crypto.
IMO, there is a higher chance of these multi-currency wallets choosing the simplest solution since zcash is unfortunately not a top 100 crypto anymore.
To clarify, whenever there is an addition to the UA features, wallets have to upgrade. And it’s not only upgrading librustzcash, its API will likely change to accommodate the new features.
Whenever any new feature is added, wallets have a choice whether or not to support that new feature. The point of Unified Address parsing is that wallets don’t have to upgrade to recognize a different address format as a valid Zcash address. Instead of returning a “Not a valid Zcash address” error, which is confusing for users, they can return an error that is more like “This is a valid Zcash address, but this wallet does not support sending to it.” This can be used as a prompt to upgrade the wallet to a version (or alternative) that does support that feature.
For example: numerous wallets have already upgraded to being able to parse Unified Addresses. Those wallets, on seeing a Traceable Unified Address from Binance, will report to their users that the address is a valid Zcash address, but not yet supported by the wallet. Instead of a user thinking that Binance has made some error, they can contact the wallet’s developer and ask that the wallet be updated.
The only change to the librustzcash API that would be required for this update is that the UnifiedAddress type in zcash_client_backend would be updated to have an additional TraceableAddress variant. Wallets upgrading to use this new zcash_client_backend version will need to choose what to do when they receive a request to send to a TraceableAddress; this is by design.
Thank you! Yes, definitely I know that Nighthawk, Edge and Unstoppable are built on the same base. However, since I do reviews for these wallets, I also know that their feature sets differ from each other and therefore I have the opinion that the SDK is something like a modular platform from which developers may or may not take certain functionality. For example, Unstoppable in its current form even on SDK2.0 does not support transparent addresses. Edge uses its own redundancy methods, etc. From all this I concluded that developers are somewhat free to implement and can simply refuse to use certain proposals.
Along with this, I saw a comment by Paul Puey somewhere on Twitter that he would recommend against indulgences for Binance and from interviews with him (which I’m translating for the blog) I know that his vision vector for Zcash looks like abandoning transparent addresses. So it’s not a clear-cut question about support for such functionality by all ecosystem participants.
It seems totally reasonable to me that if a wallet doesn’t support sending to transparent addresses at all, that they will also not support sending to this new address type, and that’s absolutely fine. Also, I think that it should be easier for a Zcash wallet and exchange ecosystem built around Unified Addresses to migrate away from the Bitcoin-derived transparent script model than it will be if address types continue to proliferate.
does this mean zcash is more of a base layer coin where we will have use cases for T and Z and users at the wallet level will decide how much functionality they want. if a user wants to stake and earn yield, they will use the T address; if they want to mint stablecoins they will use the Z address. or something like this? so the wallets decide what features to offer? in this case, if the wallet wants to let its users interact with a CEX they can whereas another wallet designed to be ultra private only allows Z to and from. Is this the right way to think about it? it’s a little confusing; maybe they need different names? treat them as different coins and charge a fee to transfer to and from the T address from a Zaddress.
Basically yes, that’s kinda how wallets work now. The core protocol has utility (T,Z,UA) addresses and they all technically work. It’s up to the wallet as to which types they support.
For example Edge wallet only supported Z addresses in the beginning, no T addresses at all. And others like Ywallet and Nighthawk Support both.
That’s still not figured yet. Once a good PoS staking/minting/spending is worked out we can figure out what address types are needed for what part. You could need T addresses for staking a node or something (so everyone knows you are holding what you say you are) but to keep Shielded Assets as private as possible the issue/send/burn could be done exclusively with private addresses.
seems like we are in a path to splitting zcash into 2 coins rather than geting rid of T. I think two coins which are sounding like they have defined use cases would be easier for people to understand and maybe unlock value
I thought of UA as a way to simplify zcash use, not making it more complicated. Instead of 2 addresses (z and t) only one (ua).
Now it seems like we have 3 and soon more. It has the opposite effect.
Why is that a requirement to get the functionality we need? The coins that are out there are all interchangeable, all coins are created equal.
So it’s really just up to us to define use cases, whether it be in transparent ledger format, or shielded format, or otherwise, it’s all possible on the same block chain.
it’s not a requirement at all. i think if they were separated, the value people assign to each would likely be different;'but it’s hard to tell at this point until the use cases are better defined
BTW - im not proposing a split. Its just starting to look like the T address might have a much different use case than the Z address. So Im wondering what happens as this evolves more…
I think it’s highly unlikely that staking will be implemented using any part of the transparent protocol. There’s no reason to use Bitcoin Script for this functionality; it’s very likely that instead staking will be shielded with zero-knowledge proofs of revealed amounts.
I’m not the right one to answer more detailed questions about this, but as far as I’m aware in NONE of the discussions thus far has use of taddrs in the staking protocol been even considered.
I have always advocated, and intend to continue to argue for the final PoS-based protocol to only support shielded addresses [*]. Obviously that depends on the existence of on-ramps and off-ramps for ZEC (and probably ZSAs) that don’t depend on t-addresses. It’s not a technical requirement to have t-addresses in order to be able to stake; from a protocol design point of view, you can quite easily base a staking protocol on proofs of balance. Economic and/or regulatory issues are a different matter, but I will still be arguing as strongly as I can that the transition to PoS is an opportunity to jettison transparent baggage.
[*] Shielded addresses are entirely compatible with selective transparency. Honestly we should never have made transparency a property of addresses in the first place; Bitcoin compatibility was in my opinion not worth the huge costs this has imposed on the Zcash protocol, code, and ecosystem.
That’s really not how it works. The balance property holds for the sum of four different pools (transparent, Sprout, Sapling, Orchard) on a per-transaction (modulo fees) and per-block basis. It doesn’t make a lot of sense to consider the pools to be different “coins”, since conversion between pools is completely implicit, and there is no balance preservation within each pool. The situation is much the same as having USD both in the form of cash and in your bank account; those are not different currencies. In fact, the Zcash pools arguably have more justification to be treated as a single currency than do USD-as-cash and USD-in-a-bank-account, because the conversion between pools is trustless and decentralised, rather than being mediated by centralised third parties subject to licensing (banks).
(BTW, if the ZSF proposals are accepted then it will be effectively five pools.)
would we still be able to audit the ZEC in circulation if we would go shielded only?
sorry for asking, but i have not seen an easy to understand text that explains that in detail.
btw, thanks for all the work that you have done for Zcash
Whether or not the protocol has t-addresses, it’s still possible for amounts transferred between pools to be revealed in order to audit the total pool balances. Those amounts are not associated with any visible address (in an otherwise fully shielded transaction, and without use of viewing keys).
Preserving auditability while keeping the amounts of transfers between pools private is possible in principle, using techniques from end-to-end verifiable election protocols as described in Private auditing of monetary base · Issue #2373 · zcash/zcash · GitHub . We don’t have a fully worked-out proposal for that so I would not expect the transition to PoS to block on it.
thanks for taking the time to explain this, @daira i appreciate that a lot!
would this mean that we have to migrate the funds to new shielded pools to audit the amounts of coins?
what if the shielded pool had 15M ZEC in it and an attacker counterfeited 15M coins and would move that to the new shielded pool? would that result in everyone loosing their ZEC because the attacker was the first to migrate these coins to the new pool?
i personally store most of my ZEC in the transparent pool mainly because of that, because having my ZEC stored there gives me some kind of insurance that i won’t be the one to loose my ZEC in case of someone finding a bug to counterfeit ZEC, is that a valid concern from your point of view ?
If by “everyone” you mean holders of funds in that shielded pool, yes, in the worst case. (It is possible that we would detect the exploit and be able to recommend a rollback, but that would depend on the specific kind of flaw.)
I am personally as confident as I reasonably can be that Zcash doesn’t have a counterfeiting flaw. The circuits and other code relied on for balance have been very thoroughly audited. The security argument for balance is well understood and has been repeatedly checked. Not finding the flaw in BCTV14 earlier than Ariel Gabizon did, was the result of BCTV14 not having an adequate and properly checked security proof, which doesn’t apply to Groth16 or Halo 2. (That flaw has been fully mitigated since Sapling activation.) The choices of cryptographic algorithms, curves, key lengths, etc. are solid. If you look at the types of balance flaws that have occurred in other coins, they are in areas where we have taken especial care (such as the 64-bit overflow in Bitcoin, or the key image bug in Monero and other CryptoNote-based coins), or they were due to software engineering practices far below the standard we consistently keep to (e.g. the balance flaw in Zcoin).
You wouldn’t directly be affected by the turnstile mechanism, but a counterfeiting bug that was being actively exploited would probably tank the coin price, despite the turnstile.
This issue wouldn’t stop me from keeping significant amounts of money in the shielded pool. Lack of shielded hardware wallet support does, unfortunately. But that’s due to skepticism about the security of general-purpose desktop computers and operating systems, not about the Zcash protocol.