1994-07-23 - Re: Voice/Fax Checks

Header Data

From: solman@MIT.EDU
To: roy@sendai.cybrspc.mn.org (Roy M. Silvernail)
Message Hash: fa3743a80720e705dfe466edf96cf5cba91611eabbe5f5199931ccfd33511218
Message ID: <9407231647.AA20693@ua.MIT.EDU>
Reply To: <940722.183524.4a8.rusnews.w165w@sendai.cybrspc.mn.org>
UTC Datetime: 1994-07-23 16:47:51 UTC
Raw Date: Sat, 23 Jul 94 09:47:51 PDT

Raw message

From: solman@MIT.EDU
Date: Sat, 23 Jul 94 09:47:51 PDT
To: roy@sendai.cybrspc.mn.org (Roy M. Silvernail)
Subject: Re: Voice/Fax Checks
In-Reply-To: <940722.183524.4a8.rusnews.w165w@sendai.cybrspc.mn.org>
Message-ID: <9407231647.AA20693@ua.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In list.cypherpunks, solman@MIT.EDU writes:
> 
> > I don't agree on this point. I prefer license based e-cash which is 
modified
> > on each transaction (and unfortunatelly gets slightly bigger -- the 
downside
> > of this method).
> 
> I'm not clear on this point.  Is this an audit trail built into the
> e-cash?  I'm not so sure that's a Good Thing.

When properly implemented, nobody can deduce anything from the "audit trail"
other than the validity of the e-cash. If somebody cheats, only the cheater
(and people who reuse his money without checking first) is revealed. I should
note that the Japanese system that I started with does not quite cut it in
this reguard. A tiny bit of probabilistic encryption goes a long way
towards imporving their system. (Vendors and banks could otherwise deduce
things when they saw the same license).

On a more important note, I believe that in one of the papers on my to-read
list for this weeked, Chaum demonstrates that e-cash can not be transferable
unless it grows bigger. Otherwise you have to give it back to the bank and
get a new one each time it is used. Given this, I think that it is highly
desireable for us to accept the increasing size of the e-cash and maintain
its transferability.

JWS





Thread