Reply From: William T Wilson <fluffyt_private> > > in any significant way. If your are doing bank to bank transfers, you > > simply move the digital coins to the other end, making sure you delete > > them out of your vault. Otherwise you could have 2 different ... > There's a problem with this, though. Electronic coinage can be copied > directly as a series of bytes. Physical coinage includes the defense This, to put it bluntly, doesn't work. :) You can copy the coinage as a series of bytes, but you still can't spend it. It is similar to signing an email with a PGP signature. You can copy my PGP signature but that doesn't allow you to forge email from me, because the signature is dependent both on the content of the message and my private key. You can copy the signature, but it's valid only for that particular message. For a real world analogy, I can take a picture of your money, but I can't spend the picture. :) There are a number of issues involved with the use of electronic "coins." However, here is a brief (and imperfect, but illustrative) example: I have money in a bank. Suppose I want to spend some. I construct a message telling the bank how much money I want to spend and where I want to spend it. I stamp this message with my digital signature, then encrypt it with the bank's public key. I send it to the bank, who decrypts it, verifies my signature, and deducts the money from my account. The bank issues me a digital coin, encrypted with their own public key, then they add information to tell the merchant how much the coin is worth, and they encrypt it again with the merchant's public key. I spend this digital coin, which is unique, at some merchant, by simply giving it to him. The merchant decrypts it with his private key and verifies it is the right amount, then he "stamps" the coin with his digital signature and sends it to the bank. Then the bank validates the stamp and credits the merchant's account. You can't duplicate the coin as it goes over the network because it's encrypted with the merchant's public key; no one but the merchant I'm paying would be able to make sense of it. Similarly, I can't try to spend this coin somewhere else, again because the second merchant would not be able to decrypt it. You could copy the encrypted coin and try to spend it again at this merchant, but this merchant will know that he's seen this coin before, and he better not accept it. There are two problems with this system. First, it is bad for privacy; unlike regular cash, it's traceable. If you give me physical cash, I don't need to know who you are, and the bank doesn't need to know you spent this money. There are ways around this, but my example doesn't cover them. Second, it does require the consumer to contact the bank before spending the money. However, I'm not aware of any system which allows for 1) no need to contact the bank, 2) is immediately verifiable and 3) is immune to duplication. You get to pick two. :) As an advantage, however, the merchant doesn't need to contact the bank when he accepts the money; the consumer needs to contact the bank, but only when he spends it. He can cash in his coins whenever he wants to. -o- Subscribe: mail majordomot_private with "subscribe isn". Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:58:04 PDT