[hashcash] Re: avoiding expiry before creation (Re: Re: 1.03pr6 fix for getopt & recent bugs)
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: Adam Back <adam@xxxxxxxxxxxxxxx>
- Date: Thu, 2 Sep 2004 22:24:07 +0100
(List is being rather slow, Cc'ing on this one and retaining full text
of previous in thread below).
Yes, I noticed that and sent a note to the freelists.org admins. You
should get my patch through the list fairly shortly, though - I sent it
ages ago.
Another issue which came up recently is Thomas Boschloo pointed out a
problem with very large stamps -- they could take so long to compute
they are expired by the time they are produced.
This would have to be non-email application given short-times, but eg
as expiry is configurable and resolution of creation time, one could
have eg second resolution creation time, and expires in 10 mins.
Interesting... though I can't offhand think of an application that
would require such a short expiry. Let's discuss this more when the
list gets back up to speed, as I think it's a future issue rather than
a critical one for now.
To do this we also need something like the "do max 2^32 tries and give
me control back" kind of API like find_collision has.
This is already present at the minter core level (and is used by the
new quickbench code), so a future API expansion to expose it to client
applications would not be terribly difficult.
I call it with 100 tries; but may be you'd want a bit more as the new
minters are faster. eg 256 or parameterizable maybe.
I've done it so that if a particular size doesn't take long enough, it
resyncs to the clock, doubles the count, and tries again. That way we
virtually eliminate function-call overhead from the benchmark. "Long
enough" is defined as a decent number of real clock ticks, so there's
also a loop beforehand to discover how long a tick is.
All this still takes quite a short time, especially under Carbon/OSX
which seems to have a clock() resolution of a microsecond!
(Question: does the Cyrix 5x86 support CPUID? If not, it would make
a
suitable test platform for this. So would my old 486, but it's
taking
it's sweet time over installing Linux, so may not be ready for
several
more days.)
I had a amd 486dx120 somewhere gathering dust (3 x 40Mhz clock
multiplier) but I am not sure I will be able to make it work, it had
several IO cards fail and I ran out of IO cards to replace them with.
That was a sweet machine in it's time.
Wow - the fastest stock 486 I'd heard of before was the DX4/100 (3x33).
I could take the chip and put it in my IBM PS/1 chassis, though it
would only run at 3x25 in that case, unless someone found a decent 486
board to go with it.
Of course, if the actual board is in working order, I could just take
that and use the I/O cards I have lying around already. I've got a
spare ATX case which should also take an AT board, and a spare AT PSU
which seems to have got slightly too worn out to drive my Pentium-MMX
reliably, but should be fine for a 486.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@xxxxxxxxxxxxxxxxxxxxx
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts:
