1996-06-23 - Accounting costs: the need for better metaphors

Header Data

From: szabo@netcom.com (Nick Szabo)
To: cypherpunks@toad.com
Message Hash: 0a4260a41773867fda45d692c6e910aa4d7f7a451c6a5a96097c1ec95e67233a
Message ID: <199606222317.QAA28081@netcom.netcom.com>
Reply To: N/A
UTC Datetime: 1996-06-23 03:53:05 UTC
Raw Date: Sun, 23 Jun 1996 11:53:05 +0800

Raw message

From: szabo@netcom.com (Nick Szabo)
Date: Sun, 23 Jun 1996 11:53:05 +0800
To: cypherpunks@toad.com
Subject: Accounting costs: the need for better metaphors
Message-ID: <199606222317.QAA28081@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



To assess the desirability of a transaction, and to avoid being mischarged,
the parties to a transaction have to count up, ie account for, the 
money paid for particular products and services --  whether making 
sure that cash payments ar made as promised (eg looking at the 
display as products are scanned at the store, or the receipt afterwards), 
or making sure the phone bill is proper.  Herein I use "accounting" in
this broad sense.

I may be paying in cash, but I'd still like to keep track of how 
and why my cash is going in and out, for many of the same reasons 
that accountants reconcile and analyze book entries.  Right now a 
transaction log (whether ecash(tm)'s or a credit card's) is the 
most useful way to do this.  There may be other metaphors 
more appropriate for some circumstances (eg, eg absolute level gauges, 
rate gauges with high and low water marks, etc.); this is a potentially 
fertile new field to explore.  There may be agents that can do some
of the accounting (eg comparing payments made to terms promised, 
payment limits, etc.), but for the vast majority of products and
services software cannot judge the quality or personal desire for 
the product or service, and thus the net desirability of the 
transaction.  The user must undertake this comparison with whatever 
information the computer can provide via the display.  The user 
interface and the cognition of the user thus remain the bottleneck 
to transaction granularity.

A big task is to use the power of GUI to come up with new metaphors to make 
this easier.  It is the intuitive yet accurate metaphor that will lower
accounting costs.  Cryptographic protocols potentially lower only 
security-related transaction costs such as forgery and extortion.
For the normal accounting transaction costs, which are currently 
too high for micropayments, we need better interactive visual
metaphors.

For transactions free of records, we need transactions
that can be fairly transacted once, immediately accounted for
by the parties via a nice visual metaphor, then forgotten.  The 
potential for unresolvable disputes in record-free systems is vast for 
transactions where this is not possible (probably most
of desired commerce: where quality of a product or service 
cannot be well determined until after the purchase 
transaction is complete, or where credit is involved).

Price is one kind of contractual term; we also need nice metaphors
to keep track of other kinds of contractual terms.  Lack of 
observability of the protocol on the part of the user leads to 
the ability of the counterparty to engage in hidden actions.  
See "http://www.best.com/~szabo/smart.contracts.2.html" 
for further discussion of this and other computerized contracting 
issues.

One of the barriers to creating good contracts is determining
what the parties want in the first place.   People tend to think
in terms of standard or stereotyped conditions: payment in dollars,
investing in stocks, etc. when there exist a far wider variety of
alternative contractual structures that, combined properly, could 
better meet the parties' needs.  I'd like to see tools which allow 
parties to explore their desires interactively with the computer.  In 
finance this might include interactive personal yield curves, determining 
the partial order of desires (as in decision theory) for particular 
alternate securities, derivatives, and synthetics; and so on.  Software 
would then analyze this input, make recommendations, and even undertake
automated contracting(*).  Metaphors should be developed so that make it 
easy for lay users to express such desires without extensive knowledge of 
finance or decision theory.  Such metaphors would provide a friendly
front end to automated exchanges, auctions, and other online 
contracting mechanisms.

Currently budget programs (like Quicken) provide some of the
metaphors, and financial analysis programs provide extensive
feedback on the cash flow properties of particular contracts,
but a potentially large untapped market lies between in a 
combination of these two technologies.

(*) contracting-like transactions done by automated agents raise
interesting questions about what constitutes a "meeting of the
minds".


Nick Szabo
szabo@netcom.com
http://www.best.com/~szabo/





Thread