I have some technical questions and suggestions about the proposed Nym integration in the context of Zcash mobile wallets. There are a few different ways I can imagine Nym being integrated:
- Option A: Send newly-created transactions to a third-party Nym receiver, which forwards them on to the Zcash network.
- Option B: Anonymize the connection between the wallet and the light client server (lightwalletd) by sending all of that traffic through Nym.
- Option C: Allow wallets to send transactions between each other in a p2p fashion to overcome the scanning problem.
Which option is being proposed here? If I understand correctly, it’s Option A?
It’s important to understand the precise impact a Nym integration will have on privacy for Zcash users. I’d recommend making a diff to the wallet app threat model so that we can compare privacy before/after.
Here’s my own rough assessment of the three options:
Implications of Option A
Zcash mobile wallets currently send their newly-created transactions through the lightwalletd server that they connect to. This means that that the lightwalletd server learns the IP address of whoever originated the transaction. Passive network observers do as well, through bandwidth side-channels. Users’ privacy is somewhat protected from full nodes, since you can think of the lightwalletd server like a “VPN” that transactions get sent through.
In the current protocol, the wallet also fetches its transparent transactions and balance at regular intervals, by revealing its transparent address to lightwalletd. This leak is also somewhat observable by active network attackers: they can send a bunch of transactions to a t-address and observe which wallet downloads more data as a result.
If we add Nym for transaction-sending only (Option A), it closes off the privacy leak that’s available to passive network observers, since Nym’s chaff traffic prevents the bandwidth side-channel attack (the anonymity set is the set of all wallets who’ve sent Nym traffic in the past little while). This could also be done by using a constant-bandwidth protocol for sending transactions to lightwalletd (the anonymity set is the set of all wallets currently connected to that lightwalletd).
Option A also prevents lightwalletd from directly seeing who originated a transaction. They can only tell that a transaction appeared in the mempool, and that it may have come from one of their currently-connected users. If everyone’s a mobile wallet and using the same lightwalletd server, then the size of the anonymity set is the number of currently-connected users.
Option A won’t close off the privacy leak that lets lightwalletd and active network attackers determine who owns a taddress. That’s because lightwalletd still sees all of its users’ t-addresses any time they fetch their transparent balances, and an active network attacker can still send a bunch of transactions to a t-address and watch which wallet downloads more data as a result.
So, for Option A to be worthwhile, it needs to be carefully integrated in consideration of the other privacy leaks that are present in the protocol.
Implications of Option B
Wallets currently download all “compact” transactions from lightwalletd, trial decrypt them, and when they find a transaction belonging to them, they request the full transaction data. This lets the lightwalletd server know who is receiving which transactions.
Anonymizing all communication between the wallet and lightwalletd would probably be too costly, since it involves a huge download. But if that were feasible, it would prevent lightwalletd from learning the network addresses of those wallets fetching transactions and looking up their transparent balance. Since wallets fetch their transparent balance by revealing their t-address, this wouldn’t provide much privacy, since all of a wallet’s activity could be correlated with their t-address by timing (the anonymity set is at most the set of all recently-seen t-addresses.)
Perhaps a better option would be to let wallets download all of the compact transactions from lightwalletd as normal, but do their transparent balance lookup, transaction submission, and full transaction downloads through independent Nym receivers. If the receivers and lightwalletd don’t collude, then transparent transaction lookups would be disconnected from transaction submissions and retrievals; if there is collusion, there is still a lot of leakage thanks to timing correlations.
So, again, it’s really complicated, and the integration needs to be thought through carefully.
Implications of Option C
If wallets could use Nym to send each other transaction data in a p2p style, e.g. by including their Nym address in their Unified Address, then they would (a) get a huge performance boost when receiving those transactions, since they don’t need to linearly scan for them, and (b) get a huge privacy boost, since they wouldn’t need to ask any centralized service for the full transaction data. By additionally broadcasting transactions over Nym, there would no longer be a small set of centralized entities that could collude to recover the transaction graph (barring breaking Nym itself).
The issues of fetching transparent transactions and fetching transactions whose data was not sent over Nym would still remain, so again, it would be important to design the integration carefully.
My Opinion
I think that Option C would be the most valuable, if it’s technically viable, since it increases privacy more than any of the other options and potentially solves a performance problem that wallets have been suffering from. Given the costs, I personally don’t see Option A or Option B as being enough of a privacy improvement given the other leakage in the current protocol. But Option C, if we can reliably solve the linear scanning problem, would be huge. (You may also be interested in this RFP that Aztec has open for solving essentially the same problem.) I argued in Scalable Private Money Needs Scalable Anonymous Messaging that a mixnet is the best known way to solve this problem.
As mentioned above, I think it would be really valuable to bring forward a diff to the current threat model explaining the precise privacy improvements. It’s super complicated, since there are so many different parts interacting!
(Disclosure: I own NYM tokens.)