The issue is that in the lite client protocol, memos are downloaded to the wallet app only when the app asks the server. So the server learns with z2z txs that wallet is interested in.
This choice to not just download all the memos from all z2z txs was made to conserve bandwidth.
I donât make decisions for ECC or decide what they communicate.
Unfortunate facts:
Zcash is only accidentally in the anonymous communication game because we needed a mechanism for payment notification. It dates to a last minute addition to the Zerocash paper.
Fundamentally, our current mechanism cannot scale. On mobile it would cause issues for some if we got current taddr levels of adoption and downloaded all memos. And if we got 10 or 100x that, it would cause problems for everyone. Its the dumbest idea possible and its not even anonymous unless you use Tor.
So we need an alternative. The one that makes sense for payment notification is out of band messages via signal/whats app, etc. Also can allow you to pay someone who doesnât have an address yet.
The question is do we also set up a mixnet or something else. I hope we do because there is excitement and interest.
Also note, out of band messages encoded in a URL also solve the programatic usage in some cases.
lightwalletd would send 1 additional byte of the ciphertext for every Sapling output. Light clients would decrypt that extra byte, and then use that determine whether the output had a memo field.
Ah, I didnât realize that the client can decrypt just 1 byte. I thought we needed the full 512 bytes.
This is great! We can implement this today, right? In a backwards compatible way? I think Zecwallet will really benefit from it! I will look into this!
Will the user still have the option to turn off memo downloads?
@sarahjamielewis is there any mathematical grounding for thinking about the protection to user privacy offered by downloading all blocks with less than n transactions? Absent an anonymizing network like Tor, and given the small size of the anonymity set of Zcash users, it seems like users who want their activity to remain private would want to download all transactions to the extent possible, no?
Also, are there any other reasons besides fetching a memo why users would need to download all transactions? Or are we just talking about memos here?
Just to respond to the general sense of the conversation so far, it seems like some design decisions have been made that compromise privacy in return for objectives like âa user can use a Zcash wallet in a context where bandwidth is limited,â because Zcash aspires to be the way everyone in the world pays for things. While I agree itâs important to design for a potential future where Zcash is the dominant payment platform, itâs important to remember that Zcash usage numbers are still pretty low and itâs still in many ways a startup looking to find product-market fit, and that the thing that makes Zcash special and unique is the potential for strong privacy protection. So, in the âcrossing the chasmâ sense the path to future global adoption runs through first building a product loved and depended on by people who need strong privacy protections. If you compromise on privacy now, and the Zcash value proposition starts to get cluttered up and diluted with pretty broad caveats like âexcept if youâre using a light clientâ or âexcept if youâre using a light client with memosâ, or âonly if youâre using this privacy-maximized wallet,â it will be harder to win over that crucial privacy-conscious user and that path to global adoption closes.
Is there evidence that the people who are the most passionate about Zcash right now, or the users Zcash is most likely to win over this year, in bandwidth constrained environments such that this privacy compromise is a necessary sacrifice for them? If not, maximum privacy should be the default, and low-bandwidth performance should be an option users can turn on if needed.
Also, in Zbay, which is just a desktop app for now, weâd like to download all blocks with memos, and only reveal what addresses weâre interested in when it is absolutely necessary to do so, e.g. when we want to see all memos sent to an address whose viewing key we just learned about, and we will probably have to use an anonymizing network as well.
Also, are there any other reasons besides fetching a memo why users would need to download all transactions? Or are we just talking about memos here?
Just memos.
@sarahjamielewis is there any mathematical grounding for thinking about the protection to user privacy offered by downloading all blocks with less than n transactions?
This analysis is based on the current distribution of transactions in the zcash network and the current behavior of the zecwallet light client (which downloads all transactions in interesting blocks in an attempt to avoid disclosing which transaction is the interesting one). As such it is specifically intended to address privacy risks that already exist in the ecosystem.
A significant number of zcash transactions end up alone in a block, so a user downloading âallâ transactions in that block from a light client reveals interest in that transaction in light clients that exist today (queue network monitoring, t-addresses, and all the pre-existing research in analyzing the zcash network here) this is likely bad. As block sizes increase the anonymity set increases (as does bandwidth).
As such this thread was originally meant to offer a discussion on providing paths for light clients to start respecting privacy and security as fundamental features - with bandwidth being the main constraint. Given the discussion across threads the last few days it is clear that the priorities are not there and different teams have different ideas about what the constraints should actually be.
As such Iâm going to summarize:
The zecwallet-lite strategy doesnât currently offer any practical anonymity for transaction/block privacy for the reasons stated above. Changing the protocol as Iâve outlined in this thread to force all light clients with less than n transactions increases the anonymity set of light clients interested in those transactions, protecting smaller blocks, and also provides a way of probabilisticly tuning such a defense as the zcash network matures.
Eventually it should be "*safe (see below) to revert back to the current zecwallet strategy
As I see it there are now 4 strategies on the table, 1 protocol tweak, and 1 existential risk to the entire concept of memo based applications in the zcash ecosystem:
Most of these can be combined with the 1-byte tweak which allows the detection of a memo or not as outlined.
All can likely be offered on a sliding scale and not impact the privacy of individual users too much in the short term i.e. these are not mutually exclusive from a privacy perspective these are gradients in protection that can compliment each other if designed properly.
Tor onion services also exist and as I mentioned at the start of the thread it might just be worth rolling those out for light service communication and calling it day, especially given the existential risk:
A. Memos donât scale, this conversation about making them scalable and safe for light clients is meaningless on a foreseeable future time frame so do the minimum amount of work to ship and hope that someone invests in workable mixnet before the all the apps zcash has founded itâs ecosystem strategy on are rendered useless.
Iâm inclined to respect @secparam analysis of the situation and think there should be some clarity from ZF and ECC on what they see as a likely roadmap for memo support as it really does have a critical input on the kinds of apps that are being funded and built right now and the priorities going forward.
If funding a mixnet is necessary for the future of many of current stars in the zcash ecosystem then that needs to be a high funding priority for the MGRC (if not ZF and ECC).
I love that quote!
@sarahjamielewis This is a great summary! It seems there is also a caveat for option 3 where we can avoid downloading all blocks. For instance, in an average 100,000 block range, how many blocks relate to your wallet?
An out-of-band layer that helps with payment detection could help with this a lot. If my wallet knows it has a transaction in block X in that 100,000 range, it could probably download fewer blocks, in a privacy-preserving way.
For what itâs worth, Iâm skeptical of this type of analysis. These kind of statistical approaches usually break. Thereâs a reason I didnât using them for hiding on chain data when designing Zerocash/Zcash.
We could, maybe, do some differential private solution. But again, weâre now going off into the realm of bike-shedding.
Itâs explicitly a descriptive analysis, not a prescriptive one - given the constraints of light clients based on what exists in field as of 3 months ago - the intent of this entire thread was not to present a solution but the present a problem for discussion.
Light clients, being used by people right now, for the majority of usecases zcash is advertising are already broken. The point was to mitigate that but improving the situation somewhat within those constraints.
The nuance is clearly getting lost and this forum is a lost cause for such technical discussion. With the issue thread in zecwallet closed, and the same behavior being perpetuated by other light clients I donât think there is much more to be gained from continuing this conversation.
BTW, this might create a decryption oracle attack to decrypt the first byte of a memo, depending on how wallets behave. If a compromised lightwalletd attacker has a guess G for what they think the first byte is, they can XOR the ciphertext byte with G ^ 0xF6 and the wallet will not fetch the memo if their guess was correct.
Reading memos for received transactions on a device like a phone isnât really importantâŚ(there, Iâve said it).
A phone wallets primary use is for spending, not receiving - all the fooling around with messaging is really just that, experiments & exploration rather than the birth of an ecosystem.
Iâd turn it off on a phone, maybe turn it on when I got home and it could talk to my own node (ie: via wifi rather than 4g). If I could share keys with my desktop wallet thatâs where I would look for detail.
EDIT: OrâŚembed lightwalletd with ZECwallet Fullnode & the lite clients look for it when connected via Wifi (not 4G), default for the client is âcollect memos only via wifiâ
There are several known issues in the light wallet protocol including the ones weâre discussing here which are documented in the threat model I maintain for our wallets: Wallet App Threat Model â Zcash Documentation 5.2.0 documentation. I wrote this threat model primarily to help us discuss and prioritize the privacy and security tradeoffs in the protocol.
There are some issues in addition to whatâs been discussed here so far. For example, there are traffic-analysis side-channels that let passive network attackers recover some information about the transaction graph (because the acts of sending a transaction and fetching the memo have traffic patterns that are presumably observable even though itâs all encrypted). There are also some flaws in the strategy of downloading all the memos in a block, because if lightwalletd is compromised, it can carry out active attacks that move transactions around between blocks or repeat them to see who they belong to (the user would eventually notice this attack because it would break outgoing transactions). Fixing these issues properly is somewhat involved and we want to do it right, without risking giving users a false sense of security with defenses that seem to work on the surface but arenât completely effective. Iâm hoping to make it one of my goals for this upcoming quarter to research and make concrete suggestions for how we can improve the protocol and fix the known issues.
In the meantime, my philosophy here is based around consent: known issues are acceptable so long as users are informed about them and consent to using the software. If people using the wallets would be surprised to find out about the problems, and care about them for their use cases, then I consider that a âsecure usability vulnerabilityâ â itâs a problem in the way the UX or documentation communicates with users. While weâre making these trade-offs and working on forward-thinking long-term solutions to these problems, we have a duty to communicate the risks to users, and Iâm very interested in thoughts anyone has on how ECC is doing on that front.
So, single sever with no trust assumptions PIR is viable using SealPIR (GitHub - microsoft/SealPIR: Example implementation of the SealPIR protocol).
With 20,000 elements (more than a month of TXs), it takes my laptop 234 ms to answer a query after 467ms prepossessing (which we may or may not have to repay every time we add a new entry) . The response is 0.32828 MB. The query is 0.065656 MB.
If we do a days worth of data (~2K):
its 36ms to handle a query, 36ms to process/setup the db, same amount of data up to make a query, and 0.262624 mb down.
For reference: Google tells me the average website size is 2mb. (and it took .1 mb to tell me that)
Can the wallet not fetch the memo and instead fetch it from cache if itâs the same wallet that sent the transaction? At least that would spare some outgoing transactions from extra lookups, though of course the light server still receives the broadcast (hopefully through an anonymizing network).
This is already the case. A sent transaction is cached locally, and memos are fetched from locally-cached transactions (the âfetch memoâ behaviour mentioned above is concretely âfetch and cache transactionâ).