[hashcash] Re: compact stamps optimization

  • From: bas <beware@xxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Thu, 08 Dec 2005 14:19:22 +0100

i suddenly understand the problem...

length <= 55
all data is in first block, 9 bytes terminator is in first block

56 <= length <= 64 worst case.
all string data is in the first block, but the 9 bytes terminator is in the second block. 2 block transforms needed for each attempt.

65 <= length
terminator and the least significant base64 char are both in second block.

however one can do things with the length of the anti collision string. i think 16x6 bits for it is overkill, especially considering it only has to be unique for an email address + date combination. but the random generation of it has to be good.

bas wrote: 
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.











Other related posts:

  1. Home
  2. hashcash
  3. Archive
  4. 12-2005