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:
-
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 -
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. -
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! -
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 theANCHOR_OFFSETneeds 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. -
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?