[ZcF-general] March Update

[Samuel D Gordon]

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