This is something that remains unclear to me. A guaranteed return address is the only thing that Binance would actually get from any “transparent-transfers-only” address; while they’d get one step of visibility, that’s all, and so I don’t see how the “address the funds came from” is meaningful; we’d implement this as a single-use address where the wallet de-shields the funds to a new taddr and then immediately spends those sending to the t2addr, so there wouldn’t be any meaningful information exposed about the original source of funds - all that this would provide is really a guaranteed return address.
If what Binance actually wants is full transparency of history, then basically we’re stuck with delisting IMO, because there’s no version of Zcash where history is fully transparent; that’s Bitcoin. But what the actual requirement is has never been made perfectly clear to me.
I agree that it’s not meaningful, but it’s what Binance is asking for. They want to prevent deposits to the exchange from shielded addresses. They have never said anything about full transparency of transaction history.
Reuben Yap from Firo was in Telegram today talking about the solution they’ve implemented to avoid being delisted from Binance. It’s a protocol change that still allows users to go from z>t>t.
This is a complicated question. On the one hand I really wouldn’t trust the numbers on Yobit, because even though this exchange has been around longer than Binance, it has a very questionable reputation due to the large number of negative reviews in the past (probably fictitious but they were). As in any other country all sensible adults with money prefer to use large international exchanges. On the other hand, this exchange has always been very active in advertising its services on all existing platforms and is very popular among newcomers. For example, during the ICO boom, they listed literally all the projects in a row very first, even before the official distribution of tokens. It was impossible to withdraw them to your wallet and it is clear that they just sold empty tokens, which were then bought out of the market. There were also other strange attractions for user that are unacceptable for exchanges with a strong name. But it is very difficult for me to assess the impact of newcomers on the market. And an important factor is that the exchange operates without KYC at all. I will give you a screen with daily volumes, which the exchange indicates right now on its platform. As you can see all the main volumes are in pairs with BTC.
Additionally, I would like to note that yesterday Binance sent out letters to all Russian users about withdrawal of funds until December 29 inclusive, that is, today is the last day of the exchange’s work in Russia.
The new exchange, to which Binance urges to transfer assets (Commex), still does not support Zcash. Subjectively by talking to different people, I think that today the leaders in getting users is Bybit, Kucoin, OKX.
One more important point that I can’t understand is why during all these news about the withdrawal, delisting of Zcash in Europe, problems in the US on ZEC balance of Binance cold wallet coins continue to accumulate. And now it’s already 2.2 million ZEC. I’m beginning to suspect that the lion’s share of these coins belongs to the exchange itself. And these are the coins that were sold by users amid all the negativity over the past year and a half. I constantly monitor metrics with large addresses. At the end of 2021, there were less than 300K coins at this address.
is it easier for the average user change exchanges? maybe a fourth party to exchange zcash for bitcoin before trading for fiat?
or is it easier for the community of zcash programmers to create a solution that works for everybody in the room
we dont need ~binance~. but if this is all it takes to satisfy these big actors for a couple years, it might be a good deal to take
The setup coordination is the tricky part of htlcs. p2sh with only a hash lock would be an option also; if both sides know the hash. It wouldnt prevent someone from sending that address coins from a sheilded address, it would give an exchange the optionailty of not having to accept a deposit. All coins are shielded at least once so its always a losing game if full transparency is what one wants.
In any case, Binance and the rest of the exchanges want to operate in the regulated world. It gives the chance to move from being a casino to a financial institution. All of these exchanges will be delisting privacy coins to keep operations. They will all have their own interpretation of what the think some regulation means. The challenge isn’t strictly a technology problem.
I as a user, would also like the option of not accepting coins (or zsa’s) that I dont know the origin of or may not want. having the ability to generate htlcs and hashlocks in a user friendly way would help when i am interacting with strangers. If i post a UA on my website, there is nothing which would prevent a bad actor to send anything they want to that address, same with my Home address. Anyone could order illigal substances and have them sent to my mail box. If i do not want the item I do not take it out of my mail box or, in the case of zec, i would not move it to my real account. UA’s already support a p2sh or p2pk addr as the transparent address. This will give the opportunity to both parties to participate in the offer, consideration, acceptance of assets and maintain mutuality of obligation.
Well… I understand what you want but it is not like you can post a p2sh address that can return funds to any sender after a certain time. At least I can’t see how to make one like that.
So I don’t see how they would help you.
I can’t trustlessly post a p2sh address that can return funds to any sender. Not having a communication round to exchange to preshare the address would mean that we wouldn’t be able to do predefine a withdraw pubkey. A second hash could be used as a lock on the timer, obvs less secure than an address. The script and preimage could be shared using a payment uri message field or only shared if the exchange wants to reject the coins. Its been a long time since i did any bitcoin scripting , it could be done something like this though
[vars]
<redeemerAddress> - address who can claim coins from exchange, would be known by script creator
<redeemBlockNumber> - block after which the coins can be moved with preimage 2
<preimage1> - used by party A to claim the tokens
<preimage2> - used to redeem the tokens by partyB
TX presented as [<constants>] [redeemscript]
case 1 - exchange will accept coins
[<signatureA> <pubkeyA> <preimage1>] [script]
case 2 - the time has elapsed and partyb can withdraw (set nLockTime)
[<signatureB> <pubkeyB> <preimage2> ] [script]
[script]
op_sha256 <commitment1> op_equal
if
op_dup
op_hash160
<redeemerAddress>
op_equalVerify
op_Checksig
else
<redeemBlockNumber>
op_CheckLockTimeVerify
op_drop
op_sha256
<commitment2>
op_equalVerify
op_Checksig
endif ```
Well, you have pubkeyA and pubkeyB. If pubkeyB is chosen by sender, the script is not predetermined.
If pubkeyB is chosen by receiver, then what’s the difference vs
using a normal address.
If the receiver doesn’t want to keep the coins, he sends it to another address and gives its secret key to the sender.
Hi, first time posting, wanted to provide an outside perspective. I see a lot of highly technical discussions, which is great but I don’t think any proposal will satisfy the time frame. Hence my proposed solution:
Mint x-amount of ZEC ERC-20 tokens
Softlock x-amount of ZEC tokens on ZCash
Total supply remains the same
Ask Binance to swap all user ZEC for ZEC ERC-20. This solves their regulatory concerns, and ensures ZEC listing and ongoing conversations with Binance in the mid to long term when a more technically advanced solution can be rolled out.
Next steps:
5. Get any other centralised exchanges that already list ZEC to also list ZEC ERC-20. They are now defacto centralised bridges. ZEC users can move funds from Binance to said exchange and bridge back and forth.
Mid to long term.
6. Invest in cross-chain, atomic-swap, DEX infrastructure to be able to move ZEC to ZEC ERC-20 without centralised party interference.
Additional benefits:
Investors can now use HW solutions to store their ZEC (albeit ERC-20) investment
Why step 2 softlock? Because you want to have the ability to remove support for ERC-20 later, and get everyone back into ZEC ecosystem exclusively. The actual implementation of softlock tbd.
Additional concerns: don’t underestimate how hard it will be to become re-listed once ZEC is delisted. Binance is likely making these demands to satisfy regulators, so from an optics perspective: ZEC solved concerns, we keep listing is a lot easier message than: we delisted to comply with regulator demands and then months (years) later tell the regulator you want to relist it because of a highly technical solution that’s supposedly compliant.
