[hashcash] Re: Length of recent X-Hashcash cookies?

On Wed, Dec 15, 2004 at 08:30:02PM +0100, Simon Josefsson wrote:
> Hi.  I have been using X-Hashcash for a while, but the recent cookies
> are long (>80 characters), which look quite ugly.  I know this is not
> a violation of any specification, but that doesn't mean they don't
> look any less ugly.

If you use hashcash -mX they are lined wrapped with continuation tabs
like this:

X-Hashcash: 1:20:041215:jas@xxxxxxxxxxx::K05jPSRhnOOWpQho:000000000000
        00000000000000000000000000000000002BaV

and the corresponding -cX parses this continuation line form.

> Could leading '0' in the last field be removed, for instance?

Most of the 0s could be removed (at some moderate speed loss, they are
to pad to SHA1 block size to speed things up).  I was thinking of
adding an option to not do that (I optimize for size not speed).  That
would make many/most email only with no extension field stamps fit on
one-line.  (You can't literally just remove them or the hash will
fail, the software needs to be adapted to have an option not to
generate them).

> PS.  This message has a cookie for a gmane.org newsgroup.  This is
> because Gnus doesn't handle X-Hashcash in news->mail gateways
> properly.  If someone has any suggestion how it should work, that
> would be appreciated.

I guess the best thing from the recipients point of view is that the
stamp is minted on the address they white listed that they think they
subscribed to.  But the problem with mail2news and back again is there
are two valid addresses.  For safety the recipient should white list
both addresses?

Or maybe the m2n and back again could be setup to always include the
Newsgroups: header (even if going via news2mail gating) and the emacs
hashcash support to also add a stamp for the groups address, in this
way it could work for both ways?  Would this break anything?

> PPS.  How about renaming X-Hashcash: to Hashcash:?  The 'X-' prefix
> also look ugly, and was only discussed in RFC 822, not in the current
> RFC 2822.

Not sure it was discussed before.  Some people argued leave it as is.
The main opportunity for change passed in that if we do it now we have
to keep the X-Hashcash for backwards compatibility, or add support for
both.

Adam

Other related posts: