More Applications For Hashcash

Anon writes: "Although the use of HashCash has been featured before, Adam Back has recently (August 1st) published a paper about it, outlining many other applications for the mechanism. Quite an interesting read. It seems the guys at camram have been working on a standard for use in e-mail too."

Comments

HashCash software

[Delta]

HashCash can be used to solve a lot of problems with publicly available resources and services, but in order to get the full gain from such techniques there needs to be software and libraries available which allows easy integration of HashCash techniques.

Does anyone have any good resources on HashCash source code or other things to aid development?

Old News?

[Halloween Jack]

This was first proposed in 1997. If it can work, where is it?

Slow acceptance if ever

[cybermint]

Although interesting, I have doubts this will ever catch on because of it being so different from the current way mail is sent. Maybe the changes would not be openly visible, but I don't like the idea that my computer may have to use extra cycles just to send a letter. If this would end spam then I would consider this a worth while, but it most likely would not; at least not for a long time.

Because the currect mail systems do not have this system in place, it may be doomed to failure because of the aspect of backward compatibility. This article posted today on slashdot says that 99.9% of all websites are obsolete because of backward compatibility. As a developer, I too am guilty of programming for browsers as low as IE4 and Netscape 4. This problem alone could cause it to take several years to catch on, if ever.

The hashcash proposition is somewhat dangerous

[hillct]

I have a problem with the basic proposition of hashcash. It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?

The entire premise seems ridiculous. Granted the system might work in small controlled enviroments where the overall inefficiency it introduces into the network would be limited, but if you read the proposal, you'll see that of course the system wouldn't work at all unless it was adopted on a large scale, so, while it's certainly a novel idea, I don't see how it could possibly succeed.

--CTH

Re:The hashcash proposition is somewhat dangerous

[Anonymous Coward]

Yet another complete utter false rumor perpetuated by a /. zombie. Also completely missing the point, even if DVORAK was better, of why QWERTY "won" in the first place (as it obvioulsy bears no relation to the situation your commenting about in any way)

There should be an intelligence test before being allowed to post, and a re-test every couple weeks to make sure you haven't recently had your head in a blender.

Re:The hashcash proposition is somewhat dangerous

[nestler]

It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?

Yes, because the current system is more dangerous.

Requiring the solution to a computationally intensive puzzle is a common technique in denial-of-service prevention, especially in protocols where the amount of computation is already lopsided.

For example, SSL servers are an easily DOSable target because the server does lots more work (RSA decryption) during a handshake than a malicious client does. One solution to this problem is a protocol modification that requires the client to answer a "puzzle" of the server's choosing. This is no problem for a legitimate client making a few connections, but it keeps out the guy trying to DOS the server with thousands of connections.

It's the same thing with spam. It's too easy for a spammer to make mail servers pass around huge spams to thousands of people on their behalf. But if the mail server required the spammer to answer a "puzzle" (hashcash) for each copy of the message sent, that would make the spammer's life much harder without making the legitimate mail sender's life that hard.

Think about mistyping your password at the telnet prompt. Telnet intentionally waits for a few seconds before letting you retry to make it harder to brute force. It doesn't kill you to wait a few seconds, does it? It's the same concept.

You are right though that it has to be adopted on a widespread basis or the spammer just goes to the relay that doesn't use hashcash.

Re:The hashcash proposition is somewhat dangerous

[sketerpot]

I don't see the problem, except perhaps on mailing lists. It would take more processing power to send email, so ISPs might have to upgrade some hardware, but in general I think it could work if it were adopted by enough people. And it would prevent mass spamming of gigantic amounts of people. You have a problem with this?

Re:The hashcash proposition is somewhat dangerous

[Adam Back]

The point about introducing inefficiency is to introduce a cost for the sender.

It's like junk faxes: in countries with free local calls, junk faxes are a much bigger problem than they are where local calls cost the caller.

Similarly for being called on cell phones with by marketers. In some countries calling a cell phone is free for the recipient and all costs are on the caller.

So while it is true that hashcash would use some CPU on the client, the amount of CPU used would be small enough to not present a noticeable problem for the sender who sends some sane number of mails per day.

The problem as I see it is deployment, as the first message in the thread "Slow acceptance if ever" puts it. ie If I use a hashcash filter on my received mail then I may lose mail if senders don't follow whatever steps are necessary for them to get their mail to me.

This is what the camram list is about -- making it reasonable for senders to send mail to people using hashcash filters, when sender has no client. For example there is a proposal to require hashcash only on the first mail, subsequent mails would be exempted. There is a simple web page with a java implementation of hashcash.

(The are proposals to deal separately with mailing lists where the recipients wants to receive the mail, and the list has to send lots of mail).

Another approach to reduce the deployment problems is to do it in two phases. In phase 1 hashcash filtering is advisory only (bounce messages on mail having no hashcash if any would just encourage sender to participate but not reject mail; filtering would improve priority of mail, not delete mail without postage); in phase 2 if phase 1 was succesful enough the filters could start bouncing mail without postage.

Will any of these approaches reach sufficient deployment to be useful? I don't know. That's what the camram group are working on.

There are also other applications of hashcash (other than email spam) in combatting DoS which have been succesfully deployed (see the paper).