2.1% of the world population - the other 97.9% really don’t care.
Having a Binance account doesn’t mean you trust them, I certainly don’t.
2.1% of the world population - the other 97.9% really don’t care.
Having a Binance account doesn’t mean you trust them, I certainly don’t.
Why would you count towards the inhabitants of the planet when you can count towards all living things on the planet. But in reality 170 million is the majority of all people who have cryptocurrencies at all.
The scenarios I’m worried about are:
Binance displays a T2 addr to the user. The user sends funds to that address, then looks up the transaction in a block explorer; it shows that they sent the funds to a different regular T-addr! The user thinks they’ve been scammed!
Basically the same scenario as (1), but this time the problem is that the use of multiple encodings causes confusion inside of Binance. Sure, it’s a problem of their own making, but it still can result in lousy outcomes for users.
There is no way to fully hide the underlying T-address from the user; for example, after wallet recovery, the user’s history will show the recipient as the T-addr, not the T2-addr.
None of these are definite showstoppers, but they absolutely add friction and potential confusion to the user experience. Ultimately using a different encoding for the address is little different from defining a ‘req-transparent-sources-only’ flag for ZIP-321 requests (I think you suggested something like this already?) but IIUC Binance though that approach wasn’t sufficient?
This is interesting, using some sort of P2SH “smart contract” for Binance deposits would require the wallets to understand that contract and therefore know how to satisfy Binance’s requirements.
it turns the problem inside out.
from: how can {any virtual asset service provider} be sure the funds they accept are not tainted?
To: How do users know if they send funds to {any vasp} they will be able to retreive their funds if the counterparty’s latest requirements does not approve?
using trustless P2sh escrow improves the experince for both sides
Thinking about our tiny, unknown project in the context of the World Population is hilarious. It doesn’t bring any value to this discussion.
Since either side would have the ability to retreive the funds, the p2sh address can be shared using a regular zip-321 payment uri qr.
User impact: Wallets could recognize a qr as a p2sh contract, create the appropriate funding tx transactions, and possibly start an internal timer to get the funds back if you want to get fancy.
Vasp impact: get addr funds will come from, modify qr deposit address generator to add a uuid & addr to p2sh, monitor the address, add a hook to the end of analytics workflow to publish the preimage and sweep funds
Network impact: none t3 address supported already
This discussion needs to stay technical. The clock is counting down!
Right, though I would say these issues arise when the protocol does not know about the receivers.
In fact, I have run into similar cases with unified addresses. For example, matching the address of a contact with the receiver of a note isn’t easy.
If the protocol is updated, I think it will cause even more confusion because block explorers will not understand the new address format.
Indeed, it was rejected because it was not preventing users from paying the address directly.
Can we estimate this somehow? It’d be great to get some data to inform the conversation.
As a rough estimate, I think that @hanh’s proposal and the P2SH proposal are both achievable in the requested timeframe for some subset of the wallets; we’d need to find out whether Binance would need zcashd wallet support, which would be the biggest pain.
Protocol-level changes are almost certainly not workable within the desired timeframe without triggering a chain-fork; it takes 16 weeks for nodes to EOS-halt and normally we want to have all of the zcashd and zebrad releases supporting the pre-upgrade set of network rules already beyond their EOS height before the new rules take effect.
I meant estimate the impact on the price. If we don’t play ball with Binance, what’s the estimated cost? Benefit?
Impossible to know. Last time Zcash/Monero were removed from a major exchange (Bittrex) was January 15, 2021 and you can see how that played out…
Hello everyone. Long time Zcash holder but first time I write here (I come from Telegram). I would like to bring a fresh point of view from someone who is also invested in other coins, following the entire crypto market closely and not so much in a “Zcash bubble”.
Bullish? How many coins have you seen going up in price after being delisted from Binance?
No… there’s no way it’s fully priced in because it’s still uncertain if it’s gonna happen or not, and many investors don’t even know about it yet.
A Binance delisting WILL be really bad to the ZEC price, and Zcash survival depends on the token price because the developers are getting paid with tokens. On top of that, timing couldn’t be worse… because the token price is already in all-time lows. If other CEXes follow Binance, the risk of death is very real. Whatever happens with Binance now can set a precedent for many other CEXes in the near future.
I personally see this situation as a blessing in disguise. Monero is biggest Zcash competition and Monero didn’t comply with Binance because they don’t even have that option. Someone here thinks that Monero doesn’t care about being delisted from CEXes? For Monero it’s impossible to comply due to the way it’s designed. For Zcash however it’s the total opposite. Zcash is designed with transparent addresses and shielded addresses and one of the biggest advantages of this design is for easier compliance with regulators and Centralized Exchanges.
What Binance is asking for seems to me relatively easy to implement for Zcash precisely because it already has transparent addresses! This should be possible to do comfortably between the timeframe, and it’s a golden opportunity for Zcash to get ahead of the competition! This is what Zcash was designed for.
And the most important thing… these changes are not going to compromise users privacy in any way.
Regulators usually move slowly. I agree they could ask for more in the future but when? It could be in 2-3 years or even 5 years or more. Who knows? And in that time we have the opportunity to move to PoS, get listed in DEXes, become more popular, recover the price, and survive Binance delisting without a sweat.
I think Zcash best move here is to try to comply with Binance. It’s just the smartest move with highest chances for Zcash to succeed long term IMO.
A few points.
Getting delisted from Binance will crash Zcash.
The community isnt ready for a Binance delisting.
Most non KYC exchanges use Binance backend.
Other Centralized Exchanges may require an Exchange Address in the near future
An Exchange t address MUST be different than a regular t address by adding a prefix (like Firo added ‘ex’, perhaps ‘tex’)
That chart has an exchange I have never heard of “YoBit” with 50% of ZEC trading volume and almost no order book depth. I am pretty sure they are pumping up their trading volumes, so I would double that 15% to probably 30%.
Agreed. That’s why I included a footnote at the end of the OP. Binance’s percentage of total trading volume is likely significantly higher than 15%. YoBit is a Russian exchange. I asked @artkor about it a couple months ago. He might be able to shed some light on their abnormally high trading volume.
Welcome! And thank you for your valuable insight
If you send to a p2sh address but you were not involved in the creation of the address, you are not gonna be able to retrieve the funds because you don’t have the redeem script.
In any case, the problem is that Binance does not want to take any return t-address. AFAIK, they want the address where the funds came from.
I think it’s doable but yet a tight schedule given the many parties involved and the different priorities they manage in their backlogs
Also testing and integration will eat a chunk of time