It is possible to defend against this threat, but not cheaply, since
the defense requires a robust transaction system that can serialize
the thousand requests, approve one, and reject the other 999, while
still providing service to the rest of their customers.
I'm not clear which party you're talking about here. The "bank" takes
redemption requests serially and acts on them serially. The list of
valid tokens can be kept in RAM. That amounts to no measurable delay.
Um, you might be surprised. Locking systems that just serialize
everything into one queue are unlikely to be fast enough to be
interesting, particularly if you hope to handle an interesting fraction
of Internet mail, which by my back of the thumb estimate is about two
million messages/second.
Also, unless the bank is planning to keep all the money for itself, it
needs to have some way for the client presenting the tokens to collect
the money eventually. That means either a book entry system where
each client has an account and the bank has to mark the token as
having been paid into that account, or a bearer system where the bank
creates and sends the client a reissued token that it can cash in
later.
People have been thinking about micropayments for 15 years, and
transaction systems for 50 years (really), and you are assuming a
cheap solution to a long-term unsolved problem.
That's why I think it would be a good idea to at least develop the
model to the point where we can evaluate whether a putative solution
is good enough.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg