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.
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.
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.
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.
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!
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.
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.
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.
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
That would require a “MUST-understand” Metadata Item, and so it would only work if we’d specified those from the start. As it is, it doesn’t work because existing UA Consumers won’t enforce MUST-understand Metadata Items.
[Edit: this is no longer true of the current ZIP 320 proposal proposal that relies on Revision 1 UAs. Those specify the MUST-understand requirement in such a way that existing Consumers won’t recognize the UA. So the current proposal uses exactly this idea.]
Update: We have received confirmation from Binance that we have successfully passed their compliance review and can proceed with implementing the new address type. Binance did not indicate a preference between the TEX Address and Traceable Unified Address options, so I’ve reached out to inquire about their position. If they do not express a preference, we will need to quickly decide which implementation approach to take.
I am going to schedule a meeting for early next week with Hanh, Kris, Daira, and Pacu to discuss implementation details and create a project plan. We also need to determine the most effective methods for coordinating with wallet developers, exchanges, and other relevant parties to ensure a smooth integration process. Following the meeting, I will update the community with our planned course of action.
When ZIP 316 was first specified, we made a mistake and essentially made all receiver types optional, which means that current wallets implementing ZIP 316 can ignore metadata items. The proposed change to ZIP 316 in ZIP 316: MUST-understand Metadata Items and Address Expiration Metadata by nuttycom · Pull Request #759 · zcash/zips · GitHub would fix that going forward, but existing wallets would ignore a flag that says “you must send only from transparent sources”. So, instead of doing that, we would have a new receiver type, and Traceable UAs would contain only a single receiver of that type. Existing wallets would then have nothing that they know how to send to, and would (ideally) alert their users that they need to be upgraded to support that.
When a wallet is upgraded to support the new receiver type, it will then know that, for that receiver type, it can only send from transparent sources.
If we go with TEX addresses instead, existing wallets will just say “This is not a valid Zcash address” which is confusing.
.