Identify options for transaction discovery that do not require Θ(#transactions * #wallets) effort.

[Taylor Hornby]

Requiring Θ(#transactions) effort per wallet to detect transactions is not scalable and needs to be replaced with a new paradigm. The options that I know about for improving asymptotics are:

1. Sending transaction data out of band, e.g. Liberated Payments through existing chat apps or through a mixnet.
2. Using transaction tags that allow a detection server to index their database and perform O(1) or O(log(n)) lookups. My design sketch allows for efficient lookup at the cost of some privacy and relying on trusted servers acting like a proto-mixnet. This work also uses transaction tags, but is much more thoroughly fleshed out and could be a good option when combined with some kind of network anonymity layer (e.g. Tor); its downside is that recipients need to know senders' addresses in order to do the key exchange to derive the transaction-tag-generating key.

Close this ticket by summarizing the various approaches that allow transaction detection that are asymptotically better than Θ(#transactions * #wallets); detection keys and TEE-based approaches are not in scope of this ticket since their complexity is still Θ(#transactions * #wallets), even though they may be practical near-term solutions.

A closely related issue is transaction data storage: off-chain out-of-band approaches require some method for wallets to back up their transaction data so that importing a seed into a new wallet will work. Indexable transaction tagging approaches could continue to work with the current paradigm of permanently storing all data on-chain, offering faster detection without necessarily improving on storage costs.

[Taylor Hornby]

The problem of updating note witnesses privately is harder than I first thought. I think that's actually going to be the the most difficult part to scale privately, rather than transaction discovery. A mixnet can solve the transaction discovery problem efficiently, but updating witnesses is harder, for the following reason.

In the current protocol, a wallet must know a Merkle path to the note it's trying to spend. Part of that Merkle path is the hash of its note's "sibling", i.e. the note to either its left or its right, depending on where its note is in the tree. A wallet with an updated witness can always bridge the witness to the latest Merkle root efficiently and privately when sets of bridges are published and downloaded by all of the wallets, but the problem lies in updating the witness for the first time, where it's necessary to at least obtain that sibling note's hash.

Either (a) the wallet downloads all note commitments, using Θ(#transactions) bandwidth, in which case it can update its note's witness in complete privacy, or (b) the wallet does not download some of the note commitments, in which case the server observing these downloads can be sure that the wallet's note is not a sibling of any of the commitments that weren't downloaded (since if it were a sibling of a not-downloaded note commitment, the wallet wouldn't know the whole Merkle path to its note, and couldn't spend it).

Ways around that might be:

• Download random notes as decoys; the privacy properties of doing this would not be that great, since it's still the case that the server observing the downloads can rule out many notes that definitely don't belong to the wallet, the number of which are proportional to the amount of bandwidth being saved.
• Use PIR to update the witnesses, which comes at the cost of Θ(#transactions) complexity.
• Use a second level of indirection in the circuit, so that the wallet proves it has a witness to its note at some (old) root R, and then separately proves that R is a valid root within a Merkle tree over the roots of all the blocks. (The sender would have to anonymously provide the Merkle path within the block the transaction is mined in to the recipient; this is fine privacy-wise since the server already knows when the sender broadcast the transaction, so having the sender download all of the blocks until it gets mined leaks no additional information, but it adds extra steps and latency.)
• Accept the privacy leak and rely on network anonymity (Tor or a mixnet) between the wallet and the server to reduce the risk; however this doesn't really work if the wallet is constantly fetching its t-addr balance and UTXOs (since sending its t-address is effectively telling the server its identity, negating any kind of network-level privacy being used).
• Other ideas I haven't thought of?