I think we should heavily push the UA option then. Now’s the time 
3 Likes
If Binance chooses the TEX option I kind of think we should actually implement both proposals. I think it’s important that Unified Addresses be able to represent all the capabilities implied by all Zcash address types; if we didn’t also implement the UA change, then that would represent a more fundamental split of UAs from the rest of the ecosystem.
I’m also coming around to the idea now that UAs should be able to have just a transparent receiver, relaxing the original requirement for a shielded receiver. If that were the case, then any existing Zcash address could be directly reencoded as a UA.
3 Likes
Yes, it’s pretty clear that UAs are a tool for this job. At least to techie people.
What I mean is that this is far beyond a tech discussion. This is something else that came to my mind. Non tech people will probably decide like Julius Caesar to thumb up or down. It’s them (unfortunately for us) that we aim to convince, not programmers.
Let’s take this scenario into consideration.
given Laura Legal Department from Exchance B or Robert Regulator from goverment agency U are shown exchange addresses in any of both proposals, would they be able to tell them apart on the spot? Is that something they care about?
With “tex”:
If they see any Zcash address that exists today and a “tex” one side by side they are able to point out with their finger which one is the exchange address.
There is a hidden feature of “tex” addresses that I don’t see reflected on the ZIP: they are ostensibly visually recognizable.
UAs
In UA paradigm, this is an “anti-pattern”. (I know, I was there 
when we came up with this address design pattern)
We wanted to have one format for all receivers so users don’t have to care. The problem now is that Regulators DO seem to care about Zcash addresses and they are willing to disallow users to access Zcash in CEXs given their capabilities.
We need to find out whether that “ostensibly visually recognizable” feature is an implicit requirement for Binance/regulators or not. (at least for this time, tomorrow we don’t know)
If it’s not, then the UA approach should have no problems other than the process concerns raise in previous posts. Otherwise it might pose a problem in the immediate future if this takes us (and them) by surprise at the moment of approving or delisting.
I don’t agree with that, I think it would impose unnecessary complexity. It will be hard enough to get wallet support for one proposal.
1 Like
I don’t see why it would be [*]. If an exchange only gives out Transparent-source addresses, it has met its requirements regardless of whether users know that it’s a Transparent-source address or not. And the users have no particular reason to care: they’re functionally equivalent to a t-address, because the wallet will handle creating the extra transaction implicitly.
[*] I know, regulators aren’t necessarily coherent in their requests/demands. We’ll see when Binance responds to ZIP 320; there’s little point in speculating further before then.
6 Likes
very good, excellent explanation
According to Binance, the approach that ZEN is taking is to disable all Shielded → P2PKH transfers at the consensus level. Users will have to withdraw from shielded to a P2SH address (they suggest a 1-of-1 multisig) before then being able to send on to Binance’s P2PKH addresses.
As I’ve stated elsewhere, I don’t think that a protocol change is a good idea for Zcash. I’m surprised that ZEN is willing to go so far.
5 Likes
I respect your opinion very much. Although I already personally don’t believe that Binance will agree to the proposed solutions, but let’s at least try to keep liquidity for the whole world.
None of the listed exchanges are available to me. They are either technically not present or have simply rejected my attempts to register as if I’m a darknet monster, precisely because they already know about me being a Zcash maximalist.
Binance doesn’t do that to their users and that’s why they will most likely decide to delete all confidential blockchains. But it’s not about me at all, I know how to exchange ZEC for anything and will do it blindfolded anywhere in the world where there is internet, or send it from a secure pool to Binance from a client command line, whatever the technical decision is. There’s a lot people on forum. But we’re talking about the other millions of people who will lose even the hypothetical opportunity to invest their money in ZEC.
When the exchange tells me we can’t open an account for you, it’s no different than the banks and what Josh tells me in his interviews.
Similarly, I can say that we don’t need to support such exchanges. To hell with all exchanges in general! But we know that this world is even harsher. Even DEXs can come under pressure and ZEC won’t be on them either.
So it’s likely that people still won’t have Zcash in Iran, in Russia, in Afghanistan, and so on.
So either we try to conform and be flexible or Zcash will become a kind of best cryptocurrency for a select few Americans.
Did you know, for example, that many of the features in the Brave browser are not available in Russia? They really aren’t there and the regional lock-in is so strong that even if you change your country of residence, you still won’t get them.
5 Likes
I would prefer lose Binance than lose the idea of Zcash forever.
But in Horizen, this decision was not due to a demand from Binance. My guess is that it was most likely the demand of an invisible party with decision leverage, which we know holds decent bags of ZEN, for the purpose of to make Zcash more unique.
7 Likes
This should be etched in stone and part of our manifesto.
I think you speak for all of us 
.
7 Likes
I know it sounds a bit speculative. I don’t mean it that way. Since I don’t know if the people signing off will be even moderately technical I assume that the difference in human readable encoding might not be understood by the other side of the table.
We wouldn’t want to be in the place where they “suddenly” realize it was not what they thought it’d be, because the proposed solutions were not explicitly explaining that difference.
As @nuttycom pointed out, from the ZEN approach, it shouldn’t be
Probably is up to us to deliberate whether clarifying point this would be of any help or on the contrary it would bring more confusion. Sometimes that happens as well. Two parties agree on A and one of them innocently says “oh, btw A also something” and the other one says “oh, wait B what? We hadn’t said anything about B” and a mixup is created out of nothing.
So, I was actually thinking about this in implementation terms, and thinking “gee, it would be great if the only address type that librustzcash had to deal with internally was actually UnifiedAddress.” The zcash_address crate provides parsing logic for all of the publicly visible address encodings, but there’s really no need to propagate that internally if UnifiedAddress can represent the full possible range of address types. The change I’m suggesting here would simplify implementation, not make it more complex.
Ah, I didn’t have this context; if they’re deprecating their shielded functionality entirely, then sure, whatever, there’s no sensible comparison to be made here. Thanks for pointing that out!
3 Likes
It’s pretty nifty IMO. Binance would have
- the existing t-addr saved by users unused by z2t
- nothing changes on their side
- current t2t wallets still work
- shielded wallets would stop being able to deshield! But later they could do a trick where they bundle z2psh and psh2pkh in the same block.
Of course, it is still an ugly hack from a protocol point of view that would puzzle future generations.
6 Likes
We have already wasted too much resources, both money and time, chasing dead ends.
We do this for Binance, what’s the next rabbit we need to follow?
It’s all distraction. Zcash will be removed from Binance. Accept it. Only question remaining is what set of decisions we can make today that will enable us to properly celebrate our 10 years. By then we must be on our way up, towards something truly inspiring.
1 Like
Frankly I consider the complacent attitude from Horizen devs toward deprecating shielded transactions on their main chain (and, even before that, the fact that they never upgraded them from Sprout) as indicating that it was never a serious privacy coin. L2 privacy does not replace L1 privacy.
14 Likes
That’s true of the suggestion to allow UAs without shielded Receivers, but not of the suggestion to implement both tex and Traceable UA addresses.
1 Like
The way this would work is that after parsing, a TEX address would be represented as a Traceable Unified address internally. If addresses are maintained as ZcashAddress up until protocol addresses are required and the APIs discourage round-tripping, then there’s no real reason to have a separate internal representation of TEX addresses.
1 Like
IMO, the proposal to encode UA with a 4th type of receiver feels odd. Receivers represent a destination, aka where the funds go to. Here, we are not introducing a new type, we are restricting where the funds come from. These are orthogonal ideas.
It seems that you could keep the existing 3 receivers and introduce a new metadata entry “pool exclusion bit flag” which, if present, indicates that the transaction must not take funds from specified pools.
Then you could have, at no additional dev cost, addresses that are for example “orchard only” (only o → o allowed).
PS: I still prefer the TEX encoding for Binance approval as it is the simplest to bring to production.
3 Likes
Having a pool exclusion flag would be useful to a receiver. A wallet couldn’t prevent t=>o at a protocol level though it could make the sender have to read a popup and confirm they know it is against the receivers intent
1 Like