TO: >internet: cypherpunks@toad.com Forgive me for a newbie question. Why wouldn't the following inelegant idea work? X gives $101 to First Digital Bank, which gives X a PGP-signed password representing a claim on $100 (or maybe they would do this just for the "float"). X gives the $100 password to Y, in exchange for a narco-terrorism decoder ring. Y, being a cautious soul, calls First DigiBank immediately and gives it the password. DigiBank pockets $1 and issues Y a new signed password good for $99. Note that DigiBank (1) doesn't need to know who Y is and (2) ensures that a given money-password is only spent once. By the same method, Y can pay Z and Z can deposit the credit in BillnHill's S&L for settlement. Or the money can keep floating around until DigiBank gets it all, which is what usually happens now ;-) Of course, you have to trust the bank - but you have to now, also. Don't abuse me too much. Just point me to the right FAQ (...cowering...) bdolan@well.sf.ca.us
Well, there are a couple of problems, but I'll only ask about one: How do you make sure that the bank doesn't earmark the "password" with X's name? You don't want the bank to know that that "password" was given to X. -derek
A newbie, bdolan <71431.2564@CompuServe.COM> timidly asked:
X gives $101 to First Digital Bank, which gives X a PGP-signed password representing a claim on $100 (or maybe they would do this just for the "float"). X gives the $100 password to Y, in exchange for a narco-terrorism decoder ring. Y, being a cautious soul, calls First DigiBank immediately and gives it the password. DigiBank pockets $1 and issues Y a new signed password good for $99. Note that DigiBank (1) doesn't need to know who Y is and (2) ensures that a given money-password is only spent once. By the same method, Y can pay Z and Z can deposit the credit in BillnHill's S&L for settlement. Or the money can keep floating around until DigiBank gets it all, which is what usually happens now ;-)
Well, it could work that way. The only thing that I see being a problem is that you're using public-key crypto when you don't really need to. This allows the bank to associate a public key with an identity. (which is what Derek Atkins <warlord@MIT.EDU> said.) But, basically, you could simplify the system to this: X has a password which is worth $100 in cash from FDB. X gives the password to Y. Y then calls the bank and changes the password to whatever he wants. Y now has $100 digital money (minus the bank's transaction fee). The bank has no way of knowing who gave them the new password. (You could also have the bank generate random passwords, and give them to the client.) Notice that no public keys (and no identification) is used. The only need for public keys in such a situation would be to establish a secure transmission channel; in which case, someone could make up a random keypair, make a transaction with the bank and then discard the private key - the money would be identified by the secret password. The only other thing to point out, is that each digital coin/token/denomination must have its own password - what if he only wanted to spend $57 and not $100? So each dollar would have to be seperate; to spend $100, X would have to give Y 100 seperate passwords. Unless, of course, you have digicoins of different denominations, but then you have to have correct change. Of course, you are still left with the the problem of needing to trust the bank. :( Good point about the bank taking its cut - I think we need to come up with a fair system for dealing with that... P.S. I'm glad to see some people on this list still want to talk about real crypto, instead of, ahem, other distractions...
participants (3)
-
bdolan -
Derek Atkins -
Matthew J Ghio