-----BEGIN PGP SIGNED MESSAGE----- In article <adc276f5060210049520@[205.199.118.202]>, Timothy C. May <tcmay@got.net> wrote:

I first read of Chaum's work in late '85, in his CACM article, and then "rediscovered" it when I was doing some review work for Phil Salin's AMIX information market startup in 1987.

Certainly the text of Chaum's articles implied both payer and payee anonymity, though certain details may've been unclear to some of us.

When Chaum unveiled his "payer is anonymous, but payee is traceable," some of us were surprised.

(On the other hand, I have had a longstanding faith that the system can be made to be both payer- and payee-anonymous. Moneychangers, for example.)

...

Deal with the devil?

Any "complete" digital cash implementation has to provide for payee anonymity.

I agree with Jim Bell on this completely. I don't know if Chaum has been seduced by the Dark Side, or is looking to get digicash widely deployed by "respectable" institutions, or is telling the truth (that his system _never_ provided for real untraceability), but I know that Cypherpunks should always strive for full untraceability.

One-sided traceability is not enough.

So here's the deal with ecash "as it works today": If a payment is made with ecash through some anonymous channel (like a remailer or a post to alt.anonymous.messages), neither the payee or the payor can directly identify the other (that is to say, neither's identity need be stored in, or used to construct, the payment). _However_, in the current implementation, the payor can collude with the bank to reveal the payee's identity. More specifically, the payor can produce the "blinding factor" he used when he withdrew the coins from the bank, which he later gave to the payee, who deposited them. The bank can use this information to figure out what the unblinded coin looked like, and then check its logs to find out who deposited that coin (remember that with the current implementation, when a coin is paid to someone, he must immediately deposit it, or risk losing the money if the payor tries to cancel the payment or spend it again). Note that the act of giving up the blinding factor will reveal _both_ parties in the transaction. That is, in order to reveal the payee, the payor must identify himself. (Not a big deal in the case of LEO...) This is because what is being identified is a "link" between a blinded coin that was withdrawn from the payor's account to the unblinded coin that was deposited to the payee's account. The way "full anonymity" works is that the coin is blinded by _both_ the payor and the payee before being withdrawn from the bank. That way, in order to reveal the link between the payor and the payee, _all three_ of the bank, the payor, and the payee must collude. This is not a big deal (the reasons for which are left as an exercise). Relevance: The ecash "concept" (numbers that _are_ money) produces an inherently bearer instrument (modulo double spending protection). The current software implements payor-side blinding only, in order to appease the Powers That Be. There's no reason why, given the information currently available, and even better when the library is released, with a weekend's work (a week if you're slow), you couldn't produce the handful of functions you'd need to implement the fully-anonymous protocol, REGARDLESS of whether you had access to the source to the current client or the library. The reson I bring this up is that yesterday, I had a 2.5-hour chat with David Chaum. These seemed to be the important bits: o The current plan is to release a lowish-level, binary-only library, as well as highish-level source which calls that library, and implements the published high-level API (http://www.digicash.com/api/). Release date: RSN. o The source to the current client, and the low-level library will _not_ be released. Dr. Chaum's main reason was that releasing the source would make it "too easy" to implement full anonymity, which he sees the various regulators seeing as a Bad Thing(TM). I disagreed. With the recent release of the byte-level encoding (http://www.cs.berkeley.edu/~iang/ecash/), it would be not too much work for a sufficiently motivated person to do, with or without the source. In fact, it's unclear the source to the low-level library is really all that helpful in this respect. o He doesn't really want there to be an independent implementation of the ecash library, with full source available, also for the above reasons. The phrase "The worst thing you could do would be to go to Canada, write the library, and publish it on the net." came up. In both this and the above case, he didn't believe that availability of source code for security analysis (everyone runs code they didn't write) was an important issue. As far as I could tell, he was thinking like a Cryptographer (not surprising, as that's what he is (and a damn fine one, at that)): he wanted to have a way to verify that the _protocols_ were behaving correctly; that is, they were not leaking private information, and that money wasn't being lost. The issue of buffer overruns causing the security of my entire machine to be compromised wasn't important. o Similarly, the source to the mint will not be published. Notwithstanding that the last few bugs I found in ecash were with the mint software, of which I've never seen source nor object code, again, thinking like a Cryptographer, he insisted that the system was designed so that no matter how one person cheats, the others can't be affected. That may be true in theory, but in practice, if there's a fingerd-style hole in the mint software, and someone manages to steal the mint's private key, and makes counterfeit ecash, does that really not affect me, a customer? If I'm going to be buying into this system, I would like to have some assurance of its security, and it is well-known that the best way to do that is to have open source. So: a question to legal-types, maybe: I am, in fact, going to Canada, and was considering writing a version of the library while I was there. Now, Chaum has a patent on 2 lines of code (blinding the coin before it goes to the bank, and unblinding the value returns). Believe it or not, I would like to stay within the law. Would my writing a library that worked perfectly well with the current system, but just didn't do blinding (and thus has no anonymity) be "contributory infringement" or something like that (noting that it would likely be trivial for someone to add in the relevant 2 lines)? Would it matter (either including the 2 lines or not) if I'd: (a) sell it (b) give it away on the net (c) give it just to a few people (d) only use it myself? Remember also that this would be done in Canada, just to make the question tougher... - Ian "I didn't rant nearly so much as I thought I would..." -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMZ5Ay0ZRiTErSPb1AQFujwQAiQy1nr7pkbk4jQ2wOJREkNFLpEJ33aO3 GoTo0LOa1ej+j/t7AkoGXmc+Udd+HD4VSkEvJE0dwMHkvbb+1DReFhpZ+F7xwf5d 8t9XLKMlL7HbQAxD1Vc2LjgooQxeOoQHyG64ovhPcEwU4v5jF0PWnYex++SKO2Bn ytYOChOmJ9Q= =mN0s -----END PGP SIGNATURE-----