Quote from: Hal on July 11, 2013, 02:25:12 AM

The zerocoin part does more than defend against DOS, doesn't it? It also provides a degree of anyonymity, if I understand it. In the conventional multi-party anti-taint protocol, every participant knows the mapping from inputs to outputs. But in your improved protocol using libzerocoin, nobody sees the mapping. Now, this requires more than two participants, so considerable organization is needed to coordinate.

Still, this an application of the zerocoin protocol which doesn't have an impact on the blockchain. OTOH, it has a small anonymity set, so the benefit is rather modest.

Indeed. Although there are simpler ways to hide the connection: e.g. Tor plus blind signatures: parties provide inputs, get a blind signature from all other parties, reconnect and expose their blindsigned tokens to get into the output list, but they leave open a DOS attack without an even more complicated protocol. Using ZC solves both the connections problem and gives you anti-DOS, which blind signatures themselves don't provide.

I was working under a (handwave handwave) assumption that the parties would meet over Tor, Bitmessage, or some other anonymity preserving transport. Practically speaking, a direct usage Zerocoin requires something similar.

I'm not sure about the anonymity set impact, it's a bit hard to reason about. One of the scaling arguments for ZC is that you could use it infrequently for a fairly small set of high value transactions. This has an impact on the anonymity set too. Because throughput isn't very limited in the joint-transaction case, and because it could potentially piggyback on regular transactions (E.g. I want to donate to Foo, but instead of donating directly I do it via a mix transaction), it should be possible to cascade many stages of mixing and increase the anonymity set size.