[hashcash] Re: hashcash v1 questions
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 1 Jun 2004 05:28:37 -0400
On Mon, May 31, 2004 at 04:08:18PM +0000, Justin Guyett wrote:
> 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.
You want the recipient to be sure the option was sent by the person
who paid for the stamp. (Rather than tampered with along the path).
So need to either put option directly in the header, or put hash of
option in header, and put option in other header, mime payload,
payload etc.
> Putting extra stuff into the header makes line-length an issue,
I think we are already close to having a line-length issue, especially
if we include sub-puzzles. Practically you want sub-80-chars.
I think the extension mechanism is valuable as lets people do their
own thing, ala CAMRAM, perhaps other systems will put other things.
Once possibility for multiple independent extensions, also have
line-length-issues if don't allow line RFC822 folding as people may
use different extensions at once.
> and there's even a slight performance hit hashing longer headers,
> penalizing people who use long keys.
This is an artifact of the implementation. The precompute
&precomputed_ctx in find_collision needs to be moved outside the next
loop as well. Then there will be no practical performance difference
(only the last block will be hashed).
As Jonathan mentioned he already did that in the fast version.
> 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?
Another header would be possible, perhaps more elegant.
Not sure you have to use PGP because PGP has its own key bloat, has
interop problems between multiple versions etc. So something
particular to CAMRAM may be simpler / pragmatic. If you want to
verify the header you would need to use CAMRAM.
Well unless you want to roll-your-own, or integrate into other
MTAs/MUAs etc. In the latter case it would actually be more
convenient if the signature literally was a PGP signature because then
you could shell PGP to verify it, create it etc.
(Interesting trade-offs; was thinking of providing some signature
support in hashcash -- you see eg. gmp.c in the 1.00 source tree --
thinking to provide public domain source, and gmp.c is public domain
version of GNU mp. This argues for PGP compatibility.)
> 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.
The random field being 6-bit is similarly space efficient at doing
this even after birthday collision (date field being
Hubert described the explicit bit-count.
> 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?
It is an example of a use for an extension field. CAMRAM may want to
advise of respond poster required, or of poster. Basic hashcash does
not care who the poster is (impossible to enforce who the poster is,
contrary to the big sender-auth/id related discussions on asrg-spam).
> 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
Well if the postage generation is done in the background probably
doesn't matter so much. (Though there is some user expectation
potential problem -- eg dialup, I want to know when its gone so I can
hangup).
But it may be difficult in some mailers to background, and/or the user
maybe looking at progress bar which is difficult to do properly with
single stamp hashcash.
btw one thing you can do with single stamp hashcash is show the
progress of largest bit-count so far. Makes absolutely no guarantee
of how close it is getting, because there is no closeness, but gives
you something to watch. (The mempow.c memory bound proof-of-work does
something like this).
> The multi-puzzle thing just makes it more difficult to verify hashcash
> without a specialized binary or perl/python/shell script.
That's true and a disadvantage/trade-off in my view.
Adam
Other related posts:
