[hashcash] Re: RPOW - Reusable Proofs of Work
- From: hal@xxxxxxxxxx ("Hal Finney")
- To: hashcash@xxxxxxxxxxxxx
- Date: Sun, 22 Aug 2004 15:44:25 -0700 (PDT)
Jonathan Morton writes:
> This is a very neat idea. My concern, however, is in the rather
> limited capacity of each server card. How much does each card cost,
> and is it possible to fit more than one in a machine? How easy is it,
> in practice, to add (a batch of) cards to the trusted server network?
You're right that in practice, the RPOW concept cannot really scale to
handling the entire email load of the Internet! Each board costs over
$3000 and while the system is designed to be scalable, there are limits.
It is really meant as a proof of concept at this point. There might
be specific areas where it could be adequate; one example I am thinking
about is anonymous remailers, which often suffer from overuse.
> An interesting and practical application, however, would be to allow
> users of low-end machines to "save up" hashcash in RPOW tokens, and
> redeem it when needed by asking the server to generate regular hashcash
> with certain properties, providing an appropriate value RPOW token as
> "payment".
That's an interesting idea. I think the main goal is to let low-end
users generate their hashcash in advance, so they don't have to wait too
long at mail-sending time, right?
The problem is that the point of RPOWs is to be reusable, and I don't
see much potential for reuse in this application. The server would
accumulate RPOWs but has nothing much to do with them. In such cases
it seems that straight hashcash is a better fit. You could accomplish
your goal by the server selling custom-made hashcash strings (i.e. ones
with a desired email address in the resource string) in exchange for
hashcash made out to the server itself. This way, low-end users could
generate their hashcash in advance.
You'd have to think about making the server resistant to use by spammers,
which could either be done by limiting its customers to a known set of
low-end (and trusted) users, or by requiring the incoming hashcash tokens
to be of higher value than the outgoing ones. Of course that gets tricky
if it is mostly coming from low-end users, you can't penalize them too
badly. But in exchange for allowing people to generate tokens in advance,
it is appropriate to raise the per-token cost by a considerable factor.
Hal
Other related posts:
