[hashcash] Re: example v1 stamp
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 28 Apr 2004 18:46:09 -0400
On Wed, Apr 28, 2004 at 04:06:36PM -0500, Kyle Hasselbacher wrote:
> >1:20:040428:foo::0298b26853c8ebb3:beca0
> >
> >which is broken down by : separated field:
>
> So, I don't remember the verdict from before. Is ':' always a separator?
Yes. So eg
% echo 1:20:040428:foo::0298b26853c8ebb3:beca0 | \
cut -d: -f 1-6 --output-delimiter=','
1,20,040428,foo,,0298b26853c8ebb3
> How do we put a ':' in a field (some kind of escape)? I guess I'm asking
> what's the right way to pull this thing into its component parts.
You have to encode it somehow. Eg URL encode. But you are not
allowed to put a :.
> I made a pretty simple change in hashcash-sendmail to deal with the new
> format. I haven't published the change yet, since I haven't tested it at
> all.
>
> diff -r1.14 hashcash-sendmail
> 773c773,777
> < $expiry = $1 if ( $tok =~ /X-Hashcash: 0:(\d+):/ );
> - - ---
> > # v0 = 0:date
> > # v1 = 1:bits:date
> > if ( $tok =~ /X-Hashcash: (?:0|1:\d+):(\d+):/ ) {
> > $expiry = $1;
> > }
>
> I think it's simple enough I don't need a test, but I've been wrong
> before. 8-)
Note when I get done you'll also have to deal with multi-line tokens;
I can't gaurantee that with people's extension fields it won't grow to
over 80 or whatever chars.
What I'm doing is to wrap at 70 chars, and use \t as continuation
char. Here's another real example (well real except that the
extension fields are unsupported junk extensions to make the token
large):
X-Hashcash: 1:20:040428:adam@xxxxxxxxxxxxxxx:abc=123,456,789;bcd=12345
6789;xzy=123123123;z=a,b:fff2f7eee8cbc1d0:13dd13
> >the random field is to avoid collisions; the counter starts at 0 and
> >increases. For small numbers of bits you expect a short counter (on
> >average) and for larger numbers of bits you expect a larger counter.
> >
> >This arrangement with separate randomness part counter field makes the
> >probability of collision collision independent of size in bits.
>
> I'm missing something. I don't understand what you gain from separating
> the random part and the count. You have <random>:<count> (e.g., 123:456).
> Is that very different from <random><count> (e.g., 123456) or
> <random+count> (e.g., 579)? I guess I'm thinking that they all collide the
> same way, with the same frequency.
I think that's true.
> You seem to be saying this has something to do with the size in bits, but I
> don't get it. We expect a low bit stamp to have a smaller counter, I
> guess, but I'm not sure what that has to do with anything.
With v0 implementation there is a fixed sized collision string (96
bits); as the size of the stamp grows the probability of an accidental
collision also grows. (Actually earlier versions had fixed 64 bits,
but that was a bit small to be safe against collisions with larger
stamps). But you're right this is an implementation issue, not a
reason to change the format.
I think reason to have a delimiter between the two halves is so that
the recipient can tell where one ends and the other begins. People
may have different sizes of random field, depending on their
application. (Ie depending on how many messages they expect in the
time period so if that is an exceptionally high number they might
choose a larger randomness field.) It's also kind of nice, though I
don't see an immediate use to be able to see the counter separately.
At present the counter and randomness can be base64 alphabet, or a
subset of that. (Previously they were any printable char > ascii(32),
except :). The code is generating hex only, but it would be more
compact to generate base64 which I might do sometime.
> >You can also see directly in the stamp btw how unlucky the generator
> >got. So for a 20 bit stamp you expect 2^20 tries which is 1
> >mega-tries, or 100000 in hex. You can see it took only BECA0 tries or
> >about BE/100 = 74% of expected time.
>
> I'm going to rewrite my generator to start the counter at 2^(bits+2).
> It'll be the unluckiest generator on the net. 8-)
Smaller counter = smaller stamp, hence starting at 0, once you have
the randomness/collision avoidance in a separate field.
Adam
Other related posts:
