1994-03-26 - Re: Digital Cash

Header Data

From: Mikolaj Habryn <dichro@tartarus.uwa.edu.au>
To: mpd@netcom.com (Mike Duvos)
Message Hash: 08de0ef81b90fb931f734761eb4407193f0c9517cafbcd36e7b6ea7409e227b1
Message ID: <199403261347.VAA23017@lethe.uwa.edu.au>
Reply To: <199403251544.HAA10502@mail.netcom.com>
UTC Datetime: 1994-03-26 13:10:55 UTC
Raw Date: Sat, 26 Mar 94 05:10:55 PST

Raw message

From: Mikolaj Habryn <dichro@tartarus.uwa.edu.au>
Date: Sat, 26 Mar 94 05:10:55 PST
To: mpd@netcom.com (Mike Duvos)
Subject: Re: Digital Cash
In-Reply-To: <199403251544.HAA10502@mail.netcom.com>
Message-ID: <199403261347.VAA23017@lethe.uwa.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


	Just a thought on ways to deter all of this multiple spending 
gunk - when you start off, have a centralized bank server. While traffic 
is low, you can have each individual certificate cleared with the bank 
server upon creation and execution. After that, things start getting 
tricky. Maybe a network of bank servers linked by high priority internet 
links (i don't suppose there really is such a thing, but this is 
dreamland, after all). This would mean that to cash a certificate more 
than once would require very fast and accurate timing, and if you combine 
this with a fairly low upper limit for certificate value, it becomes a 
waste of time try.
	Oh well. Just my A$0.02.

MJH

*       *       Mikolaj J. Habryn
                dichro@tartarus.uwa.edu.au
    *           "Life begins at '040."
                PGP Public key available by finger
    *           "Spaghetti code means job security!"





Thread