Hi and thanks a lot for all the additional info!
Regarding follow up discussions on the 2022 paper – would be better to transfer it to email (please do include my co-authors (piyushks@umich.edu and dgosain@cse.iitb.ac.in) as it’s a bit off-topic in this thread, and also Piyush and Devashish did all the implementation/experimental work so they are better positioned than me to go into the weeds of the experiments.
About the spies, that’s a tough problem! if the spies are really smart they may be able to stay undetected since these are passive attacks. However if they made some mistake or tried used multiple nodes running in the same place, well, removing or avoiding them seems a sensible thing to do (but they may come back better hidden though).
I haven’t had the time to look into Clover so I can’t say anything smart about it – though from what you say it seems an improvement over D++. What I can share is my general take on p2p anonymity designs. In my view such designs have inherently some shortcomings when used for network anonymity:
(1) conflation of roles: every peer is both a “user” (originating txs) and “infrastructure” (relaying txs for others). I believe this leads to a tension between privacy and service integrity / accountability. As user you want privacy, and thus prefer to not reveal information; while wanting to verify (to the extent that is possible) that the infrastructure routing your messages is doing so reliably and correctly. If peers reveal “more” of what they do, they may undermine their own privacy, while if they reveal “less” it may be hard for others to see that they are doing their job correctly. In that sense, I believe that client-server architectures, with distinct roles, are less problematic, as you now have two classes of entities each with its requirements (users want privacy while infrastructure should be as verifiable as possible).
(2) thin traffic and vulnerability towards network adversaries. If peers generate, say, 1 tx per minute, and every tx is routed via 10 peers, then each peer is routing on average 10 tx per minute. This means that there is little “aggregation” of traffic, which is beneficial for creating large anonymity sets. In contrast, in a client-server architecture you can potentially have thousands of packets (from thousands of users) mixed together in a server, making it hard to trace packets every time they go through a node. Furthermore, note that in p2p designs, an adversary observing the i/o of a peer can typically tell if the node is the originator of a tx: if nothing was recently received, and something is sent, chances are this is a new tx originated by the peer. Note that the “thin” traffic makes this easier (if the peer was routing thousands of txs it wouldn’t be so easy to tell, but in a p2p design that would require very long routes) .
That said, p2p designs are great for having decentralized functionalities (such as payments). I am just not too convinced that they are the best approach when it comes to network anonymity. That’s my 2 cents.