I've done a crappy implementation for my blog to fight spammy comments. It works OK, probably more because it's a totally custom thing that isn't worth time for spammers to fight, rather than because it's actually effective.
The way I did it is:
- When the user focuses in a comment field, the page makes a request to the server asking for initial parameters.
- The server returns the number of leading zeroes required, the number of distinct hashes it needs, and a salt to use. (This is just a constant in my code right now, but could be varied based on client specifics.)
- The page then crunches on the work as the user types their comment. The submit button is disabled until it's complete.
- The proof of work is submitted to the server along with the comment. The server then checks to see if it's good and accepts or rejects. A properly working client should never be rejected (since it fetches the required parameters in advance) so the rejection doesn't have to be too fancy.
- Replays are prevented by storing the salts in a database, and deleting them once they're used for a comment.
I changed the standard hashcash technique a bit by requiring the client to submit multiple distinct hashes. Requiring only one hash works fine, but results in a lot of variance in how long it takes to compute the proof of work. You might tune it for an average of 30 seconds, but a decent percentage of clients will get it in 1 second, or will take 60 seconds. By, for example, requiring 7 fewer leading zeroes but requiring 128 distinct hashes, you get the same average but with a lot less variance. You can also display a semi-accurate progress indicator this way. The downside, of course, is that you have to send more data and the server has to do some extra work to verify.
My web site is a hacked-together thing that's been gradually accumulating since the late 90s, so it's kind of ugly. The hashcash code is not very modular, either.
If you'd like to see it anyway, I pulled out the relevant parts here:
The comment-inline.js file is directly embedded in the HTML for the comments area, and is the glue code between the actual UI and the hashcash computation code. The hashcash.js file is where all the client-side work happens, and it handles the actual hashing, making multiple attempts, checking to see if an attempt produced a good result, and such. Then commentsubmit.py handles the server side by returning hashcash parameters when requested, and checking the provided hashcash for validity when submitting.
I have a brief blog post about it here, which you can also use to see the system in action:
The way I did it is:
- When the user focuses in a comment field, the page makes a request to the server asking for initial parameters.
- The server returns the number of leading zeroes required, the number of distinct hashes it needs, and a salt to use. (This is just a constant in my code right now, but could be varied based on client specifics.)
- The page then crunches on the work as the user types their comment. The submit button is disabled until it's complete.
- The proof of work is submitted to the server along with the comment. The server then checks to see if it's good and accepts or rejects. A properly working client should never be rejected (since it fetches the required parameters in advance) so the rejection doesn't have to be too fancy.
- Replays are prevented by storing the salts in a database, and deleting them once they're used for a comment.
I changed the standard hashcash technique a bit by requiring the client to submit multiple distinct hashes. Requiring only one hash works fine, but results in a lot of variance in how long it takes to compute the proof of work. You might tune it for an average of 30 seconds, but a decent percentage of clients will get it in 1 second, or will take 60 seconds. By, for example, requiring 7 fewer leading zeroes but requiring 128 distinct hashes, you get the same average but with a lot less variance. You can also display a semi-accurate progress indicator this way. The downside, of course, is that you have to send more data and the server has to do some extra work to verify.