Re: compact stamps optimization

bas <[email protected]> Thu, 08 Dec 2005 12:53:48 +0100
Newsgroups gmane.mail.spam.hashcash
Message-ID <[email protected]>
Adam Back wrote:
> I think the issue is that SHA1 is chained thru the 5x 32-bit (160-bit)
> chaining/state variables A,B,C,D,E.  So in the 2nd case you have to
> recompute the 2nd block even though the 2nd data doesn't change.
> 
i know. i was mentioning the 2 cases where one has to calculate both blocks, and 
that these don't happen for every attempt.

> (It would be nice to find a way to remove the -Z options, we tried
> before, and failed so far).
> 
> Adam
> 
> On Wed, Dec 07, 2005 at 11:19:11PM +0100, bas wrote:
> 
>>[...]
>>changes which would require calculation of both blocks are
>>1: the string becoming longer (because the counter becomes longer), so it 
>>becomes 2 blocks
>>2: a char of the counter, other than the least significant, changes, which 
>>is in the first block.
>>
>>what does the padding refer to? what am i missing?
>>
>>i think if its possible at all to optimize -Z2 so it's like 1.1 slowdown, 
>>and not 2x, this is a good idea and it should become the default, and the 
>>existing -Z1 setting becomes obsolete.
> 
> 
> 
>