MSC1974: Crypto Puzzle Challenge#1974
MSC1974: Crypto Puzzle Challenge#1974Zolmeister wants to merge 1 commit intomatrix-org:old_masterfrom
Conversation
Zolmeister
changed the title
Signed-off-by: Zolmeister <[email protected]>
|
Is this intended for client-server interactions, server-server interactions, or both? |
|
Both |
|
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. |
turt2live
added
the
needs-implementation
I think that could be solved by servers only asking for a proof of work when connecting for the first time or when sending the first few messages. Normal users don't join a server all that often, so it shouldn't cause much of an overhead. However, lots of spambots these days will join a lot of servers and immediately send a lot of spam messages. With a proof of work approach, that would make sending spam more costly. |
5 participants
Crypto Puzzle Challenge
Proof-of-Work rate-limiting, via cryptographic puzzle challenge, to fight spam.
Proposal
New Errors:
seed(String)bits(Integer)algorithm(Stringbcrypt)New Headers:
seed:bits:algorithm:n- wherenis an integeralgorithmis must produce at leastbitsmany leading zerosIn response to a request, the receiving party may error with a
M_PUZZLE_NEEDEDchallenge, which requires a crypto-puzzle be solved and request re-submitted with proof-of-work attached asX-Matrix-Puzzle.The puzzle is solved by incrementing
nand re-hashing the header usingalgorithm, then checking for leading zeros.Inspired by Hashcash
Tradeoffs
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
bitsto be requested (necessary as computers get faster) or a change in algorithm (again, necessary because of dedicated hardware (ASICs)). Though it could be made viable by re-specifying these in the Matrix spec.bcryptis used here but there are other options e.g.Argon2d,scrypt. bcrypt was chosen because it's popular (and thus most software ecosystems should have a package for it) and because it is hard to parallelize on GPU/ASIC hardware.Potential issues
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
Conclusion
This proposal provides a powerful spam-fighting mechanism which relies on compute resource consumption.
Signed-off-by: Zolmeister [email protected]