I have a suggesetion on the fast, but big padding vs relatively fast but compact padding discussion. We've determined that it appears not possible to robustly prevent there being a performance advantage to SHA1 input block boundary padding. One could define a rendering which did not display the padding and added it back prior to hashing, but a) what you see is no longer what you hash (wysiwyh:-), b) we'd have to change the format again. So given all this, perhaps we can change the code to allow people to choose: relatively fast compact, vs big padding fast. People with server side apps or slow machines etc will lean towards big and fast; perhaps others will be happy enough with compact relatively fast. IIRC the difference was around 15%. How hard is it to extricate the padding part and have an option to hashcash_fastmint() to choose. (Compact would be where padding grows as the counter wraps, starting with 1 char counter and growing). Adam On Fri, Sep 17, 2004 at 07:19:08AM -0400, Eric S. Johansson wrote: > Justin Guyett wrote: > >Why should they have a hashcash binary? Any embedded system without a > >compiler then has to be supplied with a hashcash binary by whatever > >entity compiles the rest of the system. > > yes. That's normally how these things work. We are providing a > standard library or command line tool to generate the hashcash stamp. > If you want to use the services, you need to have the library. Same > argument could be had for TCP stacks, memory management, math functions, > or configuration file access. > > >Knowledge of and modification to the stamp format should not be required > >at all in order to measure the raw (version 0 style) value of the stamp. > > but the version 0 style is deprecated as far as I know. > > > >Is there a good reason to standardize padding in the last field? Why > >not let the generator do whatever it wants, including omitting the > >counter field entirely? > > > >I think it's a bad idea to force people to use unnecessarily complex > >implementations. > > the complexity comes from the need for speed. If we can gain a > significant performance improvement with padding, then we should take > advantage of that because if we don't, spammers will.