John Levine <johnl(_at_)taugh(_dot_)com> wrote:
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.
I see no problem handling one million queries per second in a
RAM-based system. Locking is likely overkill -- the tokens in RAM are
known-good (or already deleted): the debit/credit need not be real-time.
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.
That choice should be up to the bank. I was thinking book-entry
with credit/debit lagging token redemption by perhaps a few seconds.
(Locking for the book-entry part is worth doing.)
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.
I'm assuming the problem is defined wrong if it takes 50 years
to solve. Once you separate token creation/redemption from _all_
other accounting (by journaling the creation/redemption) it becomes
much simpler. And once you move the token database into RAM, timing
problems pretty much disappear.
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.
Ben is working on that.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg