Temporary outage of available balance

[zookozcash]

When Zashi opens, Available Balance drops to zero and stays at zero for up to a minute or two. This is a UX papercut (it makes it inconvenient to whip out your Zashi and pay someone or message someone), and it undermines user trust in Zashi.

It also makes users think Spend Before Sync isn’t working, and in a sense it means Spend Before Sync isn’t working! (For a minute or two.)

The underlying issue is actually quite complicated because of privacy tradeoffs — if Zashi spends ZEC immediately after startup, without time to download more metadata to generate a witness to a different anchor, this leaks a little bit of information to the everyone in the world (linked to the ciphertext of the transaction) about the timings of when the wallet has been open and what network traffic (block headers/metadata) the wallet has previously received.

There are two possible ways to fix this:

1. Be prepared to spend ZEC immediately after startup, even at the cost of leaking a little bit of information about the timings and metadata receipts of the wallet). This is a privacy tradeoff but would fix usability and make Zashi more trustworthy.
2. Optimize the download of metadata so that it takes only a few seconds instead of a minute or two.

There are accompanying options about the UI for this.

If we’re doing option 1, the UI is that “Available Balance never goes down except when I initiate a transaction”. (This is written in Zashi UX Principles in the “Available Balance” section. See also the section in Zashi UX Principles about “Closing and reopening”.)

This still leaves two possible UIs under option 1:

1.a. There is no user-visible difference between sending after Zashi has had time to download fresh metadata and sending before. In both cases, Available Balance is shown and the send UX flow is the same. Scores: Usability: 👍, Trust: 👍, Privacy: ❓

1.b. When you type in a transaction, and Zashi is in the state of “insufficient metadata to use a fresher/better anchor”, Zashi indicates to the user somehow that this transaction will have a certain kind of reduced privacy. Making the meaning of that information leak clear to a user is a major challenge and, frankly, probably impossible. Usability: ❓, Trust: 👍, Privacy: ❓

If we’re doing option 2 there are a few UI options:

2.a. The user-visible “Available Balance” goes to 0, but for a much shorter time. Usability: ❓, Trust: ❓, Privacy: 👍

2.b. The user-visible “Available Balance” stays at non-zero, and there is “wait” UI such as a modal spinning wait indicator or such as the “Hi” animation at startup that prevents user actions (including initiating an new transaction) until the metadata is fetched. Usability: ❓, Trust: ❓, Privacy: 👍

2.c. The user-visible “Available Balance” stays at non-zero, the UI is all enabled so that the user can do things including initiate new transactions, and then after a new transaction is initiated, if the necessary metadata for better/fresher anchor selection is still not available then the “wait state” (which already in the current implementation exists, to wait for proof generation and posting the transaction) persists until both metadata fetch and proof generation and transaction posting have all finished. Usability: ❓ or 👍 depending on how fast it is, Trust: 👍, Privacy: 👍

Conclusion: we should do 2.c. and make all of the following as fast, as eagerly initiated, and as parallelized as possible:

1. Metadata fetch
2. Witness generation
3. Proof generation
4. Posting of transaction

This issue is a major UX papercut, and many of the Secret Zashi Beta Testers Club and many members of the Zcash community have raised it. A lot of people perceive this as meaning that Spend Before Sync doesn’t actually work, and in a sense they are right! Fixing this is a requirement for “Zashi 1.0”, and it is a priority within the Zashi beta development as well. However, currently adding Orchard support is a higher priority because lack of Orchard support can result in lost funds (a UX legbreak—worse than a UX papercut), and because we’re coordinating with Brave who are currently adding Orchard to Brave, and because Orchard eliminates the question mark about trusted setup.

Major thanks to @nuttycom for working with me to figure out all these issues and tradeoffs.

[conradoplg]

I agree with your approach but I think there's an orthogonal issue: Zashi shouldn't show balance zero regardless of the approach taken. Option 2.c basically solves this, but even if this initial sync takes as long as it takes now, it shouldn't show the balance zero but it should show the balance that was previously being shown the last time the wallet was used.

[zookozcash]

@conradoplg Yes, in 2c (and also in 2b) the Available Balance continues to show the balance that will be spendable once the metadata is fetched. In 2a the Available Balance is shown as 0 when it is in that state.

[dismad]

it shouldn't show the balance zero but it should show the balance that was previously being shown the last time the wallet was used.

Perhaps using colors to indicate whether its available to spend? For example keep it red, indicating NO,or STOP, then another color when it is ready to spend. Color coding is my favorite hack!