Whether or not the protocol has t-addresses, it’s still possible for amounts transferred between pools to be revealed in order to audit the total pool balances. Those amounts are not associated with any visible address (in an otherwise fully shielded transaction, and without use of viewing keys).
Preserving auditability while keeping the amounts of transfers between pools private is possible in principle, using techniques from end-to-end verifiable election protocols as described in Private auditing of monetary base · Issue #2373 · zcash/zcash · GitHub . We don’t have a fully worked-out proposal for that so I would not expect the transition to PoS to block on it.
thanks for taking the time to explain this, @daira i appreciate that a lot!
would this mean that we have to migrate the funds to new shielded pools to audit the amounts of coins?
what if the shielded pool had 15M ZEC in it and an attacker counterfeited 15M coins and would move that to the new shielded pool? would that result in everyone loosing their ZEC because the attacker was the first to migrate these coins to the new pool?
i personally store most of my ZEC in the transparent pool mainly because of that, because having my ZEC stored there gives me some kind of insurance that i won’t be the one to loose my ZEC in case of someone finding a bug to counterfeit ZEC, is that a valid concern from your point of view ?
If by “everyone” you mean holders of funds in that shielded pool, yes, in the worst case. (It is possible that we would detect the exploit and be able to recommend a rollback, but that would depend on the specific kind of flaw.)
I am personally as confident as I reasonably can be that Zcash doesn’t have a counterfeiting flaw. The circuits and other code relied on for balance have been very thoroughly audited. The security argument for balance is well understood and has been repeatedly checked. Not finding the flaw in BCTV14 earlier than Ariel Gabizon did, was the result of BCTV14 not having an adequate and properly checked security proof, which doesn’t apply to Groth16 or Halo 2. (That flaw has been fully mitigated since Sapling activation.) The choices of cryptographic algorithms, curves, key lengths, etc. are solid. If you look at the types of balance flaws that have occurred in other coins, they are in areas where we have taken especial care (such as the 64-bit overflow in Bitcoin, or the key image bug in Monero and other CryptoNote-based coins), or they were due to software engineering practices far below the standard we consistently keep to (e.g. the balance flaw in Zcoin).
You wouldn’t directly be affected by the turnstile mechanism, but a counterfeiting bug that was being actively exploited would probably tank the coin price, despite the turnstile.
This issue wouldn’t stop me from keeping significant amounts of money in the shielded pool. Lack of shielded hardware wallet support does, unfortunately. But that’s due to skepticism about the security of general-purpose desktop computers and operating systems, not about the Zcash protocol.
The draft ZIP specifying options for the new address type has been published here: ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses. Note that this is in Draft status, so additional changes are to be expected and neither of the two proposals have yet been subject to review by the Zip Editors (@daira has reviewed, but as ze is a coauthor of the ZIP I’m not sure that counts.)
Something that crossed my mind is that Binance was presented the tex address solution and not the UA approach.
My experience with larger companies is that introducing new information would require the process to start over or at least be re-assessed, which could be pretty problematic at this point
I think the UA approach is the technically appropriate, but it’s probably late to introduce it now.
I’m a football (soccer) fan and there’s a saying called “una de más” which is doing an extra move than the play actually required to scratch an itch or for one’s convenience and missing the scoring the goal
I’m afraid that introducing UAs now will be exactly doing that and complicate ourselves even more given that Binance could just pull the plug on ZEC and that’s it.
It’s important to point out that @hanh’s approach is also technically appropriate. It is optimal at the “lines of code needed” level. But sub-optimal in terms of UAs’ roadmap
I guess it was Zooko who quoted “there are no solutions, only trade-offs” from some economist.
This situation we are in is a perfect example of it.
Can someone help me understand how the proposed solution fixes the above concern? I send from a UA into a new transparent address, and then send from that same transparent address into Binance. What did that actually achieve?
I mean the lines of code Zcash developers need to code. I apologize for not being precise.
The “new information” issue shall not be ignored. Unfortunately I was not present in the conversations with Binance, but it appears to me that the UA approach was not on the table, was it?
I can’t assess how things were in those conversations to make a judgement on whether they would take this as “Zcash is moving the goalpost” or if they would be welcoming to accept another approach.
It does not seem to me that given the date we are now (mid January) we are in a place where we could propose too much, if today was November 2023 it would feel different to me.
This is what I can think of with the information I have which could be incomplete or incorrect. I would appreciate the insight from those who were involved in the conversations to provide context if needed
My perspective here is that what we’ve discussed with Binance is the general approach of defining a new address type that wallets will recognize as a directive to only spend transparent funds when creating the transaction. While we’ve discussed this in terms of the TEX address proposal (Alternative 1) we didn’t go over the specific implementation details in any depth, other than to discuss that the solution would be purely at the front-end for them and that their backend would continue to work as it always has. We did not discuss the implications for wallets and other exchanges at all; Binance did end up asking about that later in a text chat and @hanh replied that it would be necessary for the community to work with the various wallet vendors and exchanges to provide support.
My hope is that this provides an opportunity to improve Zcash user experience for all users by encouraging greater adoption of UAs in the ecosystem, and thereby getting rid of the pervasive incorrect “This is not a valid Zcash address” problem.
It seems to me that there is little risk in ZIP 320: Defining an Address Type to which funds can only be sent from Transparent Addresses giving the option of both proposals, as opposed to just @hanh’s original proposal. If Binance think that the UA-based proposal is too complex, they can say so and the original one is still available. However I suspect that, as @nuttycom said, the expiration feature that depends on using UAs (and that is applicable to all UAs, btw), will be attractive to them.
Binance has a way to send the money back, because they can reasonably assume that you have control over the intermediate address.
Binance can say to regulators that they “don’t accept transfers from shielded addresses”.
I infer that the latter has the merit from Binance’s point of view that it’s a much easier thing to explain to regulators, than is trying to make any more complicated argument in favour of the ability to receive funds from shielded addresses.
@aquietinvestor can you shed a little light on what has been reviewed from Binance’s point of view? Do you think this “wiggle room” of defining the implementation is something they consider as well or have they refered to the proposed solution as the “tex” address.
One drawback that the UA solution could over the “tex” is that there is no visual cue for white collar people to distinguish an exchange address from a shielded capable one. I’m not saying this is the case becasue of the amount of response that Binance has had, but I tend to assume that people deciding over this could be not caring about the inner workings and might favor a solution that is straight forward visible to them
On January 1, I presented Hanh’s TEX address proposal to Binance, as detailed in this forum post.
After reviewing the idea, Binance asked me several questions and requested a more comprehensive write-up.
Hanh prepared a detailed proposal, and on January 7, I sent it to Binance. Binance and I had a discussion to address their questions.
On January 10, Hanh, Kris, and I participated in a call with Binance to address specific technical queries about Hanh’s proposal.
On January 11, I added Hanh to the “Binance Tech” Telegram group (a different group from most of our discussions) where Hanh and a Binance developer discussed his proposal. Daira and Kris are also members of this group.
On January 15, Kris sent the ZIP 320 draft to Binance, which outlines both Hanh’s “TEX” address proposal and the UA proposal.
I don’t know. I certainly share your concern about introducing a new proposal to Binance after we’ve spent weeks discussing the TEX solution. I also think the UA option is more complex than Hanh’s proposal. However, I believe Kris and Daira have written the ZIP in a manner that clearly presents both options and effectively outlines their respective pros and cons. I suspect what Daira says above is accurate:
Thanks for your patience, but to be frank, I’d rather us be spending our limited resources on adding UA support for Coinbase, and Kraken, and Gemini, not this. This feels like us spinning our wheels.
I want to point out that this is already the case with Unified Addresses. If, today, I send you a Unified Address that has a Transparent receiver and also a receiver that you don’t recognize, you will make a partially-visible transaction from your shielded wallet. It is up to the wallet UI to inform their user about the privacy implications of any Zcash transaction. In the zcashd wallet, we took the approach that the user is required to explicitly consent to any transaction that is not fully private (a fully shielded transfer with no revealed amounts crossing pool boundaries).
EDIT: One more thing. I think that the need to inform users about the privacy impacts of their transaction isn’t limited to the address types used. For example, in an ideal world, a wallet would detect if a shielded address in the wallet is just being used as a “pass through” where a previously received and shielded transparent amount is being spent transparently, which as we know destroys privacy because you need to actually hold your funds in the shielded pool to get privacy.
The same thing goes for information leaked to the lightwalletd server, and so forth. Unfortunately, privacy is complicated. We need to try to reduce and hide that complexity as much as we can, of course, but we also shouldn’t give people a false sense of security. As always, it depends on the threat model.
The implementation burden for the changes to UAs is pretty minimal, and I think that this might actually help get UA functionality adopted by other exchanges. If Binance chooses the UA route, then other exchanges would need to support UA parsing in order to enable withdrawals to Binance, but that would also then mean that they can support sending to UAs (containing transparent receivers) in general, and provide good error messages if they’re given a UA with only shielded receivers - which is what we’ve wanted from UAs all along.
