Sorry, it’s a problem with my English. Of course I brought this up for everyone and would like Jack to give a public answer because he seemed to say at ZCON4 that our problem is ZEC-shorts.
1 Like
regulation is intensifying.
1 Like
Leaving the exchanges with the largest volumes and liquidity is NEVER good for the price of a token. Any experienced trader knows that.
Also I can tell you that people shorting are not the cause of a token falling in price for years. People shorting only provoke downwards pressure when they open their shorts, and then provoke upwards pressure when they close their shorts. In the long term both longers and shorters do nothing for the price. These are only short term fluctuations.
5 Likes
FYI:
I’ve left comments signaling part of ZIP-315 draft that would be affected by implementing the “exchange addresses”
Even though the ZIP is a draft I think is the best place to check the impact on wallet implementations that “solution” would have
3 Likes
Update: Last night, @nuttycom, @hanh, and I had a call with Binance to discuss Hanh’s proposed exchange address solution. The conversation primarily addressed Binance’s technical questions, and, in the end, they ultimately signed off on the proposal from a technical standpoint. Unfortunately, they have postponed the go-ahead for development until they complete a compliance review of all privacy coins on their platform. By the sounds of it, Binance plans to evaluate the discussions they’ve had with various privacy coin projects, whether they plan to adhere to Binance’s requests, and then potentially delist some coins based on this review. If we pass the compliance review, we will have the green light to start development. Binance has also indicated that they will be flexible regarding the February 29 deadline they previously quoted.
At this point, we have done everything possible to cooperate with Binance to prevent delisting. If we fail the compliance review, it will be due to Binance taking a hardline stance against privacy coins, and not a lack of a viable proposal from our side. We expect to receive a final decision by the end of next week, January 19. I will provide the community an update as soon as new information is available.
I want to thank @nuttycom, @joshs, and @reubenyap for their advice, guidance, and support over the past few months. This issue has been challenging to work on, and their assistance has been instrumental and is greatly appreciated.
I also want to express profound gratitude to @hanh. It is no coincidence that the two solutions Binance found most compelling were both proposed by Hanh. Hanh is an exceptionally capable developer with a sophisticated understanding of the Zcash protocol. We are very fortunate to have someone of his caliber in our community. Thank you, Hanh!
50 Likes
Thank you all for the great work you do!
13 Likes
Something that came up on the Arborist call today is that it might be desirable to fit the new address type into the framework of unified addresses. This would require relaxing the rule on unified addresses being required to include a shielded receiver, however, I think it might be a good idea to do it this way:
Add a new Unified address receiver type, 0x04, for transparent exchange addresses, and require that a unified address either contain a shielded receiver type, or have only a transparent exchange receiver.
@hanh @daira what do you think?
One real advantage is that wallets with unified address parsing implemented will fail gracefully when reading a tex-only UA.
13 Likes
@hanh public Z-address? I’m interested in tipping you for your profound contributions in this effort, and for so many past efforts that served as life boats for the Zcash ecosystem!
Congrats and Cheers to all for thoughts/ energies invested in this Binance saga.
2 Likes
@aquietinvestor, thank you for your leadership, thoughtfulness and proactive engagement with Binance and across the community.
20 Likes
thank you!
4 Likes
i was a silent reader on this forum for a long time and just opened an account to thank @aquietinvestor @hanh and everyone else for what you do.
after years of pain in the community, one can finally see the change that was long needed.
keep up the great work guys
19 Likes
Thanks @aquietinvestor for leading this and of course to @hanh for coming up with these clever workarounds.
12 Likes
Thank you for your hard work!
7 Likes
Great work 
7 Likes
Thank you @aquietinvestor for taking ownership of this matter. Forever grateful 
.
@hanh you’re a legend. We’re lucky to have you on our side .
8 Likes
thank you!
3 Likes
(As ZIP Editor.) I’ve assigned ZIP number 320 for a specification based on hanh’s proposal: ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses
(Taking off ZIP Editor hat.) @nuttycom and I will work on writing that up. We are currently intending to use a Unified Address Receiver type rather than a new Bech32m HRP. This has the advantage that it will be possible to associate an expiration height or time with the address, as specified in ZIP 316: MUST-understand Metadata Items and Address Expiration Metadata by nuttycom · Pull Request #759 · zcash/zips · GitHub.
Edit 2024-01-15: the resulting ZIP 320 has been published (as a draft) and describes both the “new Bech32m HRP” and “new Unified Address Receiver” approaches.
19 Likes
To clarify, we only discussed the alternative 1 (Bech32 HRP - tex) with Binance.
10 Likes
With @daira’s help, I have put together a ZIP that presents two alternatives for how to do this encoding: ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses. An analysis at of the benefits and drawbacks of each choice is provided at the bottom of the document.
Please review and provide feedback!
10 Likes
I’ll be brave enough to ask one point that I don’t understand about this proposal. Please correct me if my reasoning is based on a wrong understanding of the solution.
It is supposed that there is a new type of address that looks like a QR code (or I misunderstood it), and it contains a transparent address and some signal (combination) for the wallet that it is a special address. The wallet recognizes this “signal” and does its job. I understood that technically it is realizable.
Well, we are talking here about wallets with shielding support. Let’s assume that YWallet, Zingo! wallets are ready to integrate this quite quickly. Then we have Nighthawk on the SDK and there won’t be a problem here either if ECC releases a patch.
What about other wallets? What about , Edge and Unstappble. Are they ready for this thing? What about wallets that only support transparent assets? What about hardware wallets and desktop wallets? Will they be able to read that special address or will they just give an error? I assume that the share of such wallets is disproportionately higher than mobile wallets.
I probably misunderstood this proposal, that’s why I’m asking.
1 Like