Gemini adds UA support

[nuttycom]

@acre

Is it possible to construct a spec-obeying UA that is 106 characters long (which according to dismad’s link an orchard only UA would be) but where the only identifiable valid receiver embedded is actually a transparent receiver? What about the same thing where the only valid identifiable receiver by the wallet is a sapling receiver?

Yes to both questions.

@acre

Doesn’t seem like a material concern but I guess accidental sends to transparent address or a 100% cross pool transaction maybe could leak a bit of data to whatever tax authority the sender also reports to.

The only case where this is really relevant is iff the sender has provided their full viewing key to said authority; cross-pool and deshielding transactions don’t leak any information about the sender, so I’m not sure what scenario you’re imagining here. There would have to be a lot of other out-of-band leakage for this to be relevant; probably enough out-of-band leakage that you wouldn’t need the chain data to begin with!

[emersonian]

@nuttycom

That being said, one important thing to realize is that due to the fact that Zcash has strong sender anonymity when spending from the shielded pools, sending to a transparent address doesn’t leak any information about the sender; it harms the recipient’s privacy, but not the sender’s, even from the perspective of the recipient.

A quick OPSEC note here. While the sender does get strong sender anonymity, high risk users should always be thinking “what does the other party find out about me.” In the case of sending, the recipient will know the timestamp, the amount, and the TXID.

So a sender must be very careful about timing analysis. Only you know when and where you got your shielded ZEC from, but it could be easy to guess with high accuracy. This is how Tornado Cash transactions are traced for example. (1 ETH into its shielded pool today, then 1 ETH out five minutes later, with no other transaction for hours? Probably the same person)

Consider:

1. You withdraw 3.14 ZEC from “KYCExchange” at 11:00 UTC
2. You shield 3.14 ZEC from a transparent address into Orchard at 12:00 UTC
3. You send 3.14 ZEC from your Orchard into a recipient’s transparent address at 12:10 UTC
4. That recipient for whatever reasons can legally compel KYCExchange to reveal your identity, or their KYC database leaks at some point in the future. They see that you are the only one to send 3.14 out of Orchard this entire week by indexing all transparent transactions on Zcash (this is not theoretical, you can do this today using Google BigQuery’s Zcash dataset).

It’s easy to get traced using timing analysis, no matter how strong the privacy tech protecting the identity of your Orchard address. In this case above which is commonly happening in blockchain analysis tools (to Tornado Cash users in particular), it didn’t matter that you used Orchard at all.

Never send the same amounts that you have received, hold in Orchard for as long as possible, and try to always leave shielded pools (on any blockchain) in common denominations that you can assume many other users have used. (Send 1 ZEC , 10, 25, 50, 100, etc.) (very excited for a wallet to do this in our ecosystem at some point, DASH-style denominations & pre splitting of notes)

[nuttycom]

@emersonian

Never send the same amounts that you have received, hold in Orchard for as long as possible, and try to always leave shielded pools (on any blockchain) in common denominations that you can assume many other users have used. (Send 1 ZEC , 10, 25, 50, 100, etc.) (very excited for a wallet to do this in our ecosystem at some point, DASH-style denominations & pre splitting of notes)

I absolutely agree with all of this; wallets should definitely make it easier to avoid harming your privacy in this way. This is also a reason that I think we should be judicious in adding e.g. “send max” functionality in cases where the recipient will be transparent; it’s way too easy to kill your privacy this way. Also, thanks for your feedback on Add privacy implications to the confirmations screen. · Issue #84 · Electric-Coin-Company/zashi · GitHub.