[hashcash] Re: comment on reducing padding (Re: Re: libfastmint update 20040915)
- From: Justin Guyett <justin@xxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Fri, 17 Sep 2004 06:35:24 +0000
On 2004-09-16T16:15:03-0400, Atom 'Smasher' wrote:
> On Thu, 16 Sep 2004, Adam Back wrote:
>
> > Atom writes:
> >> thoughts (after i should be in bed) about getting rid of the padding...
> >>
> >> hhmmm... what if the padding was done internally? instead of padding the
> >> stamp that's output, a minting application would create a stamp _as_if_ it
> >> were padded and a verifying application would internally add appropriate
> >> padding before calculating the hash.
> >
> > Yes I thought about this one also. However the downside is one can no
> > longer easily verifying a stamp in script languages using the sha1sum
> > utility. One first would have to undeo the padding compression.
> =================
>
> the ease (or difficulty) depends on the language and how the padding is
> handled. padding doesn't have to prepend the counter, it could prepend or
> append the entire stamp. in any case, awk can handle it with little
> difficulty and i suspect perl can handle it too.
>
> but if anyone is using a scripting language, they should have a hashcash
> executable available to do this grunt work.
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.
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.
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.
Other related posts:
