ZIP 314 - Privacy upgrades to the Zcash light client protocol

[holmesworcester]

@earthrise

This is probably an unreasonable amount of data to download over a cellular connection by default without explicit permission (please let me know if you think otherwise!), so if we implemented this, I would recommend that the large data download would only happen when the phone is connected to WiFi.

For any user that regularly uses voice and video on their phone, or music streaming apps like Spotify, this doesn’t seem like such a huge impact.

It could surprise users that a wallet app is using this much data though, so it makes sense to ask them on first run whether they want to sync all the time or just on wifi, and explain the data usage and the reason for it.

@earthrise

Downloading all of the memos would also increase sync times whenever they are bandwidth-constrained, since the compact blocks that the light wallets download would be modified to include the memo ciphertexts for each note.

The time to receive incoming payments and spend them would be the same, right? Only memos would be delayed?

Or would notifications about incoming payments be delayed?

@gmale

@holmesworcester

The transaction will always be more important than the memo.

While I agree with your core concept, I’m not sure “always” is the right word here, given the likelihood of memos becoming more programmable, over time (frequently containing data for machines rather than messages for humans).

Maybe “always” goes too far, but even for programmable stuff, knowing that there’s something out there of interest is probably valuable independent of knowing what it is, no? But yeah! I think we’re on the same page here?

I think Aditya’s first point in his first post is really important:

@adityapk00

This is a well thought out proposal that will no doubt achieve the goal it has set out for (More private Lightwallet!). However, I think this focuses on the wrong goal.

For people focused on these glaring usability issues it might seem like increasing lightwallet privacy is the wrong goal to focus on.

But for people who want the lightwallet stack to be more private, this proposal is a huge deal and will make a big difference.

And while there might sometimes be tradeoffs, in the vast majority of cases it’s not a zero sum game between privacy and usability.

I think the thing that makes it feel zero sum is that specific people are often the bottleneck when it comes to figuring these things out, which feels like a centralization and funding problem to me.

What’s the way this conversation doesn’t have to be an either or? Can we fix all the above lightwallet issues and address the privacy problem, without having to grind our gears figuring out which to prioritize?

It seems like ZOMG funding could play a role here, both in bringing new people into the space or in funding existing wallet teams to grow to the point where they can tackle these upstream issues that create usability problems and get their changes merged upstream.

[adityapk00]

@holmesworcester

What’s the way this conversation doesn’t have to be an either or? Can we fix all the above lightwallet issues and address the privacy problem, without having to grind our gears figuring out which to prioritize?

I think this is a great idea! It would be pretty cool for Zecwallet to pull together a small team to work on Lightwallet Protocol focused on improving usability and adoption while simultaneously incorporating all the privacy improvements coming from the ECC and other teams working in the space.

Let me try and put together a proposal for the @ZOMG.

[aiyadt]

@holmesworcester ZOMG better be ready to see 2 proposals for funding wallet teams
@NighthawkApps has started onboarding 3 developers to improve the end user experience on mobile along the points discussed in this thread. The goal to address lightwallet issues will need cross-pollination with the upstream ZcashLightClient & Zcash Android Wallet SDK & wallet repositories. Therefore, the target of my upcoming proposal would be to dedicate time to resolve outstanding issues in wallet related repositories, so every Zcash mobile SDK consuming team would benefit.

@aiyadt

Speed and efficiency is of utmost importance for a mobile wallet, even the present forced delay to wait for funds to be spendable after making a transactions(and it to be mined) is a problem for end users.

[dontbeevil]

My insights never disappoint:

@dontbeevil

Instant sync? and/or improve zero state experience for first time users.

I’m “happy” to see other mobile Zcash wallets face the same issue when it comes to “instant sync”. Thank you @adityapk00 for sharing user sessions, as you can that was helpful for the discussion on this thread.

kudos to @holmesworcester @aiyadt @hanh & others for healthy discussion. Great proposal btw to improve privacy @earthrise

Looking forward for fast mobile wallet!! Fund it, collaborate it, build it, test it & we (old & new Zcash users) will use it.

[chelseakomlo]

@earthrise

Tor also fails to defend against attackers who are eavesdropping on the wallet’s local internet connection. Imagine, for the sake of illustration, a country surveils all of its inbound and outbound traffic to a foreign lightwalletd server. Even though the wallets are connecting over Tor (to foreign guard nodes, let’s say), and all the attacker sees is Tor traffic*, the attacker can still use the bandwidth side-channels to learn when the wallets are sending transactions and fetching memos. So, by correlating the timing of those events, they can still tell who’s paying who within their country.

(* - This is assuming they can distinguish Zcash wallet Tor traffic from all other Tor traffic, which they would have to do by taking advantage of other traffic analysis techniques. I expect that it would be easy to identify a wallet’s traffic, since it would probably not look anything like web browsing, chat apps, etc.)

So, adding Tor by itself doesn’t offer a solution to the privacy problems. Another drawback to Tor, which I haven’t investigated or understood fully myself, is that apparently it’s hard to get working on mobile devices; perhaps that’s something Arti could solve.

Hi Taylor. I wrote this analysis in the Zcash R&D discord as well, but as far as I’m aware, successfully performing end-to-end timing attacks in a blockchain setting is a completely different beast than performing end-to-end timing attacks in realtime applications like messaging applications (assuming a sufficient anonymity set size, otherwise we are in trouble in other ways).

So, dismissing Tor with this assumption seems wrong to me, without more detailed analysis as to what exactly an end-to-end timing attack requires for such a global adversary (such as a country that can view all inbound/outbound traffic), when considering that all Zcash transactions must first be synced to a global state store (the blockchain).

[teor]

As engineers, we should be open to incremental improvements. Even if we have plans to replace them with a better design later on, they can still provide significant improvements to our current users.

For example, wallets use TLS to connect to the lightwallet server, even though there are known attacks against TLS. Because TLS provides basic authenticated encryption, eliminating some kinds of attacks, and raising the amount of effort required for others.

Similarly, Tor provides basic network anonymity, eliminating IP-address tracking attacks, and further increasing the amount of effort required for other de-anonymising attacks. (If we’re at the point where we’re debating whether some of those attacks are even feasible, then they are obviously more difficult for attackers.)

Adopting existing well-tested solutions also helps us work out what the remaining edge-cases are. And gives us time to work on them.

For example, we could explore padding inside the Tor connection, or replace Tor with a mixnet, or do private information retrieval. But we need to deploy a best-practice network privacy solution first, so we can evaluate its actual privacy properties (including anonymity sets). Then we’ll know which of these alternatives are worth exploring.