[hashcash] Re: comment on reducing padding

Anyway, the padding gets "used up" quite neatly if you start adding extension fields, such as:

the padding is used up until we hit what, about 88 bytes being stamped? and then we jump to a 116 byte stamp. 

Which isn't nearly so bad as the jump from 52 to 96 bytes:

1:20:040917:chromi@xxxxxxxxxxxxxxxxxxxxx: sender=chromi@xxxxxxxxxxxxxxxxxxxxx:UMwjuX+wGoSyrhYV: 0000000000000000001puB

I don't see this situation as unreasonable.

i agree that most people will never know it's there, but an email addressed to 10 people would carry >1K of extra headers (the trailing spaces when using "X" makes this worse). i'm not saying that this will break email, but the extra message size can become non-trivial.

If you're sending a message to 10 people, you should be prepared to send that entire message 10 times. In practice, the smarthost will often do exactly that anyway. In this context, an extra 0.1KB header per recipient is trivial, especially if it gets added by the smarthost, one per mail (as happens with initial camram deployments). In any case, you've spent a significant amount of CPU time generating those stamps, compared to which the bandwidth cost should be negligible.

Incidentally, most analogue modems (the slowest and most expensive-per-byte link in common use today) use some form of compression on the link, which will condense a long run of zeroes to a minimal amount of data by itself. So bandwidth is a non-issue here.

--------------------------------------------------------------
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: