@Mikerah: Meson isn’t a rebranding at all. In all of our docs, we mention that we use the Katzenpost software libraries. Meson is simply an instantiation of a cryptocurrency mixnet.
The first principle of anonymity is that anonymity needs a crowd. Strictly speaking, special purpose mix-nets will offer less anonymity than a general purpose mix-net.
So if you fork Katzenpost and make a special-purpose mix-net called Meson for cryptocurrency (or worse, for only ZCash or only Ethereum), Meson will offer less anonymity as its anonymity set will be the number of cryptocurrency transactions over Meson, which would be less than a general purpose mix-net.
That being said, if you made a generic mix-net and had different, interoperable code-bases, that could offer better anonymity by blending active user-bases. However, in practice this hasn’t happened with anonymity networks like Tor. So while you can make an interoperable Tor client in say, Java (as has happened), the core Tor code is developed quite quickly by a large team while Tor-in-Java has had considerable bit rot and been abandoned.
So, what you want is a single general purpose mix-net with the maximum number of users. You want to support not just cryptocurrency, but any kind of traffic. This is where @imichaelmiers is correct, although he is incorrect in believing that mix-nets can only handle one kind of traffic (such as cryptocurrency). There’s a space of trade-offs between Tor and mix-net design.
@mikerah: So, I wouldn’t say that Meson offers strictly worse anonymity for our particular use case and future research work.
Unless there is cover traffic and timing delays in the Loopix design, currently an unparameterized mix-net offers about the same anonymity as a VPN (i.e. no resistance to a global passive adversary) with multiple exit nodes, and with lots less users than Tor and so a smaller anonymity set. So that’s why we recommended to efforts like Grin to just use Tor rather than build their own mix-net if they need a solution today.
@mikerah: The definitions are similar but different due to the considerations that both fields need to take into account. As for Dandelion++ being fine to use now for Zcash, I still don’t think this is accurate. I would say that for now, Tor is a better option for Zcash, considering that zcashd already has Tor integration.
Note that you can have mix-nets that are based on cryptographic constructions, such as MCMix that uses secure multi-party computation (it’s just reallly slow and likely can’t scale, like a DC-Net). However, implementations of Loopix such as Katzenpost and Nym are not cryptographic constructions, but “stop and go” statistical mix-nets. You can have “free routing” mix-nets based on p2p architectures, but these are vulnerable to route capture and tons of attacks, and generically less anonymity. I recommend looking at the papers by Claudia Diaz of Nym on these topics.
I would continue to argue that Dandelion++ is fine if your goal is 1) generic hiding of IP addresses and 2) it’s mandatory in ZCash. It gets you the same property, i.e. IP address hiding, and the anonymity set will be as big as the number of implementations of ZCash that support it. The anonymity set of Tor would be larger of course, but how many people turn on Tor with ZCash.
Overall, you only want a mix-net if you want resistance to a global passive adversary on the network level. I support this strongly, as it’s a realistic threat model for cryptocurrencies given say, Chainalysis, and the goals that ZCash is trying to provide.
However, what you want is a generic mix-net infrastructure, not a cryptocurrency-specific mix-net, and one that actually uses the features of Loopix that provide this level of resistance to a GPA. If such a proposal was generic to the underlying codebase, that would be great, but as an ex-W3C employee who did test-suites, formal verification, and specs, don’t underestimate the amount of work in interoperability.