[hashcash] Re: response to "proof of work proves not to work"?
From: "Eric S. Johansson" <esj@xxxxxxxxxx>
To: hashcash@xxxxxxxxxxxxx
Date: Mon, 17 Jul 2006 14:14:51 -0400
Adam Megacz wrote:
Did you publish your analysis? Even informally? If you have a
well-written rebuttal paper that's as detailed as theirs I will
certainly point people to it.
I looked around and couldn't find the draft but it shouldn't be hard to
spin another one. As I said in my other post, the basic argument is
that they used the wrong metric of cost. Yes, if you purchase a piece
of hardware, and generate an infinite number of stamps, the average cost
per stamp will drop with respect to time. Or, the first stamp is the
most expensive in all the rest come for free.
The real cost is the difference between unencumbered spam generation
versus stamped spam. Determining this real cost is difficult but it's a
function of the number of resources the spammer has to apply to the
problem.
The number of resources determines visibility which in turn determines
revenue. consume more of the resources and you drop visibility which in
turn drops revenue.
They raised a valid point about cost to the service provider and there
are a variety of ways of reducing the cost which they ignored. The most
common one is the "send one stamp first" technique which generates one
stamp on the first message to any destination address. The addresses
than white listed so, in theory, the recipient doesn't even need a stamp
to respond. I've currently implemented a bidirectional first stamp
system but as I've pointed out, that's not even needed. So here's a
little technique that would decrease the stamp load on service providers.
The second technique would be literally building a captive zombie farm
out of the user base. That if a user shut off too quickly or was using
dial-up, the stamp would be generated by somebody else. But at the same
time, when they were connected, they would be generating stamps for
others. It would probably need some form of tit-for-tat or leach
detection but it's not entirely outlandish.
One of the big problems in doing modeling is that you need to make a
bunch of assumptions. For example, if you assume that messages to new
addresses are relatively rare and only show up in 5% or less of your
e-mail, then ISP level stamp generation is not totally impractical.
Obviously ISPs are resistant to dedicating any sort resource to
producing heat which is why it's imperative to build a captive zombie
farm mechanism and agreement.
so, I will try to generate a paper in the next month highlighting this
model of stamp usage and why it has relatively low load. Then I'll
append to it a summary of rebuttals to the proof of work doesn't work paper.
if folks are willing, which is representing this at different
conferences start spreading the idea again.
It occurred to me the other day when I was talking with a friend, not
the right way to push our technique and show folks that it has merit
would be to develop a "no spam" e-mail service provider. But in order
to do so, we would need a highly automated system, maybe leverage off of
an existing ISP, client-side stamp generation, camram or its equivalent
acting as a filter plus stamp requester and a magic button people could
push to say "this is spam". The magic button be the need to be a
drag-and-drop on the desktop or a customized tool which would reach into
local mailboxes and drag out spam.
I should point out however that we need people to write code. It's not
a lot of code. But it's very specific code. but without this code,
sender-pays via hash cash won't go anywhere.
