John Levine <johnl(_at_)taugh(_dot_)com> wrote:
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.
Sigh.
... psi-star dV
There are lots of transaction systems that work well, and have
been since about 1964.
OK, the problem still might be defined wrong if it takes fifteen
years to solve...
But there are no transaction systems that handle a very high
transaction rate, most of which are rejected and provide no revenue,
at a cost of a tiny fraction of a cent per transaction.
Then, let's stop trying to do all that at once.
We need the high transaction rate.
We need to be able to reject, say, 99% of the requests.
We don't need to charge nothing at all for a rejection.
Being a bear-of-small-brain, I prefer to have the "bank" charge
for rejected transactions. This allows the receiving MTA a wide choice
of strategies for deciding how quickly (or even whether) to present
tokens for redemption. (Tarpitting is still a useful tactic.)
We haven't even started to consider how the transactions get in and
out of the systems with the RAM,
Quite true -- and that's a more serious bottleneck, IMHO...
and I don't think it would be productive to do so at this point.
Nor do I -- it's an unrelated problem with standard solutions.
That's why I really think it would be a good idea to figure out what
sort of performance and what sort of cost an e-postage system would
need, as a prototype or as a production system,
I believe we could do useful research with a million-per-day volume,
but it seems pointless to me not to design the "transaction" portion
to handle a million-per-second (leaving network I/O as the bottleneck).
By "transaction" I mean:
- a customer with sufficient credit balance asks for a token; or
- a customer with an existing account asks to redeem a token.
In neither case does the "transaction" need to debit or credit the
appropriate account at the microsecond of the "transaction" -- these
could be batched for processing an hour later if necessary. The
"transaction" involves only the creation and redemtion of tokens
issued by the "bank" and redeemed by the same "bank".
The actual per-transaction pricing is an open issue -- I'd guess
an upper limit is around a tenth of a cent per "transaction", but
I expect competition to drive that well below a hundredth of a cent.
(For research, a goal of a tenth of a cent seems fine.)
so in the even that someone came up with a concrete design, we could
tell whether it's within an order of magnitude of being workable.
Be my guest...
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg