[Hey Hal, what happened to your Chaum's ecash description? Can't find it to link to]. Anonymous wrote:

Ray wrote:

...

Even if she provides enough tokens to completely populate the cut-and-choose protocol, those tokens still have to have splits of valid identification information for somebody in them - and giving them all to Bob so that Bob could complete the protocol with the bank - would imply that Bob is privy to that information.

There are far more efficient offline systems than cut and choose. You need to get past the A's and into the B's and C's in your protocol list. Check more recent work from Brands and Chaum.

Here's a short description of Chaum's [2] ecash and credentials vs Brands' [1] more general and flexibile private credentials and ecash. So as both anonymous and Ray know cut and choose refers to the method of encoding identity into coin. The basic problem is that Chaum's blind signature doesn't the signer see what he is signing. So cut and choose is just the user encodes identity in a number of candidate coins, and the bank chooses one at random and the user must reveal the rest. This allows tunable probability of cheating (not encoding identity in the chosen coin). This is done in such a way that a coin showing protocol will reveal the identity if the coin is spent twice (due to random values chosen by the merchant resulting in two simultaneous equations with two unknowns -- one of them the identity). Cut and choose is computation and communication inefficient. Brands' private credentials stuff uses a technique he calls secret key certificates to allow the issuer and the user to both see the attributes being signed. The user ends up with a certificate on the attributes and the ability to prove the validity of the certificate during a certificate showing protocol. The user can also choose to selectively disclose attributes during disclosure, for example if there are two attributes he can reveal one (the coin denomination) and not the other (his identity). With Chaum's ecash you have to use the cut and choose protocol which is inefficient, with Brands' protocol the user and the issuer engage in a protocol with 3 moves (Discrete Log based variant) or 2 moves (RSA based variant) which is both computation and communication efficient. With Chaum's ecash you have to encode the coin denomination by having a separate public certification key for each denomination. You don't have to do this with Brands' private credentials, as you can put this in an attribute. Also the number of attributes is arbitrary, so if it makes sense to have more attributes in the general private credential case, you can. (For example sex, age, nationality, passport credential, etc. you can reveal any combination you choose after certification.) You can also show fairly arbitrary boolean expressions involving the attributes and not reveal anything other than the truth of the expression. (Eg. Female US citizen over 60 or Male Canadian citizen under 18, and not reveal sex, citizenship or age). The certificates are linkable (ie the verifier or merchant can tell that you are the same pseudonymous person who last showed the certificate), because there is a public key chosen by the user and the public key is revealed during the show protocol. There is also a refresh protocol where the user can give a used certificate and get a fresh certificate without having to show the attribute vales of the certificate -- the certifier just knows he is certifying the same as last time. The refreshed cert would be unlinkable at show time from the original cert. For ecash purposes you can use private credentials to make both offline and online cash. So private credentials are nice and flexible for building generalised private credentials, and also more flexible and so allow you to do some things more efficiently, and do some things not directly possible with Chaum's credentials. Unfortunately both Brands' and Chaum's ecash and credential schemes are patented. David Wagner et al also had some ideas about an ecash coin [3] composed roughly of a public key based MAC (ie the user can't verify the validity of the coin directly -- only the bank can do that), plus a zero-knowledge proof that the bank hasn't marked the coin. This may be unpatened in that it's not directly a certificate, it's a MAC, plus a zero-knowledge proof so it seems like a fairly different process. I don't think you can do efficient offline ecash with Wagner et al's mechanism -- I'd guess it's more comparable with the functionality offered by Chaum's blind signature. There is a high level white paper describing the applications of Brands' private credentials and comparing to Chaum's credentials: at the bottom Brands Private Credentials White Paper. [1] http://www.zeroknowledge.com/media/default.asp [2] Hal Finney used to have a description of Chaum's protocol on rain.org but he's at www.finney.org/~hal/ now and I can't find the link. (Cc'd to see if he still has it.) Actually I did once see a description of Brands stuff by Hal also... still have that too? [3] Ben Laurie has a paper describing Wagner et al's MAC + ZKP ecash / credential protocol as theory2.pdf. http://anoncvs.aldigital.co.uk/lucre/ Adam Disclaimer: As always my comments are my own.

Anonymous wrote:

You're assuming an offline cash system with embedded identity. It is more likely that initial digital cash implementations will be online.

And...

Offline cash really can't compete. Attempting to trace, identify, catch and punish double spenders will be overwhelmingly more expensive than simply checking directly that the cash hasn't been spent before.

I have to day that I strongly disagree with the above. There are several current offline ecash systems which do not require expensive (or even require at all) systems on checking double spent value. Specifically I am referring to Mondex. While there are several disadvantages to Mondex, and the fact that it is not truly anonymous, it does currently allow secure offline transactions. Regards, Andrew Drapp -- Andrew Drapp <andrew.drapp@hitachi-eu.com> PGP Encrypted Email Preferred (KeyID 65A52F89) ********************************************************************* E-mail Confidentiality Notice and Disclaimer This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-mail messages are not necessarily secure. Hitachi does not accept responsibility for any changes made to this message after it was sent. Please note that Hitachi checks outgoing e-mail messages for the presence of computer viruses. *********************************************************************

On Tue, Nov 28, 2000 at 11:50:43PM -0500, Adam Back wrote:

I was going to read about visa cash -- but more fscking shockwave -- the frontpage is shockwave no less so you get zip information out of them.

I already showed it to Adam, but in case anybody else was wondering: There is not in fact any information on that web site, other than a bombastic animated "under construction" sign and an e-mail address.

James wrote:

Adam Back wrote:

...

Hal says:

...

http://www.finney.org/~hal/chcash1.html and http://www.finney.org/~hal/chcash2.html

Wow look at the dates on those files -- Oct 93, and we still no deployed ecash. You'd think there would be a market there for porn sites alone with merchant repudiation rates, and lack of privacy in other payment systems.

The obvious starting market for good ecash is perverse pornography. Another good starting market is interactive sexual performance over the internet.

Whatever the class of pornography it is that is popular on the internet would indeed be a good starting market. I'd consider this class the "mainstream" pornography on the internet. So I'm not sure if you're referring to this or some more risky harder to find stuff which people may arguably be willing to pay a higher premium for. I'd aim for the mainstream stuff due to volume.

There have been many attempts at ecash, but I am not aware of any products involving useful, spendable, convenient, anonymous ecash targeted at that or similar markets. The only really usable anonymous ecash was that of the Mark Twain bank, which crippled its cash to prevent it from being used by that market.

I presume the crippling you're talking about is the payee traceability with collusion of payer and bank. However I'm not sure I agree that the payee anonymity identification feature killed it for this application. For this particular application there appear to be plenty of sites willing to serve the content sans anonymity -- they're VISA, etc merchants no less. I think the thing that killed MT / digicash for this application was MT at the time was reported to be closing accounts related to pornography -- they apparently didn't want the reputation for providing payment mechanisms for the porn industry or something. Plus of course: - the need to download a client - the small userbase making it an unattractive proposition for users - the need to setup an account (in US funds) -- no accountless operation - accounts were difficult to setup too - the greedy fee structure - differentiating between merchants and users I'd have thought the thing to do was put an ecash client in Mozilla and work on getting it into netscape. Plus download plugins for Internet Explorer. So whoever develops enough clue, capability and interest in making money to do this someday needs to think about making it work with existing credit card sites. Give back a one time credit card number for legacy sites which is cryptographically unlinkable with the ecash spender. In general try to make it interoperate with other payment systems. Try to make it as painless and instant as possible to buy ecash. All of this you'd think would be obvious. Adam