[hashcash] Re: status of hashcash version 1?
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 29 Jul 2004 16:32:14 -0400
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:
