1994-07-05 - Re: BoardWatch on digital cash

Header Data

From: rah@shipwright.com (Robert Hettinga)
To: mech@eff.org (Stanton McCandlish)
Message Hash: f42a1721a99ac02860cac83c44c2334ec27f5a32cd8033d18c9aea3c49e0bb9e
Message ID: <199407052107.RAA14918@zork.tiac.net>
Reply To: N/A
UTC Datetime: 1994-07-05 21:08:44 UTC
Raw Date: Tue, 5 Jul 94 14:08:44 PDT

Raw message

From: rah@shipwright.com (Robert Hettinga)
Date: Tue, 5 Jul 94 14:08:44 PDT
To: mech@eff.org (Stanton McCandlish)
Subject: Re: BoardWatch on digital cash
Message-ID: <199407052107.RAA14918@zork.tiac.net>
MIME-Version: 1.0
Content-Type: text/plain


At 11:50 AM 7/5/94 -0700, Timothy C. May wrote:

>But all but a very few of them are polar opposites of what we as
>Cypherpunks want. Microsoft wants home banking, VISA wants it, and
>various cryptographically-incompetent schemes are being proposed.

I've been talking off line with people about business models for e$.

We have to deal with the fact that for most people privacy is not as big an
issue as it is for us.  There was a quote in MacWeek today to the effect
that 80% of the people are satisfied with 70% of the Mac's functionality,
and so they buy Windows.

With that in mind, here are three business models for discussion.

The Redmond Scenario: Here's a business model (not a new one either) which
has 70% of the functionality of DigiCash(tm), and that 80% of the people
will buy into. It works like those ATM terminals you see at grocery store
checkout counters now. But I think there's also way to hack into it a
DigiCash(tm) option later...

Attach a card-swiping peripheral to a PC. Use secure Mosaic or equivalent
as the transaction protocol. When someone buys something from a vendor, the
HTML form asks for a swipe in the reader and the customer's PIN. The latest
version of "Debbie Does Ft. Meade, LXIX" is then downloaded to the
customer.  The customer has just made a trusted-third-party "cash"
transaction.  Obviously, this for credit card transactions, too.  For a
"cash" transaction, the vendor's software sends a secure (vendor can't
tamper, either) message including card swipes and PINs for both the
customer and the vendor, crediting the vendor's account and debiting the
customer's account to an ATM gateway (probably sold to a bank as a
"drive-up window on the information superhighway"<gak!>) . Instant
transaction settlement. Not private.

The Cupertino Scenario:  This one of many right ways to do DigiCash(tm). It
achieves the same result (DDFM LXIX is sold) as the Redmond Scenario with
the same technology.  In this case, the ATM gateway sells (for some
combination of a spread and float interest on outstanding cash)
Digicash(tm) directly to the purchasers, just like physical ATM does with
paper cash at a shopping mall.  The transaction is done with a card swipe
and the cash is put on the customer's hard drive to be spent. Consumer uses
digital cash to buy DDFM LXIX. Vendor either keeps e$, or deposits with own
bank, or cashes it out with DigiCash(tm) issuer.

The Houdini (more lives than a cat, that Houdini...) Scenario. Just like
Redmond scenario but, in every transaction, the option is there to use
DigiCash(tm).  The reason the option is kept alive is that the bank (the
owner of the "drive up window"<gak!>) gets a *commission* on DigiCash(tm),
just like they do with Travelers' Checks.  If the customer pays with
DigiCash(tm), the swipe/PIN doesn't touch the vendor, it goes to the ATM
gate. e$ is issued to the customer and used to pay off the vendor, who
doesn't even have to have a bank account at this point, which "suitably
incentivizes" the vendor to maybe offer a discount, 'cause his costs are
lower. (Eric has killed me on this already, but I stand ready to be killed
for it again. Sigh)  Customers are "incentivized" by privacy, of course...

>What we can do to head them off or to deploy the right kinds of
>systems is the challenge ahead of us.

As I said to somebody offline a while ago.  The thing we don't want to do
is provoke an immune response from the banking system before we get
started.  I believe that there are all sorts of real good reasons the
banking community would like to do e$.  I think that we may have evolution
on our side here.  It seems to me that strong crypto transaction settlement
and e$ are the necessary and *sufficient* conditions for the kind of global
information economy that most people on this group believe is coming.

One of the things I thought about was the idea of a conference on internet
commerce, geared toward educating a smallish (100-150) business,
regulatory, and finance people about the technology and the potential of
e$.  I wrote up a bunch of dog-and-pony slides outlining an agenda and
potential speakers, and then the ritalin wore off. ;-). Nonetheless, I have
been doing a bunch of work for the World Trade Center in Boston lately
(where the air-conditioned part of MacWorld is held ;-)), and my client
referred me to a good conference planner.  If anyone wants to egg me on
about this, (I'm *not* asking for free work from *anyone*, I swear) e-mail
me.  I could use some moral support, at the least.

>But it will
>be a tough struggle, as things are moving fast behind the scenes.

Would you like to share something, Tim? (jeez, I sound like I'm in a CR
group...)

>
>(My greatest fear: legislation to support home/cable banking, with
>restriction on competitors.)

Remember that Citicorp has been plugging home/telephone banking for years.
I also think that any regulatory response at this point will only cause the
kinds of "regulatory arbitrage" Eric has been talking about.



-----------------
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







Thread