1994-08-25 - Re: In Search of Genuine DigiCash

Header Data

From: Jason W Solinsky <solman@MIT.EDU>
To: rah@shipwright.com (Robert Hettinga)
Message Hash: 9f9629bab2f18857bafba93b3972ef2e5dcc883aa20d275907d8b56842b68a03
Message ID: <9408250247.AA19389@ua.MIT.EDU>
Reply To: <199408241227.IAA22728@zork.tiac.net>
UTC Datetime: 1994-08-25 02:47:50 UTC
Raw Date: Wed, 24 Aug 94 19:47:50 PDT

Raw message

From: Jason W Solinsky <solman@MIT.EDU>
Date: Wed, 24 Aug 94 19:47:50 PDT
To: rah@shipwright.com (Robert Hettinga)
Subject: Re: In Search of Genuine DigiCash
In-Reply-To: <199408241227.IAA22728@zork.tiac.net>
Message-ID: <9408250247.AA19389@ua.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


> At 10:08 PM 8/23/94 -0400, Jason W Solinsky wrote:
> >Well we agree that the selling point is economic efficiency. But "anonymity
> >reduces overhead" ?
> 
> I keep getting tangled up in that. I'll try again. Anonymity is not the
> issue. Strong Cryptography is the issue. Anonymity comes from strong
> crypto. Like I said before, anonymity is the byproduct of using strong
> crypto to build a digital cash system.

No it isn't. Making a digital cash system secure, scalable and distributed
is a non-trivial task, making it anonymous is still more difficult.
Guaranteeing anonymity creates alot of problems as was brought out in a
previous discussion on license based cash in which it was pointed out
that by colluding with consumers a bank can still "mark" bills.

> It turns out that in creating an anonymous digital cash system, you can do
> very cheap, irrefutable transactions offline in an internetworked
> environment.  That's cheaper for a whole lot of reasons, a relatively minor
> one being the ability to pool the cash without a lot of transaction
> recordkeeping. You don't have to know who gave you each piece of money in
> order to find who stiffed you, if it happens.

I am yet to see a single anonymous digital cash system which could not be
implemented more simply if the requirement on anonymity were not made. I
would be pleased to be proven wrong.

> The reduced overhead increases economic efficiency.

What I'm really asking is for an example of this overhead that is being
reduced.

> There are other reasons
> for not doing on-line transactions. Including credit checks, interest
> calculations on outstanding balances, vendor reserve requirements,
> transaction threading, on-line wait states and bandwidth, etc.  It's
> considerable.

And its going to get more considerable when we have communities of agents
arguing with each other. I think we want to solve the problems created by
these requirements, not shy away from them.

JWS





Thread