From: "Donald E. Eastlake 3rd" <dee@cybercash.com>
Date: Fri, 10 Nov 1995 03:47:44 +0800
To: cypherpunks@toad.com
Subject: Re: (cpx) Re: ecash speed
In-Reply-To: <v02120d03acc7c8d9c381@[199.0.65.105]>
Message-ID: <Pine.SUN.3.91.951109140743.26577A-100000@cybercash.com>
MIME-Version: 1.0
Content-Type: text/plain


There is certaily no need for an extra connection from the merchant back
to the customer.  See draft-eastlake-internet-payment-00.txt.

Donald (not on cybpherpunks)

On Thu, 9 Nov 1995, Robert Hettinga wrote:

> 
> --- begin forwarded text
> 
> Date: Wed, 8 Nov 1995 21:08:51 -0800
> From: Hal <hfinney@shell.portal.com>
> To: cypherpunks@toad.com
> Subject: Re: ecash speed
> Sender: owner-cypherpunks@toad.com
> Precedence: bulk
> 
> "Perry E. Metzger" <perry@piermont.com> writes:
> 
> >Hal writes:
> >> The point is that if the anonymity afforded by ecash is too costly in
> >> terms of time, then we may end up stuck with a non-anonymous system
> >> simply because that is the only one efficient enough to work.  It would
> >> be good to find out if that is a serious problem.
> 
> >I suspect that as CPU speed exponentiates this will become less and
> >less of a problem. It doesn't especially worry me.
> 
> Consider, though, what happens in the current ecash system if it were
> used to charge a penny per page.  You would click on a link in your web
> browser to go to the new page.  It would set the GET request to the
> remote server as usual.
> 
> The server would fire up a CGI script which will run the shop software.
> That software will make a TCP stream connection back to your ecash wallet
> software which is running on the system where your client is.  It sends a
> request to get payed $.01.  Assuming the wallet is configured to
> automatically approve such a payment, it will send a one penny coin to
> the shop software along the opened link.  (This may also involve doing a
> PK encryption on the coin as an anti-theft measure; this aspect of the
> current ecash system is not documented AFAIK.)
> 
> The shop software then opens a TCP stream connection to the bank, and
> forwards the coin there.  The bank receives it, and checks the public
> key signature in the coin.  It then compares the coin against every other
> coin which has ever been spent (within the validity period of the coin)
> to make sure it is not being doubly spent.  If this all checks out it
> sends back some authentication message to the original server.  The shop
> software then delivers the new page to the client browser.
> 
> This all has to happen whenever you click on a link in your browser.
> Even with fast CPU's I think the extra step of connecting to the bank,
> having it check against all coins, and getting approval will be
> considerable for each link traversal.
> 
> Hal
> --- end forwarded text
> 
> 
> -----------------
> Robert Hettinga (rah@shipwright.com)
> Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
> USA (617) 323-7923
> "Reality is not optional." --Thomas Sowell
> >>>>Phree Phil: Email: zldf@clark.net  http://www.netresponse.com/zldf <<<<<
> 
> 
> 

=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)