Comment by SchemaLoad
2 days ago
There was a project called Bitmessage which solved this problem by not having a recipient field. Your client would just try to decrypt everything, and when it succeeds, that means the message is for you.
The then immediate issue is routing becomes very inefficient since every node now needs to receive and attempt to decrypt every single message. Which they solved by having channels to split up the network and only require decrypting of every message on the same channel as your address.
Can an adversary detect who's sending a message, though? If they can observe 2 parties alternately sending messages into the network, they can probably assume these 2 parties are talking to each other.
The next step would be nodes sending random fake messages into the network at random intervals, to obfuscate who's talking to whom.
If you controlled almost the entire network you could see where a message showed up first, but you wouldn't know where it was going. And since the app was mostly desktop only and kind of slow to deliver it would be used more like email where it could be hours before you see a response.
So maybe kinda but you don't have a lot to work on. And nodes don't have persistent IDs so if they were on a VPN, CGNat, dynamic IP, you'd have a hard time tracking them over time.
That sounds easy to DoS.
You're right, which is why they used Proof of Work as a requirement of sending a message. Problem is it made sending messages on mobile kind of bad since any PoW which would stop a desktop GPU from spamming is too much for a phone SoC.