[hashcash] Re: Friday news
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Fri, 26 Mar 2004 12:19:05 -0500
Adam Back wrote:
> I notice in that article that it says CAMRAM requires 23 bit hashcash
> stamps. This is a stamp considered of sufficient value to add a user
> to a whitelist, right?
that's *my* interpretation/evaluation. Remember, we really don't know
where the right threshold is because we don't have a sufficient
deployment or body of experience. For the purposes of the article, I
needed to put a stake in the ground and so, 23 bits.
> I wonder if it would make sense to take the default 20 bit hashcash
> token as a once-off exemption from challenge-response / filtering
> false-positive, to improve hashcash interop story. (Once-off so that
> next time the hashcash user still needs to send a new token as no
> auto-whitelisting has occurred.)
that might make sense. interoperating with other hashcash
implementations I assume is what you mean? in the long term I don't
think it's a good idea because if a spammer can generate a message close
enough to a threshold of being considered "good" that a low value stamp
can push it over the edge, then we have not gained much. But we have
lost good credibility with users. One way to approach this is to limit
the Delta from your local postage requirements so that anyone within
three bits may fall into the continual stamp category described.
the general problem I have with stamps as a score offset is that far too
much commercial e-mail (and I've got a whole bundle of it) score very
negative and will never be redeemed to this technique. we would be
lucky if the message showed up in the spamtrap for consideration.
I would prefer to define a postage due mechanism that bounces request
for new postage back and communicates the local postage rate. I think
with SPF in the picture, we can minimize the chances for joe jobing
being devastating.
---eric
Other related posts:
