1994-08-29 - e$: e-cash underwriting

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: d81254f308ac8ae012f43a03838d7f42486fc040d049dd36b2940498b57d6f46
Message ID: <9408290735.AA29122@ah.com>
Reply To: <199408290315.XAA27012@zork.tiac.net>
UTC Datetime: 1994-08-29 07:56:58 UTC
Raw Date: Mon, 29 Aug 94 00:56:58 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Mon, 29 Aug 94 00:56:58 PDT
To: cypherpunks@toad.com
Subject: e$: e-cash underwriting
In-Reply-To: <199408290315.XAA27012@zork.tiac.net>
Message-ID: <9408290735.AA29122@ah.com>
MIME-Version: 1.0
Content-Type: text/plain

   Can you explain exactly how charging a back-end load on a digital cash
   certificate prevents double-spending?

In an online system, double spending gets immediately rejected, so the
only loss incurred by the bank is the cost of a database query.  So
the bank gets reimbursed for the cost of that query.  From the point
of view of the double spender, they pay something in order to get
nothing, although perhaps they can convince someone else to pay that
little something for them.  In either case there is no direct benefit
to a double spender, and there is a waste of time incurred.

Now, in an offline system, this doesn't work the same way, because
presumably goods or services are rendered before payment clears.
Remember differential time lags, and Herstadt risk--same issue,
different context.  So the fairly simple solution of charging for a
deposit attempt doesn't work.  (Regardless that the end of my previous
message said that it might.)

Chalk one up to the efficiency of online transactions.  A simple
product change, with very low impact, can entirely eliminate to
participate in an identity regime.

Of course, if you've got your heart set on offline...  Have I
mentioned how much more computation and communication those systems
require by all parties?