1993-01-24 - Digital cash redux

Header Data

From: ghsvax!hal@uunet.UU.NET (Hal Finney)
To: cypherpunks@toad.com
Message Hash: 8413e21a8cc78795bb734e2b7cbfb9aaa246b4343b6443ad9f6fe5a814fd8912
Message ID: <9301240115.AA11642@nano.noname>
Reply To: N/A
UTC Datetime: 1993-01-24 01:29:09 UTC
Raw Date: Sat, 23 Jan 93 17:29:09 PST

Raw message

From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Sat, 23 Jan 93 17:29:09 PST
To: cypherpunks@toad.com
Subject: Digital cash redux
Message-ID: <9301240115.AA11642@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Here is an excerpt from a description of one version of Chaum's
digital cash, which I posted on Nov. 25:

> There are lots of proposals for electronic cash in the literature,
> mostly very complex.  I think one of Chaum's simpler proposals would be
> adequate for email "banking".  This proposal, from the beginning of
> his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like
> this:
> 
> 1. Alice chooses a random x and r, and supplies the bank with
> B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is
> the modulus for the bank's public key.
> 
> 2. The bank takes the third root of B (e.g. via an RSA decryption) and
> sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from
> her account.
> 
> 3. Alice extracts C = f(x)^(1/3) by dividing D by r.  (Note that
> division can be done mod n without knowing the factors of n, but it's
> rather complicated.)
> 
> 4. To pay Bob one dollar, Alice gives him (x, C).
> 
> 5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C)
> to the bank in order to make sure that x hasn't been used before.
> Otherwise Alice could spend (x, C) twice.  The bank increases Bob's
> account by one dollar.
> 
> This scheme is pretty simple and provides untraceability - the bank
> saw B and D but not C, so although it can verify that (x, C) is legit,
> it can't correlate that with Alice's withdrawal.
> 
> The main disadvantage of this approach is that Bob has to send (x, C)
> to the bank right away (or at least before sending Alice anything in
> return for her cash) to verify that the cash hasn't been used before.
> But in email, where turnarounds of a day or more aren't unusual, this
> should be tolerable.
> 
> Alice and Bob could be pseudonyms, using anonymous addresses to
> communicate with each other and with the bank.
> 
> Different denominations of cash could correspond to different
> exponents than "3" in the example above.  (That is, $1 would use
> C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7),
> and so on.)
> 
> Technically, this would be quite easy to implement, using the code in
> PGP for the arithmetic, and MD5 for the one-way function.  We'd need
> to define a few message formats.  The RFC1113 ascii encoding from PGP
> could be used as well.
> 
> The "social" problems are more challenging, it seems to me.  What is
> the backing for this electronic money?  Why do people care what their
> bank balances are?  Is this stuff really worth anything?
> 
> One possibility is to base digital cash on real money.  People would
> open a pseudonymous account via email, then postal-mail dollars to the
> bank, enclosing their account number so the bank would know whom to
> credit with the deposit.  Later, if someone wanted to withdraw "real
> money" from their account they would have to give a real postal
> address where it could be mailed.  Now the electronic money is worth
> real dollars.  Even if people didn't deposit or withdraw very often,
> it still has value because of the backing.
> 
> Unfortunately, this approach would currently be illegal (at least,
> unless you actually were a real bank!).  If there were some way the
> bank itself could be anonymous, it might survive, but I don't see how
> to mail it money while keeping the anonymity.  Still, we could
> consider experimenting with this on a small scale with accounts of no
> more than a few dollars.  As long as it was clearly an experiment I
> doubt that any prosecutions would result even if it attracted
> government attention, because the expense involved in court costs
> would be so disproportionate to the few dollars involved in this
> technically illegal act.
> 
> Another approach would be not to try backing the digital cash at all,
> or rather backing it implicitly by the determination of various people
> to accept it and perform services or supply goods in return for it.
> Tim's offer to Xerox papers in return for digital cash would be one
> example.  Perhaps others could provide some other services.  It would
> be great if some shareware author would accept digital cash as a
> symbol of support for crypto anonymity.
> 
> One problem that I see with this approach is how you determine the
> size of the money supply.  Or, in other words, how does new digital
> cash get started circulating?  How do people get new accounts, and how
> much money is in them?
> 
> If these problems can be solved, a big advantage of this approach is
> that the banker can be anonymous.  He would be known only by his
> anonymous address and his public key(s).  This would provide some
> safety in the event that even a small-scale experiment like this
> was targetted for a crackdown.
> 
> Another issue is the prospect of multiple "banks", each issuing their
> own (incompatible) cash.  How would they compete?  Perhaps in terms of
> rapid turnaround?  Some might choose to be anonymous, others would go
> public.  The latter would have the advantage that people might trust
> them more, but OTOH there is more chance of your bank account
> disappearing after a crackdown for a public bank than an anonymous
> one.
> 
> Lots to think about here!
> 
> Hal
> 74076.1041@compuserve.com





Thread