Introducing Transaction Controls in Zcash

[AntoineR]

Hi @daira, thanks a lot for the feedback (and the comments on the Google Doc) - that’s very helpful! (and really nice to see this thread become alive again )

I wasn’t on the ZIP sync call you mentioned, (so not sure what was discussed exactly) but here’s some follow ups on your comments

Exchange Use Cases

AFAICT, most centralized exchanges supporting Zcash only accept transparent deposits/withdrawals, so users have to unshield before depositing (and need to withdraw transparent funds). This creates friction and reduces privacy. Exchanges are also nervous about deposits from recently unshielded funds (see the Binance delisting thread).

It feels like having a mechanism by which exchanges can “ask more questions about the funds coming in or out” would be helpful here. Transaction controls could work like enhanced TEX addresses - giving exchanges more control over incoming funds while enabling shielded deposits.

(Note: The double opt-in also prevents fat-finger errors, similar to how banks verify IBAN details before transfers. This could be useful even outside of the CEX use-case.)

Transitivity

This one’s a bit more relevant in the case where addresses are long lived and used across payments. Basically if someone’s address gets leaked in a data breach, malicious actors can send unwanted tokens to create relationships (like teams sending Vitalik meme coins for “endorsement”). This is less of an issue with Zcash’s privacy, but still relevant for long-lived addresses.

Other potential use cases of TX controls

E.g. ZSA UX considerations for AssetId discovery and authentication · Issue #755 · zcash/zips · GitHub seems relevant here. Especially:

“It could be nice if wallets have an opt-in or opt-out to receive funds, especially of a new Asset type. This doesn’t necessarily require protocol support. For example, a wallet could have a “block this txn and all future txns involving this AssetId” button that simply mutes those txns from the history list.”

ivk vs ask

Totally fair point about ivk not being appropriate. My reasoning was:

1. Reuse existing Orchard keys where possible (avoid adding new keys to the protocol. I saw your comment about considering “to have an intermediate key between the spending key and the full viewing key that could be used to authorize receiving funds”. This definitely was in my mind too, but as you pointed out in the comment, there is no such key in Orchard - as of now - and I decided to stick to the current key structure to limit the scope of the protocol changes).
2. ivk felt more appropriate than ask because it relates to incoming funds, just like approving transactions. Also, my understanding is that: yes, in theory ivk can literally be given to anyone (it’s a key with “fairly weak privileges”), but in practice, it won’t be given to any random party asking for it, simply because ZEC holders won’t want literally everyone to know when they receive funds. Under this setting, I assumed that the holders of a party P’s ivk were “trusted enough” by P to assume the extra responsibility of approving txs. It’s 100% fair to discuss and dispute this assumption.

Now, in my mind, ask isn’t a great fit either because:

1. ask is about spending not receiving, now we’d mix both
2. ask should stay “as cold as possible” - and the frequency of “signing to spend” is quite different from the frequency of “signing to receive” funds (especially for a business / charity)
3. If we use FROST, we’ll need an MPC to accept incoming funds

TL;DR: I don’t think there’s a silver bullet if we want to use one of the existing Orchard key, be it ask or ivk. The cleanest way would be to introduce a new key to have a clear separation of concerns in the key set, but that comes at the cost of adding another key in the protocol.

RedDSA Reuse

Good point, I agree. I noted (in the draft ZIP) that RedDSA was already in the protocol. This was a kind of a TODO for me to check if it could be plugged in as is.. (but I didn’t do that, and moved on to other tasks…) Reusing it is definitely better and cleaner than re-inventing the wheel!

[EDIT] So, using RedDSA seems totally fine here, but there’s a caveat. As discussed above, in this ZIP we try to reuse existing keys for the tx approval (that’s a core assumption we make in this design. It’s fine to introduce another key dedicated to “tx-approval” only - as discussed - but we tried not to here to keep protocol changes as limited as possible). Given that we want to prove knowledge of ivk and that we use the relationship pk_d = [ivk]g_d, to use RedDSA in it’s re-randomized form (see screenshot below), we’d need to be able to pass a generator as input to RedDSA.RandomizePublic(𝛼, vk) so that we can re-randomize w.r.t. g_d instead of w.r.t P_G (as currently done in the specs as show below)

And yes, it’s totally fine to blind the key additively instead of multiplicatively (both are sound, but additive blinding is more efficient).