From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 7a4f2e8da17d0ba7d018a6f181c4816c68065716512705e8740051a70417d2e4
Message ID: <9407230243.AA00502@ah.com>
Reply To: <199407221914.MAA18128@jobe.shell.portal.com>
UTC Datetime: 1994-07-23 03:06:00 UTC
Raw Date: Fri, 22 Jul 94 20:06:00 PDT
From: hughes@ah.com (Eric Hughes)
Date: Fri, 22 Jul 94 20:06:00 PDT
To: cypherpunks@toad.com
Subject: Voice/Fax Checks
In-Reply-To: <199407221914.MAA18128@jobe.shell.portal.com>
Message-ID: <9407230243.AA00502@ah.com>
MIME-Version: 1.0
Content-Type: text/plain
This seems like a good approach for a lot of cases. You end up having
three classes of transactions: small, medium, and large, with slightly
different strategies for each.
There are more categories than these, actually. There's already a
banking distinction between large and very large. One of the high end
funds transfer systems in the world has a _minimum_ transaction size
of about two million dollars. You can bet that these are handled
differently than a one thousand dollar check (still "large").
In addition to direct costs of provision, there are also effective
costs of collection risk. At each level, these collection risks have
to be estimated and taken into account. Since the real desire is for
a known upper bound, some fraud or other form of transaction failure
can be expected.
When credit is being offered (even intra-day), the risk increases
proportionally. Every off-line system offers some amount of credit,
however small.
Paying a penny per
site isn't going to bother me much, but if I have to set up an account
for each one ahead of time I'm probably not going to bother.
You can still use an account mechanism, but with an intermediary whose
business it is to aggregate small amounts as these proposed and clear
the total periodically. That's now one account setup for the
customer.
Eric
Return to July 1994
Return to “solman@MIT.EDU”