[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.


Other related posts: