[hashcash] Re: A summary of the state of play

(let's try this again because something failed on my end)
Jonathan Morton wrote:

This assumption makes sense up to about 26 bits, based on current performance estimates. Up to 30 bits may also be acceptable, if the user is willing to wait overnight. But waiting overnight is something even low-end users would only want to do occasionally. 

one of the things to consider for low-end users is that they may be able
to work a financial arrangement with an ISP and a stack of servers to
generate stamps for them.  Since they are a known and paying customer,
they get to generate a certain amount of stamps as part of their monthly
allowance.  In this marketplace, we would finally learn what is the true
value of a 30 bit stamp.  ;-)

notice that this solution would probably also work for telephones and
other low-power devices such as PalmPilots.

- Hybrid systems, and where hashcash fits in (e.g. the MS SenderID
proposals, which appear to be gathering pace)


well actually, if you do the research you'll find that I coined the
phrase hybrid sender pays.  To describe camram and how it allows for
sender pays technology such as hashcash to be used seamlessly in
conjunction with existing e-mail infrastructure.  So, anything else you
want to filter on, can be included in the filter chain.

In fact, I just added a filter which will automatically pass a message
that is over X bytes in size (AKA the Samoan filter) and a filter to
detect when a user has opted out of being filtered.

Proof of work can be used as either a substitute or a foundation for signatures. Obviously, it's cheaper for a sender to add a signature than a PoW token, but if a signature relationship hasn't yet been set up, the PoW token is the way to go. Hashcash is a good candidate for PoW. 

I think of proof of work stamps as in "introducer".  If you want to talk
to me, you must prove that you really want to talk to me.

Content filters are the last line of defence. They should only come into play if a message passes the domain certificate stage but gets an inconclusive result from the signature and PoW filters (perhaps because neither are present). This is the last chance for a message to "go legit" before it is dropped. CAMRAM implements this technique. 

heh. camram implements lots of techniques...


The point of the content filter is to allow the status quo to be gradually phased out, rather than instantaneously becoming obsolete. It also allows senders to be partially ignorant of the quantitative requirements of the sender (ie. PoW value), without necessarily requiring a message feedback mechanism to avoid excessive false positives. 

this is part of the point behind white lists derive from who you e-mail.
 It removes all messages from people you communicate with from content
filter consideration.


- Stamps versus pipe size (again, eric mentioned he had a spreadsheet with
some volume calcs. I'd really like to see that) 

http://harvee.org/~esj/hcstampcalc.sxc should work

I'll leave Eric to provide this. But, as a ballpark, consider that a T1 (1.5Mbit/sec) can be had for perhaps $400/month, and a typical e-mail might be less than 10KB. A typical zombie can be considered to have 250Kbit/sec upstream bandwidth. 

384k upstream is more consistent nowadays for cable modem and even most
ADSL providers.  When I had royally screwed up an Apache proxy and was
relaying spam (yes, it's ironic), my upstream pipe was saturated at a
full 384 K.

A brief, and perhaps oversimplified, description of RPOW is that it allows hashcash tokens (which can only be used once) to be exchanged for
...
Evidently, RPOW does not scale to general use of global proportions, but it may still be useful to help low-end machines "save up" CPU effort for future messages. 

this could be interesting if you used a distributed mailing list
architecture in that the token would be passed along with a message and
transformed at each relay stop.  hmmm.

---eric


--
Speech recognition in use.  It makes mistakes, I correct most


Other related posts: