[hashcash] hashcash-1.15 released
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash <hashcash@xxxxxxxxxxxxx>
- Date: Tue, 11 Jan 2005 21:02:28 -0500
There was towards end of last year some discussion about big stamps
being ugly. So I implemented the previously unimplemented -Z option
to allow stamp compression and released as 1.15:
http://www.hashcash.org/source/
(as well as binary packages for linux, and windows).
From the CHANGELOG on compression:
* implement the -Z option to compress stamps; in fact the
usage changed so -Z takes an argument: 0, 1 or 2. 0 = not
compressed, 1 = compressed but not so the counter + padding
is split, and 2 = very compressed, but slow.
(More discussion about compressing stamps at the bottom).
Also made "Hashcash:" be accepted as well as "X-Hashcash:" suggestion
by Simon Josefsson <jas@xxxxxxxxxxx>. This way if/when the X- is
dropped from hashcash headers we will not have a backwards
compatibility problem. (Well not after version 1.15).
I also fixed the issues with openssl linking, which happens to provide
a work around to the linking problem Hal reported recently (I think!).
(Compile with make x86 CFLAGS=-DOPENSSL LDFLAGS=-lcrypto).
Now more about compression:
Note firstly I had to disable -Z2 at the last minute, due to a bug.
If you want to play with it remove line:
if ( compress > 1 ) { compress = 1; }
in hashcash.c.
So the interesting thing is if you compress it a lot you end up
(sometimes depending on length of email address) with the counter or
the SHA1 padding split across two SHA1 blocks. If this happens you
roughly have to do 2x the number of SHA1 blocks per stamp.
(You could pre-compute 1st half of counter, but not done that so far).
So -Z0 does as before (fast), -Z1 compresses but avoids splitting over
SHA1 blocks, and -Z2 goes for it and pays the 2x price (sometimes, if
the stamp counter/SHA1 padding falls across SHA1 boundary).
In fact -Z2 is even more expensive than 2x because the fast cores are
hard to adapt to multi-block (they assume it's all in one block). I
might fix this later. However for now -Z2 is 4x slower than the
hashcash SHA1 or 2.5x slower than the openssl SHA1.
(You can build with openSSL using:
make x86 COPT=-DOPENSSL LDFLAGS-lcrypto
)
Also another thing I did was increase the line wrap from 70 chars to
80 chars. (Originally I figured 70 chars is friendly for quoting).
So here's an example of the largest non-wrapping typical -Z2 20 bit
address size:
(33 chars)
X-Hashcash: 1:20:050112:0123456789abcdef0123456789abcdef0::qsMwQ2OGKFrdK0ab:1ruU
and with -Z1:
(also 33 chars)
X-Hashcash: 1:20:050112:0123456789abcdef0123456789abcdef0::1KMtM7SauClmz8B8:37XD
and with -Z0:
(16 chars)
X-Hashcash: 1:20:050112:0123456789abcdef::+o1kdsIgX6q0jx85:01A13
The difference between -Z1 and -Z2 can be seen with medium sized email
addresses (between 21 and 32):
24 chars with -Z1:
X-Hashcash: 1:20:050112:0123456789abcdef01234567::qxCfuUZ4nhqzoCqj:0000000002/b0
and 21 chars with -Z2:
X-Hashcash: 1:20:050112:0123456789abcdef01234567::wrr6hy8fk3ClTRre:4bg9
So you can see -Z1 still pads to avoid counter/padding being split
across SHA1 block which slows things down (and which the fastmint code
also doesn't support as a simplifying assumption).
(The bug in -Z2 and why I disabled it is for stamps with sizes 21-23
they fail - ie it produces stamps which fail the internal consistency
check!)
Adam
The full CHANGELOG:
hashcash-1.15 - 12-Jan-2005 - Adam Back <adam@xxxxxxxxxxxxxxx>
* make "Hashcash:" be accepted as well as "X-Hashcash:"
suggestion by Simon Josefsson <jas@xxxxxxxxxxx>. This way
if/when the X- is dropped from hashcash headers we will not
have a backwards compatibility problem. (Well not after
version 1.15).
* implement the -Z option to compress stamps; in fact the
usage changed so -Z takes an argument: 0, 1 or 2. 0 = not
compressed, 1 = compressed but not so the counter + padding
is split, and 2 = very compressed, but slow.
* added -O x -sv to request benchtest of core x only
* make code work with -DOPENSSL, think this slipped during
integration of Jonathan's libfastmint as it uses some lower
level openssl APIs internally. I fixed it but it might be
a bit openssl version specific, if they changed the state
fields at any point. (This change coincidentally I think
should work around the linking with openssl problem that Hal
Finney <hal@xxxxxxxxxx> reported).
* add libhashcash.a intermediate target to make hashcash more
convenient to link into other software on linux. (A
suggestion from Hal Finney who was trying to link to his
RPOW system.)
Other related posts:
