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 >