Open oskarth opened 5 years ago
I think there are basically three directions how to have spam protection:
I would prefer the third direction because:
I agree staking schemes would be desirable. It also means you can have both staking and non staking entity, then sort by some metric, which leads to graceful degradation/interop with other ecosystems.
Staking assuming it's simple and cheap enough to get the necessary information. Any thoughts on slashing conditions and griefing factors?
There are two very separate issues here:
SPAM: If we adopt my "contact point" vs "aggregation point" design, or any modern design, then SPAM protection is almost automatic, except for "new contact" SPAM from any publicly representable address. In fact, the SURB based design naturally limits this, but if we should prevent overloading by providing some "filter". We should eventually provide an "introduction" mechanism to bypass the "new contact" overload filter, as SURBs lend themselves to this. As for the filter itself, we should have all individual presentations of publicly representable addresses contain a unique identifier, so that SPAMers must obtain the same address numerous times.
DoS: There are numerous tricks for hardening the network against DoS attacks without touching the mixnet layer, but ignoring those one might further subdivide in network border vs internal protections, and how they interact. We do not need anything as heavy as SNARKs for this, but rerandomizable certificate schemes help because they apply equally at the network border and internally. In particular, Coconut has some backers in the Panoramix community. I see two concerns:
I think proof-of-CPU-work does not help address any issues here.
A priori, proof-of-stake is not user friendly since users are unwilling to spend any resources on anything. In principle, we could make proof-of-stake work with centralized resources like phone numbers, so what WhatsApp, etc. do, but this tends towards centralized infrastructure. We could "disconnect" from that centralized infrastructure if the messaging program pays users for correctly generating their cover traffic, but this still ultimately requires some proof-of-stake from users.
A priori, proof-of-stake is not user friendly since users are unwilling to spend any resources on anything.
This is absolutely correct. But I would argue here from another perspective and compare this with "offline" communication. For example, when you want to talk to somebody or meet this person in person, then you will have to invest some money for public transport and additionally some amount of time to get to the that person. That concept acts as a "natural" spam protection. It might be wise to adapt it when building a spam protection for a messaging protocol.
I'm unconvinced that incentivization can charge enough money to prevent SPAM because cover traffic combined with low fees means SPAM costs very little.
Understand what attack vectors are possible here, study prior art and write up trade-offs / justification for given choice.
Some raw notes: