And when you try to figure how to deal with denial of service attacks in a big DC net that tries to use bandwidth with tolerable efficiency -- I don't know if anyone has figured out what would be involved -- I certainly have not.

The bandwidth is the easy part. Building clients that do a DC protocol with real-world reliability and resistance to denial of service is the hard part. And doing all this in a package that would be easy to get people to use is probably the hardest part. The only way I know of to deal with denial of service is for everyone to reveal their flips and kick the attackers out of the net. However, if someone is legitimately transmitting that round they loose their untraceability. So pretty much the only way to do it is ensure that only one participant has permission to transmit and that the participant with permission gets to decide if everyone shows their hands. A way to do this would be to have a separate reservation phase of the protocol. In the reservation phase all of the participants 'bid' on a token. Whoever gets the token has permission to transmit during that round. If collisions have been occurring, the participant holding the token can demand that everyone reveal their flips. I think there is a paper describing a protocol for this, but I don't have access to a library with crypto material. The protocol for distributing the token would be somewhere between an All-Or-Nothing-Disclosure-Of-Secrets and a poker card dealing protocol. Only one person should be able to get the token and nobody should know who got it. To make it more complicated, for people to be able to transmit in a timely fashion, you should be able to specifically request the token when you want it (so you would have a 1/n chance of getting it with n being the total number of participants wanting to transmit that round), and not have any chance of getting it when you don't want to transmit. In addition the generation of the token(s) should be secure so that none of the participants have to trust anyone that only one participant can get a valid transmit token. I can think of a way to do this with a mental poker protocol. The only problem is there is always a 1/n chance of getting the transmit token (where n is the total number of participants), whether you want it or not. I believe it also requires some trust in the 'dealer'... Anyway, the deck would consist of 1 transmit token and n-1 blank tokens. Immediately after the transmit phase the participant holding the token can optionally demand that everyone reveal their flips. To do that the participant would reveal their valid transmit token. At that point everyone else would reveal their blank transmit tokens (to make sure there are no duplicates). If anyone refuses to reveal their blank token, they are removed from the net. Once it's been determined that there is only one valid transmit token, everyone reveals their flips. In theory all of this stuff would work, but implementing it is a different story. For a DC net to be practical, it would have to run completely without human intervention. Maybe a client could be placed in your .login or shell rc file and would run in the background whenever you were logged in. It could keep running after you logged out if you had a message in your queue to be sent out. Clients must be smart enough to synchronize rounds and remove participants who aren't responding fast within time-outs, etc... automatically attempt to 'lay a trap' when collisions have been occurring, figure out who is disrupting or not following protocol and remove them or alternately have the client drop out of the DC-Net when protocol hasn't been followed to satisfaction (duplicate tokens in one round, etc...), etc... Quite a tall order, and for how much more untraceability than the current remailer system? Even if it is implemented you still have to get people to use it. The current remailer system can be used with no software whatsoever... Still, it's an interesting prospect, as it offers real sender and receiver untraceability within the group of participants. But is it worth it? (apologies for the length...) andrew