Re: [Asrg] About that e-postage draft [POSTAGE]

[John Leslie <john at jlc.net>]

John Levine <johnl at taugh.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.net>