[hashcash] Re: PR Problem?

DeLesley SpamBox wrote:


I'm not convinced that even a naive sender pays wouldn't be helpful.
Let's say I use a cheap stamp that takes an average of 1 second to
generate on a mid-level PC.  This shouldn't be too onerous on most
hardware, with the possible exception of PDAs.


http://camram.org/zombiecalc
make assumptions about the number of zombies, how much leakage you will permit and you can get the stamp size. It's quite entertaining. 



If the average zombie is putting out more than 1 spam per second, then
adding a stamp makes the spam output go down.  If a spammer has to
invest in a few more quad-core servers to make stamps, then costs go
up.  Maybe the spammers aren't out of business yet, but at least they
are making less profit, and putting out less spam.  All the criticisms
I've read treat the problem as an all-or-nothing affair: if HashCash
can't guarantee that all spammers go out of business, then it's not
worth implementing.
you are falling into the classic trap of assuming that the cost of hardware mean something. This is the fallacy behind the Ben Laurie paper. It's important to remember that the cost per stamp drops with every stamp generated with a given piece of hardware. The first step is very expensive if that's all you generate about if you are cranking out stamps to the tune of 1440 stamp minutes per day, the cost per stamp drops really fast.
You do have the right angle though in that stamps reduce spammer profitability and at some threshold, they won't make enough money to stay in business. The number of zombies will decrease and be more easily targeted. 



But this is a foolish way to think about it.  Naive proof-of-work is
dead simple to implement.
Compared to other proposals, the cost of implementation is almost
zero.  So there doesn't have to be a lot of benefit before the
cost/benefit analysis makes sense.
actually does. The cost of implementing hash cash is trivial. It's been done. But the cost of transition is very high and you need backwards compatibility so that those who are still running with sendmail 5.x or Eudora 2.0 can play along or at least not be penalized.
So if we're going to transition people, we want to make sure it's a high-quality transition with lots of value through increased reliability of good e-mail delivery and low overhead of maintaining their filters. 


Moreover, proof-of-work integrates well with existing spam filters.
Stamped mail shouldn't be allowed to bypass the filter altogether,
because then you really -do- need to put the spammers completely out
of business in order to make things work; I don't want my inbox
flooded with zombie-stamped spam.  Instead, just treat the stamp as
another piece of data that's input into the learning algorithm.  The
filter will learn how much postage spammers are willing to pay, and
filter mail accordingly.
this is probably a philosophical disagreement. I absolutely of abhor false positives. I look in the dumpster maybe once every couple of months if somebody tells me something was lost. I look in my spam trap about once a week. If somebody is going to send me a message with a stamp, I have no problem with it coming through directly. If it's a spammer, I want to be able to mark it as spam and then permanently blacklisted IP address and tell all of my friends about it automatically.
to use a stamp or even a stamp size as a scoring factor actually works in the spammers favor. By crafting a message the right way and just putting a little stamp, maybe 10 seconds worth, they would be able to almost guaranteed delivery. While at the same time, you would still end up subjecting legitimate users to the risk of mischaracterization of their messages. That is not a win. 


My guess is that at least at least 50% of all e-mail would have to
start using stamps before the spammers even bothered to calculate
their own.  The target market for spam is gullible and
non-technically-minded people, not careful e-mail users with
sophisticated anti-spam technology.  That means that HashCash users
could start seeing significant benefit for several years before the
spammers caught up.
this is another reason for direct delivery on stamps. Your stamp is an introducer. It guarantees delivery to the inbox. This is a win. This mean customers don't have to worry about their mail getting through.
Which raises an interesting demo for businesses. With the Java stamp generator in a webpage, you could create a method of generating stands for ordinary e-mail when communicating with a business using proof of work stamp gateways.
With the stamp generator, it would be possible to create a mailto entry with a stamp. I don't know if the mailto will let you create new headers but, even if it doesn't, sticking the stamp in the subject line might not be such a bad idea for delivery.
there are a variety of ways of presenting this information to the user but the important thing is they would introduce the concept of stamps and people could become accustomed to the concept. The only downside is that the spam generation process would be in the foreground and therefore there may be some bad PR from that. 




Once proof-of-work systems start to see serious adoption, and spammers
respond with zombies, then we can start the move to more sophisticated
hybrid systems.  It's good to know that bright people are thinking
about such systems, and have possible designs in mind, but I don't
think we need "The Solution(TM)" to start an initial rollout.
remember, transition costs are really expensive. We want to do it good enough that we can survive some of the zombie attacks and that will give people more confidence in our technique than just a simple brute force bloody ignorance approach of naïve sender- pays.
Also remember that a hybrid system is not necessarily expensive. A hybrid system on output is a series of predicates deciding whether to generate stamps or not. If I was clever, I would figure out how to do plug-ins or dynamic add-ins for the predicates in Python and that way we could roll out new predicates as we come up with them for twopenny blue or any other system using the same plug-in technique. But no, I'm sorry to say that I am not that clever but I am willing to learn. 




I do agree that hybrid proof-of-work systems are the best way to
eliminate spam in the long term, simply because they have the most
potential for tweaking and improvement.
However, a hybrid proof-of-work system is a wonderful example of a
Complex Adaptive System.  Detailed analysis and modeling of such
systems is enormously difficult, especially if humans (spammers +
users) are part of the loop.  It will be much easier to improve the
system if there is actual data from HashCash users on the 'net to
analyze.
as I said above, they're not necessarily expensive. Plug-ins would make it easier to adapt. Feedback loops are essential and yes those are complex adaptive systems. But you know, what I have worked. I have three years experience with the system in the field. Granted that's only a few sites but they are seeing significant benefit.
I'm hoping to find someone who knows enough Perl that they could modify a rdd framework displaying mailfilter statistics. I would love to have a grass that I can point people to saying "see, this is how the friends list works, this is how the spam filter works etc. etc." but I haven't found anyone yet. And I have not enough time or energy to dive into that particular part. 


If you add on top of that the idea that a DNS record...


But this requires a change to the DNS service, which means much higher
cost of deployment.  It's a great idea, once there is a large enough
user base to make it worthwhile.


esj@camram606:~$ host -t txt harvee.org
harvee.org descriptive text "hcrv=0:hcsv=1:bits=26:vwin=5d"
here's an example of what I meant. I don't remember what the fields were at least the first two I think they may have been something like camram version and stamp version if memory serves. But this is the basic text record. Now there may be other things we need to do because of collisions with text records used in other contexts so we might want to create a standard domain name form. But, it's not complicated. And it has the added political advantage that it further reduces "unnecessary" stamp generation.
Remember the primary emotional objection is that they don't want to spend their time generating stamps. Doesn't matter how or why they just don't want to spend their time because they don't believe it will do any good. So, when I counter that with a what if I minimize stamp generation, the susceptibility factor goes up but they can't wrap their head around how intermittent stamp generation can improve things. Then I shake my head and mutter something about bad at math.
So, the political/emotional landscape says we must reduce stamp generation whenever possible. 




If you are skilled in making a Thunderbird plug-in, then by all means,
build a stamp generator and output in a filter that detects outgoing
stamps and not generate any additional stamps.


If I was familiar with the Thunderbird code base, I could probably
write a plug-in in a couple days.  Unfortunately, I'm not -- which
means I could easily spend a couple months deciphering APIs.  I'll
take a brief look and see how hard the problem is.
consider a different solution. What would it mean to create a proxy. I believe I have the pieces you would need for an MTA independent Macintosh/Windows stamping proxy. Inbound filtering via Pop three, that's much harder. That's really really much harder. 


so I think the real answer to your question is, we're exhausted.  We
don't have enough people doing real work to make demonstrably functional
code in this area.  I've done the best I can and I'm not going to make
any apologies for it.


I certainly wasn't asking for an apology!  I have nothing but respect
for anybody who devotes time and energy to solving a real problem.  I
reserve my contempt for naysayers who spend 5 minutes thinking up an
objection, and then stand in the way of progress because they think
that they know more than the actual researchers.  :-)  It seems to be
a popular occupation... :-(
here's another idea for proving the concept. I will donate my time and energy to set up a twopenny blue mail system if somebody else will donate their time and energy to set it up for a "free" e-mail service for people wanting to experiment with this kind of anti-spam environment. I think we'll also need somebody to donate hosting. I really don't want responsibility for this in my basement. I don't have my autostart generator yet.
This would allow us to get started. We would probably need a few other machines to generate stamps as a captive zombie net unless, we add the predicates which say if you don't advertise you have that capability, we don't generate stamps.
I also have this gut feeling that using SMTPAUTH authenticated connections, we could act as a remote filter for entire domains but setting up the accounts might be a bit problematic given the requirements for uniqueness. Need to think about that one.
So, is anybody going to step up to the plate and make me regret volunteering my time?

Other related posts: