Jim_Miller@suite.com wrote:
Seems simple enough. The major sticking point (to me) is the remailer's "used stamp" archive. This could grow to be very large. Something needs to be done to keep the archive from getting too large.
One idea is to have the remailer periodically change the key it uses to sign stamps. Changing the "stamp validation key" effectively invalidates all unused stamps signed by that key. If you haven't used the stamp by that time, you're out of luck. The remailer can purge its "used stamp" archive whenever it changes its "stamp validation key".
Of course, invalidating peoples' unused stamps out from under them is not a nice thing for a remailer to do. The remailer could provide a mechanism whereby people could get new stamps from old, unused stamps. To make this work, the remailer would have to retain the previous "used stamp" archive for a while to give people a chance to get new stamps. However, there still needs to be a limit on how long the remailer retains the "used stamp" archives for old validation keys. If you wait too long, you would lose any chance to get new stamps from old.
Comments welcome.
How about this: Issue numbered stamps sequentially. Encrypt them and add a cryptographic checksum to each stamp. You then create a database such that one bit of data corresponds to one stamp. With a mere 64K database, you could issue and keep track of 524288 postage stamps. That ought to last you a few years. (At 100 letters a day, it would last over 14 years. Most cypherpunk remailers get considerably less than 100 emails a day.)