Edit 2024-01-15: the resulting ZIP 320 has been published (as a draft) and describes both the “new Bech32m HRP” and “new Unified Address Receiver” approaches.
I’ll be brave enough to ask one point that I don’t understand about this proposal. Please correct me if my reasoning is based on a wrong understanding of the solution.
It is supposed that there is a new type of address that looks like a QR code (or I misunderstood it), and it contains a transparent address and some signal (combination) for the wallet that it is a special address. The wallet recognizes this “signal” and does its job. I understood that technically it is realizable.
Well, we are talking here about wallets with shielding support. Let’s assume that YWallet, Zingo! wallets are ready to integrate this quite quickly. Then we have Nighthawk on the SDK and there won’t be a problem here either if ECC releases a patch.
What about other wallets? What about , Edge and Unstappble. Are they ready for this thing? What about wallets that only support transparent assets? What about hardware wallets and desktop wallets? Will they be able to read that special address or will they just give an error? I assume that the share of such wallets is disproportionately higher than mobile wallets.
I probably misunderstood this proposal, that’s why I’m asking.
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