<div dir="ltr"><div class="gmail_extra" style="display:block"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>I'd love to get more analysis of the tradeoffs.<br><br>Cryptocurrency users would strongly benefit from Mixnets but the DMMS/Proof of Work blockchains struggle with fitting in Directory Authorities and static membership systems.<br><br>I've been a fan of the observation that Mixnets fit in better in a Proof of Stake architectures where you have a more static set of participants.<br><br>But better understanding the tradeoffs would let us better understand what properties are desirable.<br><br><br><br></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, Dec 31, 2017 at 3:33 AM, Moritz Bartl <span dir="ltr"><<a href="mailto:moritz@headstrong.de" target="_blank">moritz@headstrong.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 31.12.2017 02:18, Vincent Breitmoser wrote:<br>
> Research papers typically select these variables to have very strong<br>
> anonymity guarantees. But it might be worthwhile exploring (or at least<br>
> brainstorming) the opposite approach: Optimize for the least impact on<br>
> usability, reliability, and performance, and see if we can still get<br>
> worthwhile anonymity gains.<br>
</span>I would first like to see any actual formulas. It irritates me to even<br>
begin to think about tradeoffs before we know what they might be in the<br>
first place.<br>
<span class=""><br>
> Obviously, the only way for a mixnet provider to avoid<br>
> depending on another organization's operational performance is to run<br>
> all mixes itself.<br>
</span>The Internet depends on "other organization's operational performance"<br>
all the time. Constantly. It is the Internet, after all. So, you put<br>
reliability on top of unreliable networks, and that can give you certain<br>
guarantees, regardless of who operates parts of it.<br>
<span class=""><br>
> Now this leads to an interesting legal question: How difficult is it,<br>
> for some entity (that is generally honest), to create an organizational<br>
> structure that operates mixes, under different jurisdictions?<br>
</span>As long as you exercise control (and that control can be constructed to<br>
even just be "you write the software for your 'own' network"), that is<br>
just too weak for anything serious. The type of legal attacks we're<br>
already looking at is no fun, and I don't expect this to become<br>
better... Look at what happened to the mix cascade run by the TU<br>
Dresden, due to legal pressure. [1]<br>
But yes, probably this could be done in a way that is less<br>
straightforward to attack. If this is what people need to hear to<br>
finally support this kind of research, then OK, I'm willing to agree<br>
with the "better than nothing" argument, especially since it does not<br>
change anything for me in terms of design, priorities, and required work.<br>
It just sounds a lot more realistic to have a court sign some order for<br>
"one bad actor (plus all subsidiaries under its control)" than for 10<br>
legally independent parties.<br>
<span class=""><br>
> This seems<br>
> like it's too easy - but what's to prevent three nominally independent<br>
> mix service providers from running a mixnet, for some umbrella org?<br>
</span>I really do not see a problem with participating providers to actually<br>
participate, and for some of them to provide decent bandwidth. We need<br>
one mix operator to be honest, and depending on your exact architecture<br>
you can get away with a total of three.<br>
Compare this with Tor, where you not only need hundreds or thousands of<br>
relays, you also need operators who can deal with hundreds of abuse<br>
complaints per day. Which you simply won't have in a closed messenger<br>
Overall, I see fifty other things that I would prioritize, and that<br>
needs to be either developed or researched, regardless of who will<br>
eventually run the network. Maybe that is not enough motivation, but<br>
really, I don't see the big problem with mixnet operations spread across<br>
multiple entities. Usenet does it, and how many PBs are transported<br>
there daily nowadays?<br>
Just to give you an idea, a non-profit IX in Berlin is sponsoring us<br>
10Gbit/s of actual traffic, just like that. This is happening at more<br>
and more places, thanks to the Tor relay community, and together with<br>
the "no abuse problems" argument, it will be fairly easy to find even<br>
faster, stable sponsored sites.<br>
What's the figures we are looking at for zcash transactions? Signal<br>
messages? Whatsapp? What would that mean for a mixnet?<br>
Generally, it seems that practitioners are underestimating how much<br>
actual research this topic still needs before we should put a mixnet in<br>
front of any actual users. Until we have that research, we should use<br>
the momentum to support them, make it easy to run simulations and<br>
experiments, and once we have anything that resembles an interesting<br>
research project we have more than enough universities already who would<br>
love to participate in a large testbed.<br>
There are dozens of interesting mixnet designs, and there is no (in<br>
numbers: zero, none) framework that allows researchers to actually test<br>
their hypotheses. We have the opportunity here to give them the right<br>
tools, which also deals with real-world network issues and everything<br>
else that is usually out of scope (PKI etc).<br>
[1] <a href="https://anon.inf.tu-dresden.de/strafverfolgung/index_en.html" rel="noreferrer" target="_blank">https://anon.inf.tu-dresden.<wbr>de/strafverfolgung/index_en.<wbr>html</a><br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/messaging</a><br>