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
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!"
Return to March 1994
Return to “tcmay@netcom.com (Timothy C. May)”