[hashcash] Re: status of hashcash version 1?

On Wed, Jul 28, 2004 at 03:54:26PM -0400, Hubert Chan wrote:
> Adam> it does not come with multiple sub-puzzle support which could be
> Adam> added.
> 
> Will this involve another format change?  Or should it be backwards
> compatible?  (I assume that it will change the format.)

It would change the format.  It is a bit of a tie

- PRO gives apps which are about variance opportunity to make it quite
low (eg if we defined max 16 sub-hashes) 

- MINOR CON challenge is a bit bigger when you do it

- CON more complex code to create 

- CON more complex code to verify

> Adam> The other part missing from the implementation is the hooks to
> Adam> make use of extensions. ...
> 
> OK.  I don't think it should be that much of an issue if the Debian
> package lacks some feature.  I just don't want Debian users to be
> generating incompatible stamps for the lifetime of the next stable
> release (which some Debian developers tell me should be much shorter
> than the current stable's lifetime, but I'd rather be cautious).

Yes I was thinking the extension _framework_ with no implemented
extensions should not be so hard to implement.  It is just checking
for the existance of the hashcash extension by-name in the
search-path, if its there exec it if not ignore it.  So just some
system / fork/exec stuff.  If someone has some simple, readable and
secure BSD / PD licensed code to do this kind of execing and look at
status code handy.

> Adam> Plus need to integrate Chromatix fast hashcash code.  Think main
> Adam> issue there is to have a way to know which code to run on a
> Adam> machine based on eg some CPU properties code so it is fast, or a
> Adam> very short trial of the set of alternatives that run on the CPU to
> Adam> measure which is best.
> 
> I guess the best thing to do is to measure once (e.g. at package install
> time), and store the result for which alternative is the best, right?

Ick.  I was hoping either the test was fast enough to run always, and
the CPU detection was also v. fast.

> Adam> And the last and probably biggest issue is how to deal with CPU
> Adam> inflation.  I was thinking this could be implemented using the
> Adam> extension mechanism.  One way is to pass around p2p the largest
> Adam> required-hash definition seen so far, and have someone / some
> Adam> group changing this over time using some pre-agreed criteria.
> 
> OK.  I guess this is another feature that is less of an issue for the
> Debian package to be missing, since it can always be done by hand.

That's a quite good pragmatic suggestion.

With the above, plus I think Chromatix suggestion to use clock() vs
wall-clock time (which is not good on systems with load), and I think
this ought to be doable quite quickly.

Adam

Other related posts: