-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, April 24, 2003, at 05:27 PM, Adam Back wrote:
If the coins offer privacy, then unspent coins are unlinkable when the same coin is deposited, so keeping just unspent coins doesn't work.
Spent coins on the other hand have their blinding removed, so you notice double spending by looking at spent coins.
(There are zero-knowledge proofs of non-set membership as proposed for use in ecash by Sander and Ta-Shma [1], but I think these are quite computationally expensive.)
Although I have read some material on blinding etc., I do not see a need for it in my system. At Tim May's suggestion I shall avoid using the word "coin" and use the more accurate financial term "note" instead. Although technically a note in my system is <32-bit file position><256-bit random gibberish><64-bit amount>, I'll use a simpler and abbreviated decimal notation with dashes in the quick example that follows. Alice has a note "0247-223235898-00032" that entitles her to 32 grams of e-bullion. She decides to take delivery. She presents the coin to the server and the server computes the RIPEMD-160 hash. It looks at record number 247 in the data file and sees if the hash stored there matches the computed hash. If so, the server extinguishes the coin (randomizing the record and chaining it to the free list) and spends 32 grams of e-bullion to the account that Alice designates, no questions asked. (Obviously you have to handle any errors in the e-bullion spend - -- don't extinguish the coin if the spend fails.) Now Alice tries to pull a fast one. She presents that same note "0247-223235898-00032" to Bob. Bob decides to swap the note for a new one. He presents it to the server. The server computes the RIPEMD-160 hash. It looks at record number 247 in the data file and sees that the record is on the free list. It rejects Bob's request. Double spend prevented. Now perhaps in the meantime the server has decided to reuse record 247. In that case there is a brand new note hash sitting there, and it is astronomically unlikely to match the hash of the "0247-223235898-00032" note. (I have considered issuing serial numbers that are never reused but for some vague reason I don't quite like that. It might not be a big deal.) Again, double spend prevented. Quite simply, the absence of a match indicates a spent coin, or one that was never issued in the first place. It's very much like GoldMoney payment keys, which simply say YES or NO when you try to redeem them, with no information given about whether it was EVER a valid payment key. If there is any problem of "linkability" in this scheme, please help me see it. The server does not log any socket events or transaction records of any kind. OK, if someone put a gun to my head and said "put in some code to log everything" then they might be able to discern some pattern like "this coin was issued to this IP address, and then three days later that coin was swapped from this other IP address." OK, that sounds like a potential problem, but I don't see how you can hide this information from the server ITSELF. When you present a coin to the server, it is going to know from which IP address it came, and I don't see a way around that. There is no linkability of personal identity in the system because there is no personal identity in the system, period. The server has no use for a public key from any user. - -- Patrick http://fexl.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBPqhhW1A7g7bodUwLEQL63gCg91lfShbCyCGQ68Bn2LAeY3Cv6wkAnAtR lEhm4j76EzsgzU/sdrm6TNbV =4OMx -----END PGP SIGNATURE-----