[hashcash] Re: getting rid of stamp value variance (Re: Re: Hashcash vs. Time?)
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: "Eric S. Johansson" <esj@xxxxxxxxxx>
- Date: Mon, 26 Apr 2004 15:28:19 -0400
Eh yes sorry. The comment was not really about the topic of the
thread I responded to, only the little side comment of yours I quoted:
| the collision in a stamp is a probabilistic event and can be
| anything up to the full number of bits in the hash. It's all luck.
| :-)
My comment is just about how one goes about measuring the size of the
collision in a stamp.
So more clearly:
As you state the current stamp generation process has two aspects
where there is randomness. A) The stamp takes a random amount of time
to generate (tho' with a predictable average time); B) the stamp can
be larger than required. On B) with probability 1/2 the stamp can be
1 or more bits larger than needed, with probability 1/4 2 or more bits
larger etc.
So I noticed we have the option to prevent variance B. If we put the
stamp size into the stamp:
1:20:040426:adam@xxxxxxxxxxxxxxx:123ab234fddee7
^^
like that would be a 20 bit stamp, then it will never be considered to
be worth more than a 20 bit stamp because even though it is still true
that it can have a larger collision, the definition of value of a
stamp would then be that the collision is >= the stamp size listed in
the stamp itself. Now as with the other fields you can't change the
stamp value without recaculating a fresh stamp from scratch.
So someone could try generating a 21 bit stamp, and get lucky and
generate one with <= the cost of a 20 bit stamp; however they have no
guarantee of that, and so are really trying to do the work of
generating a 21 bit stamp.
So I would say doing this has two benefits:
- it makes it easier for humans and scripts to read stamps (they can
for example be pre-validated by some filter, or presumed valid and
checked separately, and as with digital signatures the typical case
will be that they are valid so it is useful to make them human
readable as possible)
- it conveys more information -- about what size of stamp the sender
was actually trying to create (vs how lucky they got in getting a
larger than requested stamp). This info would be useful for example
in some of the heuristic p2p approaches you Eric have been discussing.
Adam
On Mon, Apr 26, 2004 at 07:23:20AM -0400, Eric S. Johansson wrote:
> Adam Back wrote:
>
> >btw In thinking about v2 stamp formats, it occurred to me that if you
> >include the stamp length in the stamp, you will not get larger than
> >expected stamps ever.
> >
> >(Where the modified definition of value is 0 if stamp-bits less than
> >measured bits, and equal to stamp-bts otherwise, where stamp-bits is
> >the number of bits defined in the stamp).
> >
> >Eg.
> >
> >0:20:040426:adam@xxxxxxxxxxxxxxx:123ab234fddee7
> >
> >(Anonomasia first proposed putting the stamp value in the stamp)
> >
> >Of course this has no impact on the time-variance.
>
> this confuses me a little bit. It sounds like at first that you are
> saying if you include the stamp length in a stamp, when sending stamps
> and then you'll never receive a stamp of greater length? but then you
> say stuff that sounds like you're talking about letting self define the
> value of a stamp.
>
> could you please help me with my confusion? It's Monday morning.
>
> by the way, it looks like camram in a sendmail milter may be happening
> today if all goes well. pseudo blog with ugly details coming soon. ;-)
>
> ---eric
>
Other related posts:
