[hashcash] Re: more format stuff
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 25 Mar 2004 02:40:41 -0500
On Wed, Mar 24, 2004 at 07:45:38PM -0500, Hubert Chan wrote:
> Small clarification: should there be a comma between "non-printables",
> and "> ascii(127)"? i.e. the sentence should be parsed as:
> the following are banned (in addition to whatever was above):
> - non-printables
> - > ascii(127)
> - whitespace
yes.
> Adam> we could put some time limit on acceptance of the version 0 format
> Adam> so it doesn't live for ever.
>
> Is the time limit necessary? Not having a time limit only requires
> that hashcash verifiers have an extra bit mostly trivial of parsing
> code. I don't see that it creates any problems with double-spending
> databases, or any other part of the system, unless I'm missing anything.
If we do nothing organized about bit inflation there is no problem,
just v0 clients do not benefit from v1 extensibility. v1 clients
would still accept v0 stamps relatively indefinately.
However if v1 defines a MUST extension which is a way for clients to
communicate in a distributed store-and-forward compatible way a single
global increase in required collision bits, then v0 starts to be a
problem:
- a v1 client never knows what version it is talking to so it has to
send what? both versions?
- a v1 clients have to accept v0 tokens because there are v0 only
clients out there, then spammers will use v0 because the bits are
cheaper and fixed at 20 bits (in some years time when 20 bits is much
less significant).
- if v1 clients apply their knowledge about required bits from v1
protocol to v0 protocol, they will have effectively disabled v0
clients anyway because their default 20-bit tokens will be rejected as
insufficient.
So this all points to the somewhat brutal but pragmatic, clean
approach of just deprecating v0 either immediately on stable v1; or at
a given flag day eg 1 year in future before which time required bit
increases are unlikely.
> I'm just asking because if we don't have a time limit, then I can
> unblock hashcash from entering Debian testing. I'm fine either way,
> though.
Other issue with v0 going into debian stable (via debian testing) is
that it would propogate the above problem.
Of course the above assumes some things about the system using
hashcash. Some systems (such as CAMRAM) perhaps have their own way to
communicate inflation, and for them it wouldn't make any difference
one-way or the other. Where it becomes a problem is if you try to
strictly respect the store-and-forward nature of email and avoid
introducing challenge-response protocols between clients and/or users,
other than perhaps one way notifications of rejection. As a base
strategy that systems like CAMRAM, TMDA etc can extend with
challenge-response functionality while remaining fully compatible over
time with the base store-and-forward no-challenge approach.
Thoughts?
I'm just trying to avoid making big problems and complexity later by
trying overly to avoid small problems now, a common software
deployment mistake IMO.
Adam
Other related posts:
