[hashcash] Re: A summary of the state of play
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 25 Aug 2004 04:20:11 +0100
(let's try this again because something failed on my end)
Actually, I received both of them. :)
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.
Yes, that is something I suggested in the past, but temporarily forgot
about. It need not be the ISP that does this - an independent
third-party should be able to provide this kind of service at a
reasonable cost.
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.
Yes, that's a good way to describe it.
But after introduction, you want to be fairly sure you're still talking
to the same person. I assume this is what you mean by "opportunistic
signatures", and if so, it's what I have a suggested design for.
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...
I just went back and re-read your paper on it to refresh my memory. It
seems that as of January, you had (effectively) PoW, weak whitelisting
and a feedback mechanism implemented. Since then, you've added a
content filter, and started talking about signatures and stronger
whitelisting.
- 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
Pity I can't read it on my Mac.
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.
That's still in the same order of magnitude, at least. I said 250K
because that's what is usually available in the UK (I have 288K, but
it's advertised at 256K), and I've heard of people having trouble
finding better than 128K upstream ADSL in the USA. It obviously
depends on where you are.
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.
That would produce too many transactions for the system to handle.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@xxxxxxxxxxxxxxxxxxxxx
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts:
