[hashcash] avoiding expiry before creation (Re: Re: 1.03pr6 fix for getopt & recent bugs)
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 2 Sep 2004 16:40:20 -0400
Hi
(List is being rather slow, Cc'ing on this one and retaining full text
of previous in thread below).
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.
Now if one has slow hardware or a large stamp it might take more than
10 mins to generate.
I think the fix is to change the timestamp in the stamp to the current
time every few seconds.
I have not yet coded this fix.
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.
So you might want to from this make it the same API for speed
measurement and finding collisions -- just give it small amounts of
work to do in speed estimate, and maybe target a rough time-intervals
worth of work per loop iteration to have somewhere to update time on 1
second interval (or min clock-resolution interval).
(You do not know how long stamps are valid for when you create them,
expiry is defined by the recipient).
Adam
On Thu, Sep 02, 2004 at 03:28:33PM -0400, Adam Back wrote:
> On Thu, Sep 02, 2004 at 02:21:17PM +0100, Jonathan Morton wrote:
> > arowana:~/Desktop/hashcash-1.03 chromi$ ./hashcash -mXb10 foo
> > X-Hashcash: 1:10:040902:foo::seq16tNIwlP0naeX:000000H9
>
> good to see that works (was kind of operating blind :-)
>
> > > * one remaining issue to fix in pr7: time the right thing in
> > > hashcash_per_sec -- we're still calling find_collision(
> > > ... step = 100 ) and we need to call the CHROMATIX code
> >
> > I'll get on this one - you need a libfastmint function for getting a
> > quick, single-core benchmark, right?
>
> Yes. The problem comes from my assumption when I wrote the code on
> the old find_collision() function which has an extra argument with how
> many iterations (max) to try. Then I just call this in a loop until
> clock tick rolls over. Crude but _fast_ test :-)
>
> (find_collision also returns how many tries it did if it finds a
> collision and 0 if it did not find a collision (you know how many it
> did if it did not return)).
>
> 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.
>
> > (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. I was running slackware on it
> (well already earlier running slackware on a 386sx16Mhz :-)
>
> Adam
Other related posts:
