A Binance delisting would be a significant loss. It’d hurt.
BUT I don’t think we should make any protocol changes to kowtow to the whims of an exchange that is now effectively owned by US financial powers. It’s my belief that we are here to build a different system, a different choice, one free from coercion and subjugation.
I love that people like @hanh are brainstorming different mechanisms for supporting Binance in order to forestall delisting without changing the protocol itself. Access and liquidity are good because they support choice. But we musn’t sell out our mission or compromise our values.
And we all know necessity is the mother of invention. So, the sooner this band-aid gets ripped off by these suits who are attempting to commandeer entire crypto communities with their legislation and money (power), the more likely an even better decentralized (private) exchange comes along. And I’d definitely be willing to help build such a thing once ZSAs get traction.
Hanhs solution is novel and he has my upmost respect (yall should watch the video, it’s really good). But short of implementing that on the protocol level, it would not prevent sending to binance addresses which, while the mica requirements are under defined, in my opinion, do specifically use the words shall prevent. Secondly, it doesn’t do anything about the transaction history tracability, whatever you assume the minimum requirements might be for that. Logically, you can assume that the maximum possibly imposed requirements would be the maximum amount of information you could possibly provide i.e. complete history traceability from a plaintext public record. It works for Bitcoin but not for here. It’s actually like the whole reason this project really even exists.
Then, I nominate you for the scribe in this thread.
Joking aside, I agree with the discussion becoming quite murky.
Side note: Why doesn’t Zcap function more like a listserv where these updates are broadcast to a much wider audience?
I think the community is fragmented in too many places (here, discord, X, Telegram), and Discourse may not be the most effective way to communicate and get the community fired up.
At the very least, use the @zcash X account to publicly reply instead of relying on zooko to do so. I mean this is the last thing that was posted:
No offense to ZecHub but that’s a good handle to not utilize more effectively right now.
Based on my conversations with Binance, their concern is that they are unable to identify the immediate source of funds when receiving deposits from a shielded address. For example, they cannot determine if the funds come from a country or individual sanctioned by OFAC. There is certainly no guarantee that Binance won’t impose more restrictive transfer limitations in the future. However, given that Hanh’s proposal does not require a change to the protocol and is relatively easy to implement, I think it’s a solution worth exploring.
People here puffing up the idea that Zcash can out live a Binance Delisting have been drinking too much kool-aid
In a hypothetical world, where Zcash wasn’t reliant on the value of ZEC, perhaps we could outlive the massive negative consequences of a Binance delisting, but in the real world of today, we can’t.
Wasn’t one of the most driving factors for Halo, to make the Zcash protocol more capable of upgrading on shorter cycles?
Just for clarity, Halo2 allows us to make upgrades to the ZK circuit without having to perform a new trusted setup ceremony. So for example, the upgrade to adopt ZSAs can be made in a normal hard-forking upgrade. This doesn’t have a lot of relevance to changing purely-transparent parts of the protocol.
The issue with protocol-enforced “super transparent” addresses, as I see it, is that the “super transparent” concept solves a made-up problem: if a user transfers balance from their shielded pool to a fresh transparent address, and then transfers that balance to a “super transparent” Binance address, the only thing that Binance has gained is the ability to return funds to the originating transparent address. That’s a very small gain, and @hanh’s proposal provides the same benefits at a much lower cost.
Protocol upgrades aren’t cheap; there’s implementation complexity and risk involved in any change to the consensus rules, and then there are all the knock-on effects on the wallet ecosystem, where wallets must update to accommodate new transaction formats. I mean, heck, the problems with Ledger hardware wallets today exist because as far as I’m able to tell, Ledger never implemented support for the V5 transaction format (or at least not V5 transaction signatures, it’s hard to tell.) If Zcash developers are spending time implementing this sort of feature (which regulators might come back and say is inadequate anyway) then that takes time away from working on everything else that needs to be done.
Privacy is a fundamental human right, but just as importantly you can’t actually run an economy on a fully-transparent coin where everyone’s paycheck, every business supply chain payment, every doctor’s visit is ultimately public information; you can’t run an economy on a chain where miners or notaries can arbitrarily discriminate against certain transactions. I want zcash to be the chain that the economy runs on; we’re the only one with the features needed to actually make that happen.
Binance wants to have a way to know where funds come from.
z2t transfers do not allow that. Binance asks for a way to restrict their deposits to t2t.
In other words:
t → t : GOOD
z → t : BAD
z → t → t : ALSO GOOD!
They don’t care about the previous transaction history. Therefore your privacy is unchanged. Just unshield before depositing.
Exchange taddreses would indicate to wallets that they must not use shielded notes as inputs
But they don’t force you to always use t-addresses.
What’s the point of exchange t addresses if they don’t force you to reveal your whole transaction history?
Binance needs an easy way to refuse incoming funds. With an exchange t address, the source has to be transparent and therefore it provides a return address.
They don’t care about your transaction history.
That’s what they say but mark my words, it will come to that.
That could very well be. But that’s not the purpose of this thread.
I suggest that we split this thread and continue the general discussion about how CEX and privacy in its own thread.
So are we 100% certain that they only care about one last transaction prior to receiving at the Exchange?
For example:
Z → Exchange = fail
Z → T → Exchange = accepted
T → T → Exchange = accepted
Z → T → Z → Z → T → Exchange = accepted
If so, then this whole thing is a moot point.
Generate a T address, allow the user to somehow mark “This T address is to send to exchanges” in the UX. Then fund that T address via any method, and your good.
It occurs to me that the t2-addr proposal has one significant drawback, which is that the generated t2-addrs will not be something that’s visible to block explorers, or indeed to the recipient of a transaction. There’s a UX challenge (perhaps soluble?) that is, if Binance is using the zcashd (or another Bitcoin-derived) transparent wallet, even if they generate t2-addrs, the rest of their infrastructure will also need to be modified to interpret regular transparent addresses read from the chain in terms of the new encoding.
@aquietinvestor what degree of certainty do we have on this t2 solution achieving the goal of avoiding delisting from Binance?
If we implement it, I think we should also plan an unroll roadmap so that we can deprecate T1 and t2. I liked the idea of @jelly5649 about deprecating t on some date. I’d rather it be sooner
the t2 accounts do solve a problem for binance. it does nothing for the user, aside from cause confusion. Given that wallet implementations have been zcash Achilles heal, It could lead to the same type of trouble ux where some work, some dont, and users find out after coins are stuck.
Couldn’t an exchange use a htlc for deposits instead of a t2? lock deposit with htlc > share preimage with exchange > exchange verifies it was t2t & tx history and claims or the user gets coins back at T
Changes required would be at the wallet UX layer only, exchange claiming logic, and (best) no impact to network participants(indexers, block explorers, apps, etc), no risk of spam attacks on t2 addresses
There is absolutely no guarantee that the t2 solution will prevent Binance from delisting ZEC. While Hanh’s proposal appears promising, and Binance is willing to consider alternative solutions, it is unclear how Binance will respond to this specific proposal. There is always the possibility that they may not accept it or may raise concerns that could lead to its rejection. Given that this solution doesn’t require a change to the protocol and is relatively straightforward to implement, it is worth proposing.
