// COMPLETE THREAD

Re: Voice/Fax Checks

3 expanded posts ยท every known parent and child

NODE 109f0330Re: Voice/Fax Checks
At 11:38 AM 7/21/94 -0400, solman@MIT.EDU wrote:
>The selling point for digital cash is that it has a low transaction cost
>and can easily be used for extremelly small transactions. If agent A and
>agent B want to do business without bothering their owners, you had better
>have some robust digicash.

I've made this claim myself here before.  It's possible you're in a
position to verify it.  Can you?

Cheers,
Bob

-----------------
Robert Hettinga  (rah@shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923
NODE 0b4277f1Re: Voice/Fax Checks
> At 11:38 AM 7/21/94 -0400, solman@MIT.EDU wrote:
> >The selling point for digital cash is that it has a low transaction cost
> >and can easily be used for extremelly small transactions. If agent A and
> >agent B want to do business without bothering their owners, you had better
> >have some robust digicash.
> 
> I've made this claim myself here before.  It's possible you're in a
> position to verify it.  Can you?

Not yet. But I'm just a few weeks away from Alpha testing a very
large web-based project which has all sorts of agents interacting
with each other and dealing in very small amounts of money. It
includes a second rate (but effective) digital cash protocol.
When I'm done (which will be very soon), I'll post the code
here so everybody can tell me what's wrong. I am presently
attempting to upgrade the digital cash to a new method that
I've devised (using other people's demonstratedly secure
primatives of course). That's why I joined this list recently.

I am sure of two things:

A) To extract the greatest possible value from human time,
it is necessary so set up a complex infrastructure of agents
that can abstract tasks whenever possible.

and

B) A system like this can not exist without a method of
dealing with extremelly small monetary transactions.

If my confidence is not misplaced, digital cash is simply
required by the digital future.

JWS
NODE 960c362fSmall transaction amounts
Not yet. But I'm just a few weeks away from Alpha testing a very
   large web-based project which has all sorts of agents interacting
   with each other and dealing in very small amounts of money. It
   includes a second rate (but effective) digital cash protocol.

In a closed computational environment, there is no need for
cryptographic digital cash.  Telescript, for example, is a closed
computational environment, at least now.  Inside such an environment,
one can rely upon the fact of closure for security in money transfer.
The operators of the closed place provide an assurance that running
the agents will be done as expected, and that funds will flow as
expected.

I can't tell from the above quotation whether the project is closed in
this way or not.  Verbum sapienti ...

The cost of cryptographic computation, database lookups, and amortized
staff time (the most expensive, and not getter cheaper nearly as fast
as the others) for each transaction has some characteristic minimum
value.  The transactions cleared through such a system will have their
own minimum, which will be on the order of the cost of provision.

One can create closed environments expressly for the purpose of doing
this kind of low-cost low-level transaction.  These systems have
reduced resource requirements and will always be cheaper to operate
than a full scale digital cash scheme.

The closure, however, of these systems means that they don't scale.
That's bad, fatal, in fact.  That doesn't mean that closed systems
will disappear, merely that the largest systems must be open.

What is desirable economically is that the boundary between closed
clearance systems and open clearance systems be porous enough that the
market can find an optimal distribution between the two varieties.

Eric