[hashcash] Re: python hashcash status (Re: hashcash v1 support)
- From: "John Honan" <jhonan@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 12 Aug 2004 08:39:17 -0500 (CDT)
>> I apologize for not paying attention. Is this backward compatible or
>> not with the previous version of the stamp?
>
> Both v0 and v1 stamps can (crudely) have their value checked by running
> through sha1 and counting leading zero bits, then verifying against a
> double-spend database. If that's all an old implementation does, it'll
> work fine with v1 stamps, though it will begin to miss a larger
> proportion of technically invalid stamps.
>
> The v1 format also includes an intended bit count, which displaces the
> date and address fields, so if v0 code checks these, it will definitely
> choke on a v1 stamp.
>
What is the purpose/advantage of the 'intended bit count' field? - As the
stamp will have to be checked anyway to determine the actual bit count.
The receiving server will be comparing actual bit count against it's own
'acceptable postage value' bit count, the verification process won't be
referencing the 'intended bit count' field.
Sorry if this was covered in the docs, but I can't find it.
One other thing, on the http://www.hashcash.org/dev/ page, I think there
might be a typo. There is an example section about halfway down;
"Taking the example stamp: 1:20:040806:foo::be1f404f77b928e2:2360d4 one
could verify its collision using the following:
echo -n 1:20:040806:foo::65f460d0726f420d:13a6b8 | sha "
It appears you're using a different stamp in the command line than in the
text above it?
John.
Other related posts:
