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
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
Return to January 1993
Return to “ghsvax!hal@uunet.UU.NET (Hal Finney)”
1993-01-24 (Sat, 23 Jan 93 17:29:09 PST) - Digital cash redux - ghsvax!hal@uunet.UU.NET (Hal Finney)