Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC1974: Crypto Puzzle Challenge #1974

wants to merge 1 commit into
base: master


None yet
4 participants
Copy link

commented Apr 24, 2019

Crypto Puzzle Challenge

Proof-of-Work rate-limiting, via cryptographic puzzle challenge, to fight spam.


New Errors:

    • extra field seed (String)
    • extra field bits (Integer)
    • extra field algorithm (String bcrypt)

New Headers:

  • X-Matrix-Puzzle
    • seed:bits:algorithm:n - where n is an integer
    • When this header is hashed with algorithm is must produce at least bits many leading zeros

In response to a request, the receiving party may error with a M_PUZZLE_NEEDED challenge, which requires a crypto-puzzle be solved and request re-submitted with proof-of-work attached as X-Matrix-Puzzle.
The puzzle is solved by incrementing n and re-hashing the header using algorithm, then checking for leading zeros.

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 bits to 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.

bcrypt is 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


This proposal provides a powerful spam-fighting mechanism which relies on compute resource consumption.

Signed-off-by: Zolmeister

@Zolmeister Zolmeister changed the title MSC0000: Crypto Puzzle Challenge MSC1974: Crypto Puzzle Challenge Apr 24, 2019

MSC1974: Crypto Puzzle Challenge
Signed-off-by: Zolmeister <>

This comment has been minimized.

Copy link

commented Apr 24, 2019

Is this intended for client-server interactions, server-server interactions, or both?


This comment has been minimized.

Copy link

commented Apr 24, 2019



This comment has been minimized.

Copy link

commented May 22, 2019

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?


This comment has been minimized.

Copy link

commented May 22, 2019

@JJJollyjim Excellent points, battery life added to issues
That's also a strong argument for specifying a correct mode of operation for when to serve the error.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.