ZIP 314 - Privacy upgrades to the Zcash light client protocol

ZIP 314 has been assigned to me for proposing privacy improvements to the Zcash light wallet protocol. A lot of the changes I would like to propose have severe UX drawbacks like drastically increasing the wallet’s bandwidth usage or sync times. So, ahead of writing the ZIP, I would like to explain my thinking and ask the community for feedback on which trade-offs to make.

This is going to be a lengthy and technical post whose purpose is both to educate the community and to request feedback. If you’d like to contribute without slogging through the technical details, please let me know in a reply and I will put together a short nontechnical survey to collect opinions to help inform these decisions.

Let’s start with a survey of what’s wrong with privacy in the current protocol. All of the weaknesses are already documented in the Wallet App Threat Model. In this post I will be focusing exclusively on the privacy problems.

This post will extend previous research by the Zcash Foundation on the same topic.

Privacy against a compromised lightwalletd

The issue I’ve seen raised most frequently in the community is the fact that lightwalletd—the server the wallet connects to—can learn the transaction graph of all shielded transactions sent between its users. This is because wallets broadcast transactions through lightwalletd, so by watching a wallet send a transaction, lightwalletd learns where each transaction comes from. Then, when a wallet receives a transaction, it will fetch the memo ciphertext by indicating exactly which transaction they want the ciphertext for, so lightwalletd learns where transactions are going to, as well. Combining these two pieces of information, lightwalletd learns who sent and received each transaction between its users.

Some implementations introduce ad-hoc defenses against this leakage, for example by requesting to download all memos in a block instead of just the one transaction they are interested in. I don’t consider this to be an adequate defense, since blocks have few shielded transactions at present, so the anonymity set is very small.

I’ve investigated several potential solutions to this problem, but before I enumerate them below, I want to describe a different kind of vulnerability that can be exploited by passive network eavesdroppers. I’m actually a bit more concerned about it, and I think it might be under-appreciated by the community in discussions about light wallet privacy.

Privacy against network eavesdroppers

While the above issue seems to be the most salient one within the community, I am more concerned about similar attacks that can be carried out by network eavesdroppers who haven’t even compromised lightwalletd.

The connection to lightwalletd is encrypted and authenticated, so we don’t need to worry about active attackers modifying or inserting traffic. However, there are bandwidth side-channels that a passive adversary (for example, the NSA or an ISP) can observe to learn information about the wallet’s behavior:

  • When the wallet downloads a compact block, it creates an observable traffic pattern.
  • When the wallet fetches a memo, it creates an observable traffic pattern.
  • When the wallet submits a transaction, it creates an observable traffic pattern.

By watching these information leaks, a passive eavesdropper can approximate the transaction graph that the compromised lightwalletd learns with certainty. The attack goes something like this:

  1. The eavesdropper watches for traffic patterns that indicate a wallet is submitting a transaction. When they see a wallet submit a transaction, they watch lightwalletd broadcast it to the network in plaintext (or if lightwalletd did so privately, they look for the new transaction in the Zcash mempool). Now, the eavesdropper knows which transaction the wallet broadcasted and which block it ended up in.
  2. The eavesdropper watches for traffic patterns indicating that the wallet fetched a memo. When they see a wallet fetch a memo, they know that a transaction in one of the recently-downloaded blocks belongs to the wallet.
  3. If they observe Wallet A broadcasting a transaction and then they observe Wallet B fetching a memo just after Wallet B downloaded the block the transaction went in to, they can conclude with some confidence that Wallet A just paid Wallet B.

The attack is not exact: If a large set of wallets S1 all broadcasted transactions that all ended up in the same block, while another large set of wallets S2 all fetched memos after receiving that block, the attacker can’t find out who in S1 paid who in S2. But they do learn that…

  • if a wallet wasn’t in S1, then it wasn’t the originator of a transaction to a wallet in S2.
  • if a wallet wasn’t in S2, then it wasn’t the recipient of a transaction made by a wallet in S1.

So, privacy gets a bit better the more active wallets there are (S1 and S2 are larger), but this is still a substantial amount of information leakage, especially at current usage levels. At present, S1 and S2 are likely to be so small they’re just one wallet each—so in practice, an eavesdropper can still find out exactly who is paying who. (I haven’t confirmed this attack with a proof of concept, but I believe it works.)

Solutions I’ve considered

So far I’ve described the two main privacy weaknesses in the light wallet protocol: a compromised lightwalletd server learns the exact transaction graph between its users and a passive network eavesdropper learns an approximation of that same transaction graph.

What options do we have for plugging these information leaks? The following sections walk through the options I’ve been considering. As you’ll see, a lot of the solutions have UX drawbacks—like increased bandwidth usage or long sync times—that would make it harder for a Zcash wallet to be competitive with centralized payment processors like PayPal and Venmo.

PIR

Private information retrieval (PIR) would let a wallet fetch a memo without explicitly revealing which memo they are fetching. However, just adding PIR alone doesn’t solve the information leakage, for two reasons:

  • PIR queries are huge (~3MB), so it would actually make the bandwidth side-channels easier for an eavesdropper to observe.
  • If a wallet does a PIR query immediately after it learns it received a transaction, lighwalletd and eavesdroppers still learn that a transaction in the last block-or-so belongs to the wallet, so the anonymity set is still very small.

To really illustrate the problem, imagine you’re eavesdropping on a wallet and you have a guess for what its address might be (e.g. you’re an evil dictator trying to find out which wallet owns an address known to be associated with activist activity). To confirm without a doubt the address belongs to the wallet, you send it a transaction and see if it makes a PIR query. Then send two transactions and see if it makes two PIR queries. Then send three and see if it makes three PIR queries. As long as the wallet keeps making PIR queries in response to your transactions, you can be sure that you have found the correct wallet, and you’ve de-anonymized the address.

To fix these issues, the wallet would need to perform ‘dummy’ PIR queries at regular or random intervals even when it has not received any transactions so that when it does need to make a real PIR query to fetch a memo, the attacker can’t know if it’s actually fetching a memo or just making a dummy query. In practice, that would translate to the wallet using 3MB of data each time it is opened, and, if we want the wallet to automatically receive memos while it’s open, probably another 3MB every 30-60 seconds continually. This also creates a UX problem: when the wallet wants to fetch a memo, it can’t do it immediately, it has to wait for the next scheduled ‘dummy’ query, otherwise timing of the query leaks whether it was real or fake.

(Technical point: The bandwidth cost of PIR can be reduced by a factor of 10, to ~0.3MB/query, by using SealPIR’s technique which would require the wallet to register pseudonymous identities with lightwalletd. An argument could be made that this is okay to do, since with transparent address support, the wallet is effectively pseudonymously identifying itself to lightwalletd anyway).

Connecting over Tor

Another suggestion has been to have the wallet connect to lightwalletd over Tor. This alone would not hide the bandwidth side-channels, because Tor only applies minimal amounts of padding to the traffic. What Tor would do is hide the wallet’s IP addresses from lightwalletd as well as from any eavesdroppers local to lightwalletd. Tor could also provide some degree of censorship-resistance to help wallets on censored networks access lightwalletd.

With Tor, a compromised lightwalletd would still learn the transaction graph and eavesdroppers local to lightwalletd would still learn an approximation to the transaction graph. But, since Tor is hiding the IP addresses, wallets’ “names” are no longer written on the graph; the adversary can only identify wallets by the time they are active.

(In fact, once t-addresses are implemented, lightwalletd does learn wallets’ “names”, because wallets must reveal their transparent addresses in order to fetch their transparent UTXOs. So with transparent address support implemented, Tor is not much of a privacy improvement at all.)

By combining the “nameless” graph with other information, parts of the full graph can still be recovered. For example, “X paid Y at 3:00pm then X paid Z at 4:00pm” combined with “Alice was seen using her wallet from 3:00-4:00pm, Bob was seen looking at his wallet at 3:00 and Charlie at 4:00”, we can conclude that X is likely Alice, Y is likely Bob, and Z is likely Charlie. I’m curious if scenarios like this matter to the community: can anyone think of scenarios where “combining information” attacks like this one would cause real harm to users?

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.

Constant-Bandwidth Protocol

To prevent passive eavesdroppers from learning information about what the wallet is doing, we could implement a constant-bandwidth protocol, as I’ve written up in draft form here.

If we did this, wallets could send transactions and request memos without revealing what they are doing to eavesdroppers. As long as the wallet is open, it would be repeatedly sending and receiving chunks of data large enough to contain mempool contents, memo queries, outgoing transactions, etc., so the downside is that it will need to use more bandwidth.

A constant-bandwidth protocol on its own wouldn’t do anything to help privacy against a compromised lightwalletd, since lightwalletd can see the actual queries and knows which ones are real versus filled with padding, but it would eliminate all of the privacy leaks that are visible to passive network eavesdroppers.

Download all memos, when on WiFi

The way that a Zcash full node retains its privacy is by downloading all of the blocks, including all of the transactions. As far as other peers and network eavesdroppers are concerned, a full node’s observable behavior does not change depending on whether some transactions belonged to it or not, so privacy is preserved at the expense of having to download everything.

We could take the same approach in the light wallet protocol. A light wallet could download all of the memos, not just the ones that belong to it, so that it never reveals to lightwalletd or any eavesdroppers which transactions it is interested in. I’ve estimated that a full sync from sapling activation, optimized to remove all unnecessary data, would cost 300MB of data downloaded to the wallet during its initial sync, and on the order of 0.5KiB more for each Sapling transaction that gets mined thereafter (this conservatively works out to ~0.5MiB/day at 2020 shielded usage levels, or ~5MiB/day if shielded transaction frequency grew to match transparent transaction frequency).

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. This would affect the user experience: if you’re away from home and receive a transaction, you’d have to either (a) wait until you’re on WiFi to receive the memo or (b) click a button to approve the use of X MiB of data to fetch all of the memos, including the one you want. (I imagine ECC’s wallet team could work out improvements to this UX!)

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.

With this change, and without additionally implementing a constant-bandwidth protocol, network eavesdroppers can still learn who is sending each transaction, but not who is receiving them. So there is still some information leakage, but eavesdroppers can no longer recover the transaction graph. (Zcash full nodes also suffer from this information leakage.)

At the moment this is my preferred solution, since it seems easiest to implement and it prevents both a compromised lightwalletd and any eavesdroppers from being able to learn the transaction graph. I’ve heard objections that it would use too much bandwidth or the sync times would become too long, so I’m curious what the community thinks. How should we prioritize bandwidth usage and sync times against strong privacy properties?

Other options

For completeness, here are some other options:

  • Sending transaction information out of band. I think that in the long run, we should replace lightwalletd with a mixnet for distributing transaction information. In the medium term, we could implement liberated payments, but we would still have to support regular (“non-liberated”) payments even if we do that.
  • We could have wallets broadcast their transactions privately using something like Dandelion++. This would prevent lightwalletd from seeing one side of the transaction graph, where transactions are coming from, but they would still see the other side, where transactions are going to. If the attacker already knows where a transaction came from, for example if they saw a Zcash full node broadcast it un-privately, then this doesn’t help.

Conclusion

If I’ve been able to convey a couple messages, I hope they’re that these trade-offs can be difficult to make and that solutions that might seem great on the surface (e.g. PIR and Tor) sometimes don’t provide the kinds of guarantees we would expect and want to have.

Regarding the trade-offs, on one hand, we can provide world-class privacy sufficient to protect high-risk users like activists (when combined with additional OpSec training) at the expense of worsening UX (using more bandwidth, adding more buttons to click). Down the road, these decisions might make it harder to compete on usability with centralized payment processors like Paypal and Venmo, but I’m inclined to make these privacy improvements now and face those challenges later once they become real blockers to adoption. Of course, if anyone thinks that implementing my preferred solution—downloading all of the memos on WiFi—would introduce any blockers to adoption in the short term, I would really like to know!

As Zcash begins to see adoption and begins to reach wider audiences, privacy-versus-performance trade-offs will start to matter more and more, and we’ll have to start making even tougher choices, so I’m eager to get that discussion started early.

For your use cases, what matters to you? What do you think matters to other people and their use cases? Do you think you and others want absolute, solid privacy, or would you prefer something performant enough to compete with centralized payment processors so that we can improve the privacy (albeit not as perfectly) of vastly more people? Should these trade-offs end up being options, so that people can decide for themselves which privacy-versus-convenience trade-off they would like to make, even though that adds complexity to the implementations and makes them more confusing to use?

Thanks!

p.s. apologies for the delay in getting this ZIP written up—writing out this post has helped clarify my thinking and decide to recommend download-all-memos-on-WiFi, so unless I hear substantial objections, I’ll be proceeding along those lines!

10 Likes

Interesting I’m sure members of @LightCli_WG would be interested in this ZIP

1 Like

Thanks for putting this writeup together! @earthrise

With so many ideas to fix privacy at the network level, I will limit my response to the open questions towards @NighthawkApps implementation.

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.
At the same time, power users need to have control over privacy of their usage, so having options under settings to use advanced constant-bandwidth/sockets/download all or random memos in addition to the ones needed would be helpful.

So, yes, let user decide for themselves which privacy-versus-convenience trade-off they would like to make with 1) the default option set to trust the lightwalletd setup + tor(& don’t pull all memos) with PIR improvements and 2) an advanced option to use more bandwidth and pull memos.

For the default option, allow the user to manually trigger a one time download for memos if they want to see the contents of transactions.

2 Likes

Hi, glad to see some discussion about lightwallets.

As a recent user, I’d like to give my impressions of the mobile wallets. For background info, I’m running both zcashd and lightwalletd privately. It took a while to sync up but it’s part of running a full node and I’m fine with that.

For mobile wallets, my expectation is different. I didn’t think I would need to sync up a new wallet and wait before it becomes operational. In my opinion, on boarding a new user on zcash is hindered greatly by this. Imagine this scenario:

  • “Hey friend, have you heard of zcash? No?, it’s a privacy centric coin, here… let me send you a few” … "
  • Friend downloads a new wallet. Then it takes more than 10s to get ready. Friend rolls his eyes.

In fact, I learned later that I would need to keep downloading data. Compact blocks are small, sure but it is increasing. If I close my wallet for a month and then come back, I would have to download a fair chunk of data and then scan it. It feels like a light wallet behaves like a mini full node rather than a block explorer.

Therefore, for me, the UX is much more important than the privacy.

If it is not instant or constant time regardless if I use it daily or monthly, I personally would not use it. So currently I don’t use shielded addresses on mobile. That’s unfortunate. I asked my friends who hold zcash and they said the same thing. They use multi coin wallets because they are snappy; even if that means they sync with the mothership. For zcash, that means transparent addresses too.

8 Likes

Adding a background sync mechanism can reduce the syncing delays:

Shielded Zcash really cannot leverage a transparent block explorer :smiley:

The UX is indeed important, but not at the cost of forcing users towards T-addresses on mobile.
As zooko recently said along the lines of, “privacy comes from storage, not transactions”, the storage on mobile wallets need to support shielded addresses, the transactions could be z2z or z2t

Adding a background sync mechanism can reduce the syncing delays:

I don’t like apps that do work in the background. They take resources and slow down the rest of the system. Not everyone has a powerful phone.

Shielded Zcash really cannot leverage a transparent block explorer :smiley:

I didn’t say they would leverage a block explorer. I mean I would like direct access to my information (putting the burden on the server to do the processing work), rather than scanning client side. Of course, I am not saying it comes without cost to privacy. Monero users are ok with it though.

The UX is indeed important, but not at the cost of forcing users towards T-addresses on mobile.

For me, lightwallets are all about compromise. Otherwise, everyone would run a full node. Currently, in my opinion, the drawbacks of using a shielded wallet are too big:

  • startup time, download bandwidth, cpu resources, storage
  • dedicated app. Many other coins are bundled in a same multi currency wallet not z-addr.

As a user (not a dev), the direction that these privacy upgrades take hinder their adoption and push me further towards t-addr. Honestly, I’m fine if wallet transactions from mobile have less privacy because I only store pocket change there. But I’m already concerned about the UX. Personally, it’s not worth using the current mobile lightwallets.
I wonder how many people feel the same way and how much this contributes to why z-addr aren’t very popular.

As zooko recently said along the lines of, “privacy comes from storage, not transactions”, the storage on mobile wallets need to support shielded addresses, the transactions could be z2z or z2t

I’m sorry but I don’t understand how this point relates to my statement.

5 Likes

Here comes the power of native APIs in picture, as the “Download all memos, when on WIFI” can be set to only trigger during night times, when the phone is set to charging and not in use. Several options can be explored.

@earthrise has highlighted different ways to achieve it in the post.

True, but the compromise must only be to the extent of trusting the Lightwalletd operators, we could improve privacy at the network layer and optimize the efficiency of using shielded transactions on the go.

While the native app does consume a decent chunk of data(~250MB for @NighthawkApps) with ~37MB app size, it is by no means taking up too much storage compared to other finance apps. And the startup time can be optimized. The challenge is to optimize the use of bandwidth & CPU resources when syncing.

Unstoppable Wallet has included Z-address support in their multi-currency app.

This is exactly what we are working on, to improve Z-address support for native, hybrid mobile wallets. The user should not need to worry about the underlying tech. And just get to experience the shielded aspect of storing their funds.

You seem to come too strong with your support and advocacy of T-addresses. Zcash community has interests to grow the adoption and usage of Z-addresses, and the smart phone is the only computer accessible to majority of the world’s population. T-address work fine in a multi-currency wallet, in-line with every other cryptocurrency, but it does not provide any privacy benefits that come with Zcash, the users would be leaking their transaction graph by using T-addresses on their smart phone all the time, and they might just prefer using an alternative crypto that is faster & transparent to meet their needs. Why Zcash?

@earthrise has highlighted different ways to achieve it in the post.

They all mean increasing bandwidth/cpu usage in the pursuit of better privacy. My opinion is that the cost is too high now and it would be valuable to offer an cheaper alternative solution. The only current choice for the end user is to switch to t-addr.

While the native app does consume a decent chunk of data(~250MB for @NighthawkApps) with ~37MB app size, it is by no means taking up too much storage compared to other finance apps. And the startup time can be optimized.

Not sure what finance app you refer to. 250 Mb seems way too much data for a mobile wallet.

Unstoppable Wallet has included Z-address support in their multi-currency app.
https://unstoppable.money

Thanks for pointing me towards it. I downloaded the app. It’s been 5 mn and it hasn’t synced yet to a new wallet.

You seem to come too strong with your support and advocacy of T-addresses.

I don’t want to push t-addr. I’m saying unfortunately, they are the sweet spot. I use z-addr but not on mobile.

You seem to come too strong with your support and advocacy of T-addresses. Zcash community has interests to grow the adoption and usage of Z-addresses, and the smart phone is the only computer accessible to majority of the world’s population. T-address work fine in a multi-currency wallet, in-line with every other cryptocurrency, but it does not provide any privacy benefits that come with Zcash, the users would be leaking their transaction graph by using T-addresses on their smart phone all the time, and they might just prefer using an alternative crypto that is faster & transparent to meet their needs. Why Zcash?

I agree on an objective but not on the methods. I think if you make z-addr harder to use on mobile, even if that’s for a noble cause of increased privacy, you will lose users to privacy coins that are less private but more accessible.

I feel you are trying to convince me that the cpu/bandwidth/storage/time usage is reasonable considering the privacy it offers. I wish I would think the same way but at this point, they are deal breakers.

It’s subjective though. I think we should find out what the users really want.

9 Likes

Here are some ~250MB apps



Agree that we should find out what users want, that initial sync is a real pain and must be improved upon. I rarely use T-address; for transparent payments I prefer using BCH, so having access to Z-address features on the go is very important to me.

There are some apps like 3D modelling that have balanced their load times, we just need to research an optimal solution that works for both beginners and advanced users.

I’m here to make Z-addrs easy to use on mobile :smiley: so that more people benefit from Zcash privacy.

I am not trying to convince you about the challenges being reasonable…towards dealbreakers, instead I am pushing towards working on improving the cpu/bandwidth/storage/time for Z-addrs on mobile.

1 Like

Getting back to topic,

For your use cases, what matters to you? What do you think matters to other people and their use cases? Do you think you and others want absolute, solid privacy, or would you prefer something performant enough to compete with centralized payment processors so that we can improve the privacy (albeit not as perfectly) of vastly more people? Should these trade-offs end up being options, so that people can decide for themselves which privacy-versus-convenience trade-off they would like to make, even though that adds complexity to the implementations and makes them more confusing to use?

For mobile apps, solid privacy matters less to me than a fast responsive app. I’d like something that works as well as btc/eth/… When I run this hypothetical wallet, I should be informed of the trade-offs and only proceed because I accept them. And not all wallets should have to implement this behavior.
Also if this means giving my ivk, I’m ok - still better than t-addr.

PS: unstoppable wallet didn’t sync after 1h though I suspect it doesn’t run in the background; I was using my phone to browse the web at the same time.

2 Likes

seems interesting, thanks for the write up

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.

My experience with Zecwallet has been that Zcash’s current problem is adoption, not a lack of privacy. Zcash already is the most private protocol out there, and already features the most private way of using this protocol (With Zecwallet Fullnode/Zcashd/Tor).

However, most potential users of Zcash aren’t converting into actual users of Zcash because Zcash currently lacks a good onboarding mechanism for people that are enthusiastic and interested. The Lightwallet protocol was a great first step, and I would love to see the Lightwallet protocol evolve towards more ease of use than towards more privacy/resistant to side channel attacks - Since we already have the Zcash fullnode for this.

The situation right now is this:
There’s a lot of users that have are uneasy over the transparency of Bitcoin/Ether/their favorite coin. They’ve heard of Zcash, and are now interested in learning more and trying out private transactions for themselves. They meet a friend who is into Zcash or watch a Youtube video. They download one of the Zcash lightwallet apps.

The first set of transactions that this user will make is almost always receive a z-address transaction for a small amount from the friend, and send the amount back. They’ll then go to a block explorer, and want to make sure that this transaction - specifically the amount and address - is not visible. In my experience, 99% of new users will follow this path.

However, this path is filled with pitfalls today. If you think of it as a conversion funnel for acquiring users, there is significant drop off at each step.

A typical first-time user:

  1. The first time they open the wallet, it has to sync.
    We lose ~40% of people right at this step. The initial sync is unexpected, and they’ve never experienced it with other wallets or coins. I’ve surveyed users that drop off at this step, and a lot of them thought that the wallet needs to sync every time they open it (Which is sort of true), and they think “I’m not going to wait 7-8 minutes every time I want to use Zcash”, and delete the Zecwallet App

  2. After the sync, they go to the “receive” section of the app, and give the z-address to their friend, and ask the friend to send them a small transaction. The friend sends our user a transaction. However, our user doesn’t see the incoming transaction yet.
    We lose another ~20% of people at this step. Users have the expectation that their wallet will be able to see unconfirmed transactions. They understand that they will have to wait for it to be mined, but they definitely have the expectation that the unconfirmed transaction should be visible in their wallet, but it is not.
    They refresh the app a couple of times. People force close it and open it again. Still no incoming transaction. The ~20% of the people uninstall the app and decide Zcash doesn’t work.

  3. They finally see the incoming transaction. Oh! It has a memo attached. That’s kinda cool. We can send messages with transactions? That’s neat.
    This is the first time our user has been delighted! The memo feature is one of Zcash’s coolest features, and they like it a lot. They ask questions - Are the memos encrypted too? Can anyone else see them? No? That’s awesome!

  4. Our user now wants to send an outgoing transaction back to the friend. They get the friend’s z-address, and try to send the money back. But the wallet shows an error!
    This is the most frustrating part of the experience, and causes another ~25% of users to drop off. The error, of course, is because the ANCHOR_OFFSET needs to be 10 (5 in Zecwallet’s case), which means our user can’t send a transaction for another ~12 minutes. Note that the problem is not the error message (nobody reads the error messages) not UX. It’s just that users don’t want to wait. No amount of messaging is going to change this. The ~25% of users decide something is wrong, give up and close the app. Even if they read the error message and wait for 10 minutes, but the time the funds are spendable, the conversation with the friend has drifted off, and they’ve forgotten about Zcash.

  5. After waiting for 10 minutes, they manage to send the outgoing transaction, including a memo, and then wait for another minute for it to show up on the friend’s wallet.
    For the ~10% of users that do manage to make it to the last step, it has still left some uneasy questions in their mind, and the wallet’s mysterious behaviour (incoming tx didn’t show up on time, first time I sent outgoing Tx it showed me some error about confirmations) means that the wallet hasn’t created a bond of trust with the user. Showing errors to users, unreasonably long delays means that the users are uneasy about the wallet, and don’t quite trust it yet.

If you’ve ever introduced a friend to Zcash, or tried to “sell” someone on Zcash by trying to get them to use it, you’ll find that these 5 steps are what usually happen.

What should Lightwallet protocol evolve into?

IMHO, I think the Lightwallet protocol’s goal should be to solve the problems listed above. We need a way for casual usage of Zcash to be accessible easily to more users. In my mind, that’s what the Lightwallet protocol is for. We want people to use Zcash for $1-$100 transactions, get comfortable with it, get used to it. And after they get comfortable, then they start to harden their usage with Tor, with Full Node, with running their own lightwalletd.

So, specifically, I’d like to see LightwalletD research go towards trying to solve the following issues. Specifically, I think the @ZcashGrants has a large role to play here - I would love to see the ZOMG proactively funding research on this. Improving the Lightwallet protocol is the single most high-leverage thing we can do today to bring Zcash to more people.

Anyway, here’s my list. I’m sure other people working on Lightwallets have even better ideas.

1. Mempool access

How can we get access to the mempool in the Lightwallet protocol and show an incoming Tx notification the instant a user receives a transaction?

2. Initial Sync

What can we do to improve checkpoints with the Lightwallet protocol. Can we allow LightwalletD to send checkpoints with some proof of work/block verification? Can the LightwalletD prove with a zkproof that the checkpoint is correct?

3. Reduce ANCHOR_OFFSET to 0 or 1.

How can we allow users to spend unconfirmed funds? Can this be a UX experience like accepting the destination and amount from the user, but delay building the transaction until after the 1st confirmation? And send the Tx in the background, and notify the user only if something goes wrong?

4. Improve sync speed

How can we make sync faster? If the user is OK with it, can we send the ivk to the server and get the server to do a super fast sync, and send us all transactions we’re interested in? Instead of syncing on the phone? IIRC, the Ycash folks do this, and it’s pretty awesome!

Downloading all transactions, memos

I’m not necessarily opposed to the proposal in this thread, but I think implementing it will make all of the existing problems worse. It will result in worse UX, more data, worse battery performance, more drop off of users trying Zcash for the first time.

Maybe we couple some of these improvements with the idea of downloading all memos?

21 Likes

:100: agree with the first 5 issues faced by new users while onboarding.

And, Mempool access with incoming notification on a smart phone will make the z2z experience lightning fast.

Initial Sync ideas with lightwalletd are great, any time delay can be better handled as “Setting up your wallet, please check back later step in the wallet UI”.

I am in full support of reducing the ANCHOR_OFFSET to spend unconfirmed funds as long as the base protocol supports the edge cases around it. Do we know how to handle Zcash blocks getting orphaned?

This is something @vamsi is going to look in to while building Zcash Block Explorer Grant - #14 by aiyadt

I agree, the large downloads on mobile wallets is a pre-2020 thing to do.

3 Likes

I think it’s great that discussions like this are happening on the forum.

I agree fully with @adityapk00’s points, I even got a shock using zecwallet yesterday when receiving a transaction, that mild panic when you think you’ve sent to the wrong address, until I remembered! Someone coming from Bitcoin or similar would not have a great first experience and anything we can do to improve the first time experience is key.

I’d be in favour of having the more secure features behind advanced settings, but I think the the default focus for lightweights should be on user experience / speed.

4 Likes

Compactblocks don’t have proof of work or zksnark attached either. Why are they trusted but not checkpoints?

Thanks

1 Like

Should we try making a Zcash wallet app with the best UX while sacrificing some network level privacy? I believe on-chain privacy is what most people need anyway.

For those who require the highest level of network privacy then we can recommend them to use fullnode.

3 Likes

Zcash blocks get orphaned if their total pow is lower than another chain.
Anchor offset is about privacy.

Edit: removed the incorrect reason. Your note could be from before the anchor.
Added link to privacy reasons.

4 Likes

This should be fine as long as privacy at wallet balance and transaction history level is maintainable while sacrificing some elements of network level of privacy.

1 Like

ANCHOR_OFFSET can be set to 0 if you want to take the risk. The consensus rules do not care about it. I have just tried it.

1 Like