7 Likes
It is neat because of the forward camptibility and that some users are just hopeless or even donât want to know about any technical aspects and that shouldnât be an excluding factor to be able to adequately use Zcash but it doesnât alleviate the need for some users to at least have a modicum of understanding about underlying value pools so as a âcomplimentary featureâ it sounds great but âno more native addressesâ seems excessive
1 Like
Great video. One small criticism though: I think âbackward compatibilityâ is a better word than âfuture-proofâ.
Your current UA will continue to be supported in future wallets but to benefit from future advances in crypto, you will need to upgrade your UA.
1 Like
Great job on simplifying Unified Addresses!
Thatâs the whole point of UA, you never need to change your address which makes it future proof! As this is where the autoshielding/sending ZEC to the most-recent-supported-pool-on-client happens.
Thatâs not correct. The autoshielding happens when you upgrade your UA in a more recent wallet.
Suppose that UA were released before halo. Your UA would include (yellow) transparent and (green) sapling (I donât know why they omitted sprout in the video).
Now (blue) orchard addresses are invented but you donât change your UA address.
You give your UA to a new wallet. This wallet cannot auto migrate your coins since your UA does not include a blue address. Therefore you need to change your UA address if you want to have the latest feature.
The plan is to release UA after orchard.
And as far as I understand, the UA doesnât need to know your new shielded address as your client will identify both UA and the latest shielded pool(post orchard) and the client will make the auto shielding, transferring ZEC from UA based transparent/shielded pool to the post orchard pool address. But this is way in the future, for now, the 3 in 1 UA should be the standard for a long time.
Yeah. I said âSuppose that UA were released before haloââŚ
How can it be possible? The client does not know your post orchard pool address since you donât have one yet. It can regenerate one but thatâs a new UA: Same format but new content.
Right, but this is like saying âitâs future proof for a long timeâ. For me, future proof means âgood as long as zcash existsâ not âgood as long as it remains the sameâ.
The fact that there is so much confusion around this feature is not a good sign. âUniversalâ comes with some expectations. Iâm afraid this expectations arenât going to be met and it will lead to disappointment from users. I think they should have called it âaddress cardâ because it sounds like a âbusiness cardâ.
A business card contains several contact info, i.e. home phone, work phone, email, fax, etc. A person who wants to reach you will chose the best method based on what technology he has available. Itâs pretty much the same with the UA.
3 Likes
This is very interesting. Zcash is always improving and implementing cryptography with secure, professional-grade code.
How does this effect Sprout coins?
How does UA actually work (receivers) and UX implications
Hello,
Iâm unable to understand how the UA address type actually works (and unable to create a new topic on the forum).
UA can have one or more receivers (Transparent, Sapling, Orchard, future ones, etc).
-
how does the wallet or protocol know which receiver to use from the address? Itâs not visibly recognizable if the UA supports only transparent (equivalent to t-address) or (transparent + sapling + orchard, for example).
-
Is there any protocol implicit receiver type that is used if more than one receivers are used by the UA?
-
Can I choose from my wallet, which receiver to of recipipients wallet to use?
-
if I want to have an UA that supports only the latest, most advanced shielded pool (this time Orchard, in the future the next shielded pool iteration), does it mean that I have to generate a new UA in the future?
Thank you so much!
Tbh, this is very poorly explained when you try to read about UAs, how it technically actually works and its UX implications. @ZecHub something to definitely work on! 
1 Like
@hanh might be an expert on this after reading the forum, from the implementation perspective.
Bonus question: if I use someoneâs UA to send them shielded funds (they use shielded receiver like sapling or orchard), does it also hide the UA from the blockchain explorer? If I send something to UA with only transparent receiver, it will be obviously visible in the explorer i guess.
My bad, I forgot that Zcash is actually excellent and one of very few cases in the whole crypto, that it provides its full protocol specification, so according to https://zips.z.cash/protocol/nu5.pdf#unifiedpaymentaddrencoding and ZIP 316: Unified Addresses and Unified Viewing Keys I was able to understand it.
Brilliant.
(using a different account, because this forum doesnât allow me to post more than 3 replies in the same topic)
2 Likes
From ywallet you can choose which receivers to display:
There are subtle differences visually as discussed here:
https://zechub.wiki/guides/visualizing-zcash-addresses
If using zcashd, you can build the receiver you want as discussed in our full node guide:
https://zechub.wiki/guides/raspberry-pi-4-full-node
If you need to use a particular pool, ywallet has a neat feature:
note: ywallet has been updated but this feature is still available.
If you choose a receiver without transparent support, then everything will stay shielded except if you send funds from Sapling => Orchard or vice-versa because of the turnstile.
For each shielded value pool (see above), there exists a turnstile which can calculate the expected amount of ZEC held in it. Since ZEC must be mined to a transparent address before being sent to any shielded address, the value entering either the Sprout or Sapling value pools is visible. Similarly, because ZEC cannot be sent directly between shielded value pools without revealing the amount (see: Sprout-to-Sapling Migration), the value exiting a shielded value pool is also visible. This allows for publicly tracking the total value held by shielded pools without having the ability to know individual shielded address balances.
Great questions!
3 Likes
For any given unified address, you can use the the z_listunifiedreceivers command to see them and then select which one to manually send to if you wanted. This function is available in the zcashblockexplorer (at least for the next couple of weeks).
With Ywallet you can select the you receivers that get sent âfromâ and sent âtoâ by selecting your available funds to spend from and also your privacy policy.
For example, if you only wanted to spend your sapling notes to a FULL UA sapling reciever, you would set your privacy policy to very high, deselect your transparent and orchard funds on the tx screen and that will force the wallet to select the same pool to send to.
With the privacy policy set to very high then the wallet will be initially prevented from making a partially shield transaction which is one that crosses pools between orchard and sapling ( Itâs actually kind of negates the need to deselect transparent and orchard notes. But with them deactivated, you could potentially do a send max and it wouldnt mess it up at all). This way, you could potentially know whether or not the address contains one receiver or another even though you canât specifically tell just by looking at it. The byte length of the UA address does change with receiver count but, you know, weâre not robots!
The default behavior for auto receiver selection e.g if you didnât manually select the receiver or rely on privacy policy, can vary somewhat from wallet to wallet, but overall, it will generally pick either orchard always or the best shielded receiver available by default.
Yes, shielded addresses do not appear on the block chain in any way. What I mean by using zcashblockexplorer to find the receiver is that it implements a function that, when you paste the UA in the box, it shows you the receivers. With a full UA, one is transparent and may have history. The other two are shielded addresses and canât actually be correlated to any history from there.
3 Likes