ietf-asrg
[Top] [All Lists]

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

2003-03-23 21:57:21
At 08:16 AM 3/23/2003 -0700, Vernon Schryver wrote:
Steve Schear <schear(_at_)attbi(_dot_)com> 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" <esj(_at_)harvee(_dot_)org>, 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?
<Prev in Thread] Current Thread [Next in Thread>