Join GitHub today
MSC1974: Crypto Puzzle Challenge #1974
Crypto Puzzle Challenge
Proof-of-Work rate-limiting, via cryptographic puzzle challenge, to fight spam.
In response to a request, the receiving party may error with a
Inspired by Hashcash
The original Hashcash is not a request-response challenge but instead only opt-in by the sender. This allows for pre-computation and does not allow dynamic
Giving clients free-reign over when to use the error and how much work they require could lead to some unintended consequences.
E.g. If the major server implementations use too high values as their default then it might force out low-end hardware altogether (and make running your own server potentially costly (in CPU time), decreasing decentralization).
Client battery will also be severely impacted if puzzles are overused
This proposal provides a powerful spam-fighting mechanism which relies on compute resource consumption.
Signed-off-by: Zolmeister firstname.lastname@example.org
A major consideration you don't mention here is power consumption, both from the perspective of an end user ("I have to use whatsapp instead of riot because riot kills my battery") and from an ethical perspective: ("whoops, matrix now uses more energy than a small country").
Sticking to the first point, is it really possible to pick a difficulty such that a user on a low-end smartphone or a tiny microprocessor on a battery-powered IoT device sees no impact, while an attacker with desktop GPUs (or worse) is severely impeded?
Overall, I can't really see the need for this: can you explain how your proposal solves problems that traditional "come back in ___ seconds" rate limiting (based on IP or user account) doesn't?
@JJJollyjim Excellent points, battery life added to issues
Perhaps the biggest difference from "come back in ___ seconds" is the ability to rate-limit initial connections. For example the first connection from an unknown IP address / user. This makes this method significantly stronger against distributed attacks using multiple IP addresses.
I suspect that IoT devices would use a federator that did not challenge them with a PoW. Otherwise this may actually be a positive given the threat of IoT botnets.
I posit that even a small proof-of-work would deter spammers in favor of a cheaper target.