[hashcash] Re: Hashcash performance improvements
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Sun, 30 May 2004 05:00:02 +0100
> 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:
