[hashcash] Re: Hashcash performance improvements

> Malcolm> - Recipients will likely be storing the random field in a
> Malcolm> double spend database.  This way, they're not storing your
> Malcolm> padding in there too.
>
> Is there any reason recipients would want to store just the random
> field, as opposed to, say, a sha1 hash (or some similar hash) of the
> entire stamp?

I can't think of any good objection to that.  OK, we lose a few bits of 
uniqueness due to the value of the stamp itself, but there's still over 
130 bits remaining, and we get the benefit of each entry being the same 
size.

Heck, you could just chop the first word off it and still get an 
essentially unique quadword[*] to compare.  Also, quadwords are 
particularly easy to accelerate comparison of (using vectors), so you 
can have quite a large database to check if you needed it.

[*] - using RISC convention of 1 word = 32 bits, a quadword is 128 
bits, the size of an Altivec or SSE2 register.  It's come to my 
attention recently that x86 manuals often refer to a word as being 16 
bits, and a quadword as being the size of an MMX register, or 64 bits.  
I vaguely recall that 68K uses the latter convention as well.  Sigh.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@xxxxxxxxxxxxxxxxxxxxx
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

Other related posts: