Posted by
timothy
on from the to-stem-the-tide dept.
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."
This was first proposed in 1997. If it can work, where is it?
--
I looked into the abyss, and the abyss looked into me--and we both winked.
Anti-Hashcash
by
Animats
·
· Score: 4, Interesting
What a sink for CPU cycles!
The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.
I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with. "When the only tool you have is a market, everything looks like a commodity". Sometimes, the accounting overhead costs more than the thing is worth.
We need a solution to spam, but this isn't it.
There really aren't that many spammers; put fifty people in jail and it will stop.
The hashcash proposition is somewhat dangerous
by
hillct
·
· Score: 5, Insightful
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.
Re:The hashcash proposition is somewhat dangerous
by
nestler
·
· Score: 4, Insightful
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:HashCash software
by
Adam+Back
·
· Score: 4, Informative
there is some library and command line tool source available at:
http://www.cypherspace.org/hashcash/source/
also there is a windows gui version and a java applet version which is kind of "clientless" for people with java browers. (The camram group are using the java version for senders who don't have a hashcash client).
http://www.cypherspace.org/hashcash/
advantages over tarpits?
by
EricHsu
·
· Score: 4, Interesting
Many of the proponents of this idea suggest that the advantage is creating a non-trivial cost for access to resources.
Can someone spell out the advantages this method has over the "tarpit" strategies that some mailers follow? (I.e. each successive access takes longer, so the first access may take 1 sec, the next 2 sec, the next 4 sec, so soon abusers find themselves timing out.)
Is it fair to consider tarpits a special case of hashcash where the non-trivial cost is time waiting applied server-side?
If so, isn't this a less wasteful approach? (Genuine questions on my part.)
Slashdot Mirror
To prevent spam I ask for the solution of a difficult math problem before I give my e-mail address. I haven't had a date since then.
This was first proposed in 1997. If it can work, where is it?
I looked into the abyss, and the abyss looked into me--and we both winked.
The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.
I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with. "When the only tool you have is a market, everything looks like a commodity". Sometimes, the accounting overhead costs more than the thing is worth.
We need a solution to spam, but this isn't it. There really aren't that many spammers; put fifty people in jail and it will stop.
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
--Got Lists? | Top 95 Star Wars Line
there is some library and command line tool source available at: http://www.cypherspace.org/hashcash/source/ also there is a windows gui version and a java applet version which is kind of "clientless" for people with java browers. (The camram group are using the java version for senders who don't have a hashcash client). http://www.cypherspace.org/hashcash/
Can someone spell out the advantages this method has over the "tarpit" strategies that some mailers follow? (I.e. each successive access takes longer, so the first access may take 1 sec, the next 2 sec, the next 4 sec, so soon abusers find themselves timing out.)
Is it fair to consider tarpits a special case of hashcash where the non-trivial cost is time waiting applied server-side?
If so, isn't this a less wasteful approach? (Genuine questions on my part.)