Gemini adds UA support

General
1

First exchange in the world to allow sending to a UA. Thanks to the Gemini team for getting this over the finish line.

27 Likes
2

That’s really awesome! Nice work to those involved!

I have a weird technical issue/question. It seems I am able to only withdraw to UA addresses generated by Zashi’s main account page. If I try to copy and paste a UA receive address generated from my Keystone Wallet page in Zashi into Gemini it (Gemini) will give an error when I try to execute the send and say it is unable to process the withdrawal.

I’ve tested with multiple UA addresses from the Keystone page and multiple UA addresses from the regular Zashi page, but only the ones from the main Zashi page get processed by Gemini.

Can someone help explain why this might be happening?

4 Likes
3

I’ll check. I wonder if it’s because they don’t support an Orchard receiver.

5 Likes
4

Confirmed. It’s an unfortunate misalignment.

Keystone supports Orchard and transparent. But Zashi removed transparent from the UA (for Zashi and Keystone) and Keystone does not support Sapling.

Gemini hasn’t yet added support for Orchard and can only send to a UA that contains a Sapling or transparent receiver.

You can send to a Zashi UA.
You cannot currently sent to a Keystone UA.

8 Likes
5

I worked on adding support for UAs at Gemini (and sapling a long time ago!). If Keystone generated a UA with both a transparent and orchard receiver, we should send to the transparent one per the ZIP (as we don’t support Orchard). Confirming that if there is only an orchard receiver then we won’t be able to send to it, unfortunately. I actually didn’t realize until now that the ZIP was amended to allow a UA not to have transparent receiver, but I do think that was a good choice.

It sounds like keystone is generating UAs with a t-receiver, in which case we should accept them. I will take a look at this and report back. If it only has an orchard receiver then please let me know so I don’t waste my time. I don’t have a keystone wallet so taking your word for what is generating.

6 Likes
6

Keystone UA is Orchard receiver only, no underlying T-address in the Keystone UA address since it is being used purely for shielded (the T-addresses are completely separate of UAs on Keystone…ie transparent addresses all start with t and all orchard shielded addresses start with u on Keystone)

3 Likes
7

what are the obstacles for adding also Orchard support to Gemini?

4 Likes
8

Gemini’s press release is appallingly-misleading and should be corrected promptly.

Sapling support is progress, better than nothing. But I wish that they had an expert proof-read their inaccurate press release.

A lot needs to be called out here.

(this rant is intended for Gemini’s marketing team, I’m sure the engineering hurdles were immense, thank you @enforser and others at Gemini for your hard work at bringing your Zcash functionality a step forward… but please take more ownership internally of peer reviewing what claims your company is about to make about any technology, especially when it impacts user safety/privacy) (I’m also quite phobic of losing banking rails. It’s personal and hard for me to publicly-criticize centralized exchanges, there are so few of them. My hope is that someone at Gemini finds this feedback constructive. I almost deleted all of this but am deciding to trust that Gemini, its stakeholders, and compliance teams are not retaliatory people)

Inaccurate statements in Gemini’s press release:

“Highest privacy by default: When you withdraw to your unified address, you automatically get the highest level of privacy available.”

False. Implying “UA = privacy” is reckless.

This statement puts non-expert Zcash users at risk. Also Orchard offers the highest privacy on Zcash today, which Gemini does not yet support. (will they? it’s required if they want our upcoming tokens/ZSAs)

Gemini will “automatically” withdraw to a transparent address if your UA does not have a Sapling address, according to posts above. How convenient and dangerous.

“When you withdraw to your unified address, you automatically get the highest level of privacy available”

Generate an address on any modern Zcash wallet that does not embed a Sapling address? Gemini actually gives you the lowest level of privacy possible.

Starting today, every Gemini user can: Withdraw to any unified address — whether it’s your own wallet or sending to friends and family

False, “any unified address” shared by Zcash users will most certainly include Orchard addresses these days, default on all of our ecosystem’s wallets.

When you’re ready to withdraw, simply add a unified address to your address book — your funds will be sent with full compatibility.

False until they support Orchard. (“full compatibility”)

Gemini now supports Zcash unified addresses, making us the first exchange in the world to support UAs and sending Zcash to a shielded receiver in one.

False. First US-based exchange, probably. It’s not a major exchange, but Swapter has supported UAs for over a year, there are probably others. They deserve the credit for that.

Gemini: What you should harp on is why this was so hard for you to implement, why it took this long.

I bet it’s because your security is vastly superior, probably using HSMs or similar/better methods to protect user funds. Your engineers rock, no doubt at all. Give them credit, why is it Sapling-only at first? Probably some very interesting technical, security reason.

I’m sure this is a case of marketing misunderstanding the technology, and frustration aside, I do respect Gemini and its founders’ long-standing support for the Zcash ecosystem.

But I strongly believe this press release needs a correction.

Meanwhile, Kraken.

Kudos to the only US-based exchange that supports privacy-by-default withdrawals on any currency: Kraken’s bold support for Monero, and thus the human right to privacy, since 2017.

Privacy is a growth sector: Kraken’s 24 hour Monero trade volume shows $2.4 million today. Gemini’s 24 hour Zcash volume shows $2,820. NEAR DEX is at $180k ZEC 24hr. I don’t use Gemini for Zcash because there’s barely any liquidity, it’s easy to get ripped off. Please get a market maker.

Gemini: match Kraken’s commitment to privacy by disabling transparent Zcash address generation, and withdrawals, for your users. It won’t cost you any revenue (look at your volume) and is incredible marketing.

Even just on the withdraw side as a step forward. Never send to a transparent address, revealing forever that your customer uses Gemini. Or if you must, only send to T-addresses from the Orchard pool (shield your own reserve). That’s what a strong privacy stance looks like.

Until then warn your users. Withdrawing to a Zcash UA? You must warn users if they’re withdrawing to a transparent address without them knowing! It’s so hard to tell what’s embedded in a UA.

“Simple UX” can be dangerous in this industry - when something “just works” it might mean you’ve forever doxxed yourself on a blockchain, with real human consequences. “Whoa: That UA ain’t private!”

Want to take a strong privacy stance? Show a warning “this transaction is not private, is forever stored on a public blockchain” for all public blockchains, including T-address withdrawals.

And don’t quote the Cypherpunk Manifesto in your press releases. I’m sure that you have entire teams dedicated to invading people’s privacy, tracing public cryptocurrencies using walled garden “compliance tools” and crypto-unbanking them without telling them specifically why or which “computer said no.”

Do you not log every UA pasted into your exchange, even if it contains a traceable T-address, and even if a user does not actually withdraw to it? (Error states?) Perhaps compliance teams can access those logs?

Sure, you’re tightly-constrained by US regulations. Don’t quote the manifesto.

A centralized exchange can never be cypherpunk.

Zcash: our top priority should be adding Orchard support into decentralized exchanges (NEAR and Maya). This also paves the way for ZSAs on DEXes.

Edit: to engineering at Gemini - you are considering Orchard-only UAs valid and allowing users to add them to their accounts, then the withdraw fails, FYI, not a security issue just a usability and potential data cleanup headache. example orchard-only address that I have burned (do not send anything into it): u1ugyp343q07xw4v2w28esdrtyjg9kx7agx4rgkmfrr9kj5792q387n9r29fw2sr3fxzuaweaklpnh25nxqat6xpc9spwpn6a79v6lvjeh

1 Like
9

This is not true, Zashi defaults to Orchard + Sapling.

5 Likes
10

Thanks, corrected.

3 Likes
11

It’s so hard to tell what’s embedded in a UA.

I’ve been meaning to ask, what’s a good way to do this? If I’m sending from Zashi to a UA someone says is shielded, is there a simple private way for me verify it’s not actually just a transparent receiver or sapling receiver that’s embedded in the UA before I send? Will Zashi warn me that the transaction will not be fully shielded (orchard to orchard)?

1 Like
12

Few ways:

2 Likes
13

Thanks for the answer! Does Zashi give any kind of popup warning if you are sending to a UA that is actually just a transparent address or a cross pool address?

It does seem like a slight step back if there isn’t a simple way upfront to just know if you are about to send an orchard to orchard or not. Before if you were sending from an address that started with a z to an address with a z you knew on its face it was fully shielded, is there no equivalent now?

1 Like
14

Good question! One easy way to tell is by the length of the address.

I think their is room for improvement in this department, good call out :+1:

1 Like
15

This is something I’ve wanted for a while, so I’ve made sure that the feature request is being tracked: Add privacy implications to the confirmations screen. · Issue #84 · Electric-Coin-Company/zashi · GitHub

5 Likes
16

Thank you that link was very helpful.

A few questions geared towards human readable aspect (like a user was able to do with z2z knowing with their eyes upfront iif the receive address being offered would result in a fully shielded transaction if used):

  1. I noticed that the link doesn’t provide lengths of UAs that are encoded as transparent only and sapling only. If it’s possible for those two to exist as a UA what lengths would they be? (so length of a t only receiver type encoding and z only receiver encoding)
  2. Does anything at the Zcash protocol level prevent a t-only UA from being used? If not, what ultimately ensures a t-only UA can’t be encoded or decoded and used by a wallet?
  3. t+s and t+o seem to both be 141 characters, so a human by themselves wouldn’t be able to tell on its face if a UA send will be cross pool without the help of a wallet or app, correct? The only exception being a UA that is 106 characters which would mean it is Orchard only?
17

At present, T-only UAs are forbidden by the spec (prior to Revision 1 UAs, which needs some rework as they’re now going to omit t-addrs entirely); however, it’s possible to construct a spec-obeying UA for which all existing wallets will only be able to identify the transparent receiver as a valid Zcash recipient. So, a malicious party could induce someone to send a deshielding transaction.

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.

The recipient always knows who they’ve given out addresses to, so they can identify the sender by distinguishing which address the value was received on; if they don’t have that metadata (say they put a donation address on Twitter) then they don’t learn anything about who paid them unless the sender explicitly provides that information in a memo or something like that.

1 Like
18

Relevant to the discussion: Let's remove t-addresses from UAs

1 Like
19

To my knowledge a UA with just a T or just a S receiever doesnt exist, it would reduce to the normal taddrs and zaddrs from before.

I believe the lengths are:

  • t = 35
  • s = 78

For the nitty gritty we will have to jump in the super dense ZIP.

Since cross pool transactions do leak amounts, this is precisely where we have opportunity for improvement for the perspective you bring up. Open to ideas :light_bulb:

1 Like
20

Thanks! I really appreciate all the help you’ve all given.
I know these are very edge case questions:

At present, T-only UAs are forbidden by the spec (prior to Revision 1 UAs, which need some rework as they’re now going to omit t-address entirely); however, it’s possible to construct a spec-obeying UA for which all existing wallets will only be able to identify the transparent receiver as a valid Zcash recipient. So, a malicious party could induce someone to send a deshielding transaction.

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?
(ie a human checking to see if the UA length is 106 characters long is not a foolproof way for a human to avoid a UA that might have T–address receiver or sapling receiver)

then they don’t learn anything about who paid them unless the sender explicitly provides that information in a memo or something like that

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.