[ZIP 314] Privacy upgrades to the Zcash light client protocol

[defuse]

TODO:

• [x] First pass at collecting requirements.
• [ ] Find the other discussions that were on the forum.
• [ ] List all of the features in the current protocol (including ZecWallet's changes).
• [ ] Finish reading some research on these kinds of protocols.
• [x] Sketch of a constant-bandwidth container protocol.
• [ ] Look at how gRPC is used within the wallets and estimate the effort to switch to a container protocol.
• [ ] Sketch how wallets will either download-all or download-some memos.
• [ ] Write up informal but complete protocol.
• [ ] Collect early feedback from all stakeholders.
• [ ] Write detailed ZIP.

[defuse]

Master brainstorm list of requirements, non-requirements, desires, thoughts, to be added to and filtered later.

Privacy & Security

• Simplicity!
• Security review!
• It isn't a goal of this ZIP to prevent lightwalletd from giving wrong information to wallets.
  • ZIP 307 already says how to do that.
• Defend against attacks on privacy by global passive adversaries.
  • Size and timing of (most) traffic should be predictable from public information plus wallet start/shutdown times.
• Defend against attacks on privacy by active on-path adversaries.
  • TLS, detect TLS session truncation, make sure error conditions don't leak information.
• Defend against passive attacks on privacy by lightwalletd.
• An active lightwalletd adversary should not be able to recover the transaction graph.
  • Any remaining active attacks must be documented.
• Must take transparent address functionality into account.
  • The current proposal is to request the entire UTXO set periodically, so wallets will already have pseudonymous identities.
• Must account for users being spread out across multiple different servers and that some users may connect to different servers at different times.
  • Currently, users are spread across multiple lightwalletds run by different wallet vendors. We might build this protocol into Zcash nodes so users might be spread out even more thinly.
• Let wallet developers experiment with different privacy-bandwidth-UX tradeoffs, but don't give them so much freedom that every wallet does something so different and they're all identifiable by that behavior (few settings, few parameters).
• Where the protocol needs to be constant bandwidth and constant time, make it as hard as possible for the implementation to be messed up accidentally (say how it "SHOULD" be implemented).
• Be aware that wallets may react visibly to certain conditions.
  • E.g. making requests to a block explorer to view tx details.
  • Wallet devs can add all sorts of these kinds of features, which we can't predict.
• Be aware that other parts of the wallet will not at all be constant time.
• Universal buy-in from wallet devs to use this protocol is essential.
  • If some wallets keep using the old protocol, implementations will diverge further (which multiplies the cost of securing them all) and it will be really confusing for users that some wallets are more private than others.

Other

• Must support all of the features in the current protocol.
• Figure out what the next planned features are so I can keep them in mind (TODO).
• The protocol should have well-defined and predictable performance characteristics (server/client bandwidth/cpu).
• Takes error handling into consideration (currently lightwalletd returns zcashd RPC errors right to the wallet).
• There needs to be an upgrade path so a server can support wallets running the old and new protocols.
• Stick to gRPC since that's already part of the stack. Only move away if there are hard-to-avoid side channels or ripping gRPC out would be cheaper in terms of developer hours.
• Constant-bandwidth is likely going to be a radical change to the protocol (individual gRPC calls replaced with async messages within c.b. protocol).
  • Wrap gRPC in the
  • Make it possible to 'download all memos' without taking on the full cost of implementing constant-bandwidth?

Stakeholders

• Server operators are concerned about hosting costs and total bandwidth usage.
  • Perhaps settings that can control the total cost in a way that's fair to the wallets?
  • Wallets could pay fees, but that's too much complexity for a first proposal.
• Wallet developers are concerned about the amount of bandwidth needed.
• Different users will have different tradeoffs between privacy risk vs bandwidth vs UX.
• There's a cost to ECC to implement these changes and design UX around them.
• There's a cost to wallet vendors to upgrade the SDK version and add any necessary UI features.

List of places where there might be feedback/discussion

• https://github.com/zcash/zcash-android-wallet/issues/166
• https://github.com/adityapk00/zecwallet-light-cli/issues/53
• https://github.com/zcash/lightwalletd/issues/151
• https://github.com/zcash/lightwalletd/issues/307
• https://github.com/zcash/zcash-android-wallet-sdk/issues/83
• the forum? which threads?

[defuse]

Design Sketches (everything below will change unpredictably)

Constant-Bandwidth Protocol

• Parameters set the size and timing of container messages, relative to the start of the protocol.
  • Specify as few as possible parameter sets so wallets don't end up all using different values.
  • They can be a function of public information (e.g. the current mempool size) if that's helpful later.
• Container messages always leave on time.
  • How to do this in a way that doesn't depend on system load, other program state, micro-architectural state, etc.?
• Container messages contain sub-messages of different types:
  • both directions:
    • padding (empty space)
  • wallet->server:
    • outgoing transaction
      • It's visible when lwd broadcasts it, so perhaps lwd should wait for containers to come in from different wallets?
    • full transaction request
    • UTXO set request
      • Every time this happens it links the entire session to a t-address!
  • server->wallet:
    • mempool transaction (use all slack space to send the mempool, circularly and repeatedly)
    • full transaction reply
    • compact block (after syncing is sufficiently caught up)
    • less-compact block (compact block including all memos)
      • TODO: work out what exactly this will contain.
    • UTXO set response
• Generic info (lwd version, branch ID, etc) can probably still use the same old gRPC.
• TODO: think about how best to deal with side-channels in the container parsing and wallet's handling of the result.
• TODO: how to do this in a way that's not a radical departure from gRPC?
• TODO: reasonably-fast syncing can't be accomplished in (reasonable) constant-bandwidth, so specify how that's supposed to work.