It's a lot more than that that the stamp vendor needs to keep track
of. The first thing that comes to mind is that recipients need a
way to check that a stamp hasn't already been used
Not necessary, if the stamp cryptographically includes both the
sender and recipient addresses.
Then the recipient needs a way to check the crypto signature - and even
then, you have to figure out a way that stamps can't get reused with
forged sender addresses. (That is, X sends mail to Y, with a valid
stamp <X,Y>. Spammer gets hold of a copy (through any of many possible
means) and sends mail with that stamp, to Y, forging X's address as the
sender.)
Another solution is to use a proof-of-work stamp,
There really is no such thing. Hashcash is not something that can
be attached to a message; it requires an interactive protocol.
(There may be some way to do proof-of-work in an open-loop form, but
I haven't seen it yet.)
Why is this?
Why? Simply because all the hashcash protocols I've seen outlined, or
that I've thought of, involve some kind of challenge by the recipient
which must be answered by the "payer". A simple example might be "find
a data blob whose SHA-1 hash has these 20 bits set to these values".
As I said, I don't know whether this is an inherent property of
hashcash (by which I really mean "proof-of-work", even though,
strictly, hashcash is but one form of p-o-w) or whether it's just an
artifact of the hashcash schemes I am aware of. But until someone
shows me one which doesn't have that property, I have to operate under
the assumption that no such thing exists.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML
mouse(_at_)rodents(_dot_)montreal(_dot_)qc(_dot_)ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg