[hashcash] Re: hashcash stamp server

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Mar 19, 2004 at 08:04:51AM -0600, Kyle Hasselbacher wrote:

>I have to admit, though, I'm pretty happy with how the daemon works right
>now.  I'd rather not chew up my processor generating stamps I might not
>use, and I don't mind waiting for my messages to go out.  [...]

Having said that, I now have something that's partially working (code not
yet available).  Blame a long car ride this weekend with plenty of time to
come up with an implementation idea I like.

I have a quick and dirty 'hashcash-request' script to tell the daemon to
prepare a token for a message not-yet-written.  You give it a -r option to
say who the token is for, and it uses the bitconf to determine the details.
You can also specify a -b option to force a certain number of bits.  I'd
like to be able to tell it to generate tokens that expire in the future,
but that's not written yet.  What it does is create a .req file in the same
queue that has .msg files.

The daemon treats these requests as second class citizens, processing them
dead last regardless of expense and such.  A finished token is written to a
file in a directory full of premade tokens.

When I go to generate a token, I first look to see if there's one already
available at or above the postage required.  I also check to see if there's
one already being generated with the same specs I need.  If there's one in
process, I take over that process.  Taking over another process generally
only happens with a message displacing a request, but it's possible for one
message to oust another.

Oddities:

* If I have an expensive pre-made token, it gets processed late even though
  it's really cheap.  I don't notice how cheap it is until the last minute.
  This means I could have messages that I can delivery immediately hanging
  around waiting for a message that I wasn't prepared for.

* If I request a token ahead of time, but that token isn't finished by the
  time I need it, I basically generate it twice.  The message that goes
  through doesn't 'eat' the unfinished request.

* The daemon has a bit where it waits for a running hashcash to finish.  I
  do premade token expiration there.  Maybe I should do it when requests
  are queued.

My idea at the moment is for a MUA to make a request as a message is
started.  It's also easy to script something that will make tokens for
incoming email, or a cron job that requests often used tokens on a regular
basis.

Beyond being able to specify the expiration date of a request, what would
folks like to see here?  I can see the prediction business becoming very
complicated pretty quickly.
- -- 
Kyle Hasselbacher              When free speech is outlawed,
kyle@xxxxxxxxxxx               only criminals will complain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAX2qL10sofiqUxIQRApRMAJ94bixrae47xKyjFcJ1pXe8QgWU9wCgzXIy
6IeJQ2LvGpt5rU0tTX/QuP0=
=UD0T
-----END PGP SIGNATURE-----

Other related posts: