Re: [Asrg] Re: "HashStamp" == hashcash? (Re: Stamping)

[Steve Schear <[e-mail]>]

At 08:16 AM 3/23/2003 -0700, Vernon Schryver wrote:
>Steve Schear <[e-mail]> wrote:
> > You're still, I think foolishly, focused on an ISP-oriented
> > solution.  Sender-pays makes them most sense when the client SW is 
> capable,
> > if not singularly empowered, to enforce the payment mechanism at the
> > receiving point.
>
>Ok, but what about the main question?  What is the minimum speed CPU
>that you will allow to send mail?  Do you expect everyone from now on
>to buy equal speed CPUs?

"Allow"?   Stamps will in all probability be "sized" at 
60-600GHz-seconds.  Whether someone is willing to tolerate this process 
delay is one based on CPU speed, patience and importance of the email.

>How else do you ensure that the spammers
>don't have CPUs that are 10,000 times faster than spam targets?

Why would it matter?  The hashcash stamp generation process is highly 
asymmetric.  Stamps generated through many GHz-seconds of effort can be 
speedily authenticated by even cellphone or PDA level machines.  Even stamp 
generators constructed from state-of-the-art ASICs are unlikely to make 
stamps more economically than a cluster of x86 blades.


> > >There are reasons why after at least 6 months the hashcash proposals
> > >are still only ideas.
> >
> > The reason is mostly that there are lots of arm chair generals but fewer
> > competent programmers.
>
>I can't disagree; standards committees, netnews groups, and bars are
>always filled with non-players eager to tell the players how to play.
>However, a willingess to admit and deal with fundamental design problems
>such as the span of real CPU speeds is part of being a competent
>programmer.  At the end of the day, competent programmers are those
>who have programmed competently.  How is your sender-pays implementation
>working?  How much of your incoming mail is sender-paid, and how much
>is simply whitelisted?  (If I'm confused about which solution you have
>implemented, please forgive me and say how it is working.)
>
>Only about 1% of the spam sent my way gets through my filters, but I
>must admit that the DCC is applied to only the leavings of my static
>filters.

The following is an edited version of cross-posts from "Eric S. Johansson" 
<[e-mail]>, Camram's primary developer:

One of the systems proposed in camram is to switch from proof of work 
stamps to signed messages once you have been properly introduced. This some 
write-ups on this on the camram site but it's kind of obscure because the 
idea wasn't well thought out when I wrote it. The paper at 
http://harvee.org/camram/ is somewhat more illustrative but it's not fully 
documented yet. That is yet another way folks on the cypherpunks lists can 
help. Work out a system by which message has an embedded public key and the 
key is considered "good" after some introduction process involving two 
parties e-mailing each other. Then figure out how to deal with new key 
introductions if the original key has been lost to accident or deliberate 
action. It's a hoot. ;-)

it is safe to assume that these keys will not have any pass phrases because 
this is a crypto system totally invisible to end-users. Argue with me on 
the no pass phrases requirement directly if you wish.

the camram protocol can be embedded: at the client, or at the server. I 
have a mostly working version at the server and could use some help with a 
few things (see end)

one thing folks aren't too aware of is that I have incorporated a Bayesian 
style filter into the camram environment in order to reduce the number of 
"postage do" notices. As many folks justifiably point out, if you don't 
eliminate the need for a "and then the universe changes" step, you won't 
get out of starting gates. The addition of a filter to discriminate e-mail 
into three categories (red/yellow/green) allows me to reduce the number of 
challenge messages to a small fraction what they could be. The feature that 
implements "and friends fly free" allows you to build your communications 
map and reduce the need for stamps in either direction. Again, this works 
at client side or server side.

>What I want is
>- a Eudora plugin to check for hashcash stamps, send bounce messages, auto 
>generate my hashcash stamps, and help create and maintain my white list.
>- a web site which offers a hashcash stamp generator applet and simple 
>instructions for

Figure out how to make Eudora interface with Python code and we are most of 
the way there.

what we have done:
- basic filter sequence consisting of stamp, white list, postage due 
response, basic template
- a stamp generating SMTP proxy prototype.
- spam discriminator prototype based on CRM114
- holding area management for spam and maybe spam mail
- prototype CGI for holding area operations (discarded because UI sucks eggs)
- prototype CGI for browser based stamp generation in response to postage 
due notice

what we need help with:
- holding area operations CGI. Must be simple UI allowing non-computer user 
to correct discriminator mis-recognitions and release improperly filtered 
messages.
- better CGI for browser based stamp generation.
- better SMTP proxy for outbound stamp generation (including proper BCC 
handling)
- proxies for pop 3
- Most of the code has been written in Python.  We're using Java only for 
the postage due notice web page. It needs to be rewritten a bit to be only 
Java 1.1, show only a big fat button that says "send postage" when it is 
done, and probably some other things which I can't think of right now.

any takers?