[hashcash] hashcash v1 questions
- From: Justin Guyett <justin-hashcash@xxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Mon, 31 May 2004 16:08:18 +0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Why integrate options into the hashcash header? It makes no difference
whether they are hashed or not; the sender still has to compute the same
number of sha1 hashes on average. Putting extra stuff into the header
makes line-length an issue, and there's even a slight performance hit
hashing longer headers, penalizing people who use long keys.
As for putting keys in headers at all, there are already headers like
these in use:
/^X-...-Fingerprint:/ (... is GPG or PGP)
/^X-...-Keyserver:/
I've seen some others, but I don't recall them at the moment. Aren't
those perfectly adequate to transfer keys in virtually all cases? They
don't require email-bloating keyblocks either in headers or in the message
body. If it's absolutely critical that a message be sent via email, why
not use a standard pgp keyblock or define another header in which to place
a base64-encoded key?
As for collisions causing mail deletion due to double-spending checks,
doesn't it make sense to require a full YYmmDDHHMMSS timestamp? It's
harder to prevent double-spend collisions than it is to prevent double
spending. Using Message-IDs as a model, adding a sender field (either
hostname or email address) could further hedge against mistaken
same-second collisions.
Using the alphanumeric (or base64 charset) gains nearly (exactly) two
bits per character over hex. Since collisions are a worry as is header
length, why not use a larger charset for the random field?
What's the point of including the bitcount? That seems like a
completely inconsequential piece of information. It could be a lie, or a
spammer could set it to the actual number of bits. Why give end users the
opportunity to create draconian mail filtering rules? If I send a stamp
with a claimed value of 26 bits but there are only 24, and the recipient
requires 22, what are they going to do? It's my fault for lying, but is
the hashcash header supposed to weed out compulsive liars or merely test
for proof of work?
And the counter at the end? Same issue.
This example is v0 with an advisory reverse-postage and sender
address/hostname added:
X:date:recip_resource:sender_postage:sender_resource:random
X:20040531062557:hashcash@xxxxxxxxxxxxx:25:sender@xxxxxxxxxxxxxx:asdlkfj1325ASDFJ
Is that really so lacking due to exclusion of an options field, hash
value/multi-puzzle indicator, and counter? The 25 is advisory only, and
indicates the reverse-postage to the sender. It's mentioned on the camram
page. Why is it not in hashcash v1 stamps?
I understand the rationale behind multiple puzzles, but people sending
generating stamps should allow that it might take up to an order of
magnitude longer than normal. If I expect a stamp to take 1 minute, I'm
not going to get bent out of shape if it takes 5 minutes to deliver. If
messages are time-critical, make sure the recipient has you whitelisted
The multi-puzzle thing just makes it more difficult to verify hashcash
without a specialized binary or perl/python/shell script.
--
"Not your decision to make."
"Yes. But it's the right decision, and I made it for my daughter."
- Bill, Beatrix; Kill Bill Vol. 2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAu1hynH0ZJUVoUkMRAsdaAJ0YvuqyOCPmHNN9CpWueGwsF40J9wCbB6rK
sWY8Ca152R9yHFN2UnCdhBk=
=DZHg
-----END PGP SIGNATURE-----
Other related posts:
