[hashcash] Re: python hashcash status (Re: hashcash v1 support)
- From: "Hamilton, Michael" <mhamilton@xxxxxxx>
- To: <hashcash@xxxxxxxxxxxxx>
- Date: Thu, 12 Aug 2004 12:50:19 -0700
Message was cut off because of a '.' by itself on a line (I think).
-----Original Message-----
From: hashcash-bounce@xxxxxxxxxxxxx
[mailto:hashcash-bounce@xxxxxxxxxxxxx]On Behalf Of Hamilton, Michael
Sent: Thursday, August 12, 2004 9:00 AM
To: hashcash@xxxxxxxxxxxxx
Subject: [hashcash] Re: python hashcash status (Re: hashcash v1 support)
> 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.
This is the problem. In version 0, if you try for n bits, you will get
>=n bits in 1 out of 1 attempts
>=n+1 bits in 1 out of 2 attempts
>=n+2 bits in 1 out of 4 attempts
>=n+3 bits in 1 out of 8 attempts
>=n+j bits in 1 out of 2**j attempts
There is some number of bits of value that a spammer can generate economically,
call it S. By luck, a spammer will generate S+6 bits or more 1 time in 64.
For hashcash to gain acceptance among legitimate users, it must be at least as
effective as Bayesian content filtering at identifying spam (~1% false
negative). This means that when using v0 stamps, legitimate users must spend
at least S+7 bits on their stamps, because that's what receivers should demand
to weed out the randomly expensive spam stamps.
Nobody knows what S is, but one can generate on the order of 100 16-bit stamps
per second using modern hardware, and a 23 bit stamp is expensive on 5 year old
hardware.
In v1, the number of bits that the sender is trying for is encoded in the
stamp, so the sender gets no value from the "luck" of getting more bits than he
was trying for. He can't go back after the fact and change the reported bit
count, because that would ruin his collision string. The result is that
legitimate senders only need to encode S+1 bits, which is a factor of 64
(=2**6) less expensive.
Michael
Other related posts:
