[hashcash] Re: hashcash stamp server
- From: Kyle Hasselbacher <kyle@xxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Mon, 22 Mar 2004 16:36:59 -0600
-----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:
