[ZcF-general] March Update
Samuel D Gordon
gordon at gmu.edu
Fri Apr 19 02:13:03 EDT 2019
March Update:
We thought about the meaning of our security definition, based in part upon this comment by Ian Miers<https://github.com/ZcashFoundation/GrantProposals-2018Q2/issues/36#issuecomment-393334620>. Our thinking is that the strength of our system depends almost entirely on the size of the mix-in that we can support. Of course, if my mix-in is small enough that, later, nobody else in my mix-in spends in the same shops that I spend in, the security is greatly reduced. Similarly, if only a few thousand zcash keys are shielding, then even if you use a ZKP to “mix-in” the entire set, your anonymity is only as good as the size of your mix-in. And, to take the opposite extreme, if our protocol is efficient enough to support mixing a very large fraction of the entire network, this would be similar to using a ZKP to prove that a large fraction of the network could have made some payment. Our hope is that we can support a large enough mix-in to claim something comparable to other systems.
Unfortunately, though, our initial findings indicate that the amount of noise required might be a deal killer when building a system that simultaneously achieves strong anonymity and cheap payments. We plan to try a few things to move forward:
* We are going to see what we can do to lower the noise, either by changing the protocol, or by changing the noise distribution.
* We’re going to see whether our \sqrt(n) variant gives something useful. (So far, we don’t think so though.)
* We’re going to see if our construction at least allows us to claim some asymptotic improvement over naive mixing alternatives.
* We will estimate the exact noise requirements for small sizes of mix-ins, i.e., n=50, as traditionally estimated in some related work (e.g. Dicemix)
Dov, Foteini, Mayank
More information about the general
mailing list