On Thursday, April 24, 2003, at 06:46 PM, Joris Bontje wrote:

Like Patrick M (the Lucrative-one) said, it is unlinkable-by-policy vs unlinkable-by-mathematics. If you don't blind coins (and want them to be able to be linkend), the easiest solution is storing the valid coins. If you do have blinded coins, the only solution is storing spend coins.

Strictly speaking, my server stores neither the valid nor the invalid coins. It stores the hashes of the valid coins. Therefore, the server has no way of discerning the details of any coin stored in its database. All it can do is recognize a valid coin when it sees one, and immediately extinguish it and issue a new one. So, can somebody give me a concrete example of a "linkage" problem here? I'll tip you a couple of grams in the DGC of your choice if you can do a good job of it. One person suggested that Citibank might issue a coin X to Alice, who then spends it at Bob's Kinky Sex Emporium, who then deposits that coin at Citibank. Citibank begins building a profile of Alice's kinky tastes because it remembers issuing X. But that is simply not how it works. Citibank issues coin X to Alice. Alice immediately swaps X with the server and obtains a new coin Y. Alice gives coin Y to Bob in return for kinky porn. Bob immediately swaps Y with the server and obtains a new coin Z. Bob gives coin Z to Citibank. Citibank immediately swaps coin Z with the server and obtains a new coin A. I do not see "linkage" here. Citibank never sees X again. To be clear, I am NOT trying to solve the problem of having a coin circulate several times out in the wild without any contact with a server, and somehow prevent a double spend in that scenario. I do not see how that is even remotely possible. Alice has a fancy string of bits on her computer. She transmits that string of bits to Bob and gets a sweater. Then she transmits the same string of bits to Charles and gets a beer. You cannot prevent this without consulting a server. -- Patrick http://fexl.com