-------- Forwarded Message -------- Subject: FC 2016 reviews for paper 10 Date: Wed, 2 Dec 2015 11:19:05 +0100 From: FC 2016 To: Christian Grothoff Dear Christian Grothoff, Please find below the reviews for your paper 10 Taler: Taxable Anonymous Libre Electronic Reserves that was not accepted to Financial Crypto 2016. We hope that these comments are useful for your research and that you can join us in Barbados in February. Best regards, Bart & Jens Program co-chairs FC 2016 ----------------------- REVIEW 1 --------------------- PAPER: 10 TITLE: Taler: Taxable Anonymous Libre Electronic Reserves AUTHORS: Florian Dold, Christian Grothoff, Benedikt Müller and Sree Harsha Totakura ----------- REVIEW ----------- Positives: This paper is interesting, well-written, and accessible. Drawbacks: The core technical contribution of the paper is a coin refresh protocol that (i) is necessitated for making change and (ii) goes to great lengths to avoid customers abusing it as a transaction oracle. The problem is that I think the paper fails on both (i) and (ii), but mostly on (ii). A simple way to do (i) is requiring the user to go to the mint first to make change (as per DigiCash). You might argue that with Taler, the user can be offline even if the merchant is online: I might buy this, but this argument isn’t made in the paper. Now this arguably still requires linkability between the whole coin and the two split coins however… Regarding (ii): while Taler does prevent coin refreshes from being abused, it does not seem to me to prevent the original withdrawal procedure from such abuse. If Alice wants to pay Bob in a tax-free way, she can take a blinded coin from Bob and withdraw it from the mint herself. The mint thinks it is Alice’s coin but only Bob knows the key in it, and so only Bob can spend it. Alice gives the coin to Bob to complete the payment. This does not allow a chain of transactions, as Bob has to do something with the coin, but generally digital cash services let you return an unspent coin at any time and credit your account, which Bob could do. But even if he can’t, at least one payment can be laundered in this way. Finally, I think the contribution here is somewhat narrow. Linkable refreshing is done with a cut-and-choose and is not particularly challenging once you know what you want to do (I suppose the contribution is partly in developing the requirement, based on real world requirements). Other comments: [1] I didn’t understand why ZeroCoin is particularly suited for developing nations? [1] Taxability: with reference to income tax, if Alice works at Acme Inc and is paid her salary, in this case Acme Inc is the “customer” and Alice is the “merchant”? Is that the idea? Otherwise it seems, the taxability property should apply equally to customers and merchants. [1] The change protocol sounds like it solving the same problem as HINDE. While HINDE isn’t well documented, the authors should attempt to contrast their approach with it. In HINDE, the customer creates coins to withdraw (so only they can spend them) but the merchant pays for the withdraw. These can be used as change. It is compatible with DigiCash. [2.1] “easily taxable” -> this concept paints a picture of the tax agency proactively looking at transactions. A better way of describing it might be that it leaves an audit trail for tax agencies. [2.1] There is no casual relationship that can be proven between Bitcoin’s independence as a currency and its volatility. All you can really say is that today, Bitcoin is more volatile than certain currencies (and less so than others) but we have no idea why and if that might change in the future. [2.1] I don’t see AltCoins as a “problem.” You are correct that Bitcoin is less a currency and more an open protocol for creating new currencies. So what? And why do altcoins become a ponzi scheme? (Noting that you do not say that they might become one, rather that they do). [2.2] How does Taler avoid Chaum’s patent on his blind signature scheme? It seems to be built on it. (Could you use Lucre instead?) (Or is it that Chaum’s patent has expired?) [2.2] I thought DigiCash used the Chaum-Fiat-Naor (or variant) scheme for offline detection of double-spending? Even if it didn’t, you should mention the possibility of using this kind of detection mechanism (and variations from Ferguson, etc) [2.2] Divisible e-cash is a subject with many publications beyond Brands’ work. The authors should include a broader survey of this as it seems pertinent. They should also consider anonymized change protocols, as mentioned above, such as HINDE. [3.1] To be clear, the anonymous channel only hides the customer’s identity, not that of the merchant or mint? (Which is obviously what Tor provides in its base form, without hidden services) [3.1] Why does the customer need an anonymous channel when interacting with the mint? [3.2] The discussion of copying private keys is informative but I’m not sure it is sufficient. If the signature scheme is one that admits threshold signing (or even just distributed key generation), it might be possible that entities own shares of a single private key in a way that is indistinguishable from the situation where there is only one private key. In this case, they do not have to worry about the other party absolving with the funds (but they do have to worry about the other party cooperating when one party wants to use the funds). [3.3] I think you understate the benefits of the mint knowing the identity of the customer: many countries have Know Your Customer (KYC) laws for organizations like your mint—as many Bitcoin business are now finding out about :) I would explicitly add KYC to your list of requirements. [3.4] In case of a loss mint private key, you say customers can exchange their unspent coins. I think you either mean (i) their potentially unspent coins (because the mint only has a list of and doesn’t know what was spent) or (ii) the bank keeps a record of the blinded coins it has signed and the customer must spend their coin (to prove it is unspent) and provide the blinding factor (to prove it was issued and not made up with the leaked key). In either case, this needs much more explanation (or a forward pointer if it is explained later). [3.5] Is there any real difference between spending a fraction of a coin a refreshing it, or going to the mint and exchanging a whole coin for two new coins (one worth the value of the transaction and the other worth the difference)? This is effectively how Digicash works. To link the old (whole) coin to the new issuance, the customer could be required to provide the blinding factors. [4.1] IIRC Chaumian blind signatures are based on RSA. You are using discrete logarithms (presumedly if you are using elliptic curves). Blind sigs in the DL setting exist of course, but you should specify and cite an appropriate one. [4.6] If Alice pays $75 to Bob using a $100 coin, is there any technical difference between (a) Bob limiting the coin to $75 and Alice refreshing the coin and (b) Bob taking the $100 but issuing a $25 refund to Alice, who then refreshes the refund? ----------------------- REVIEW 2 --------------------- PAPER: 10 TITLE: Taler: Taxable Anonymous Libre Electronic Reserves AUTHORS: Florian Dold, Christian Grothoff, Benedikt Müller and Sree Harsha Totakura ----------- REVIEW ----------- This paper presents a number of important design ideas: it adapts chaums' e-cash ideas to the modern settings, and augments it with modern notions of anonymity for the spenders, traceability and accountability for the merchant, the ability to levy tax, and features to prevent fraud. A key assumption used, that makes it different from traditional e-cash, is that on-line checks are expected, making traceability and identity escrow unnecessary to prevent double spending. The paper does present some good ideas: it is pragmatic about balancing abuse prevention with privacy, and also recognizes that modern monetary systems have to support taxation and known merchants. It also uses the rule of law to enforce parts of contracts (such as delivery of goods) rather that complicating the protocols with such things -- which other designs attempt and fail to address in a satisfactory manner. At the same time, the paper also has some serious issues, that prevent me from wholeheartedly supporting its acceptance: first, it reads a little like a white paper. The details of the crypto are a bit thin, and it is not clear how to instantiate specifically the blind signatures and other primitives proposed. Following from this, there is no evidence any part of it has been implemented and evaluated for any system aspect -- performance, latency. This is a missed opportunity, as such an implementation -- and its evaluation -- would provide a good reference point to compare with the more expensive crypto-currency designs; finally, the paper makes reference to blind signatures from Chaum, but of course a number of constructions -- allowing for efficient proofs -- have been proposed since. It is not clear the authors appreciate their importance or even existence. However, providing proofs of the statement to be signed is important, and a potential attack on the presented scheme may illustrate this. The scheme suggests that a any transfers of value should be taxed. However, the issuing protocol in 4.1 can be abused to transfer a coin, without paying tax, and in an unlikable manner. The party withdrawing the coin may chose to use a public key belonging to someone else in step 4 -- thus asking for a coin controlled by another entity to be signed by the issuer. As a result, the coin can be directly used by the other party, without any visible transfer (or use of the spending protocol). This could be avoided by using a modern credential issuing protocol that ensures the party withdrawing a coin, knows the secret associated with the coin -- something that traditional chaum blind signatures can only achieve with a cut-and-chose technique, which is very expensive. So my advice would be to chose a modern credential scheme to instantiate the protocol, such as the anonymous credential light (Baldimtsi et al) protocols, actually implement the protocol, and then provide a thorough security and performance evaluations. ----------------------- REVIEW 3 --------------------- PAPER: 10 TITLE: Taler: Taxable Anonymous Libre Electronic Reserves AUTHORS: Florian Dold, Christian Grothoff, Benedikt Müller and Sree Harsha Totakura ----------- REVIEW ----------- It seems like the only novelty here has to do with the mechanism to unlinkably refresh partially-spent coins. I can imagine that being useful! But I'm not sure it would be useful. Its value should be compared to on-line-verified DigiCash Ecash, to which it is most similar, to Bitcoin (it is clearly better for payer-privacy than Bitcoin) and to Zerocash. I think it is probably better than Zerocash in some performance measures, and in avoiding the need for secure parameter setup (which raises the possibility of a backdoor in Zerocash). There are a lot of comparisons to Chaumian off-line double-spending-detection, but those aren't as relevant as a comparison to Ecash would be. The only difference in functionality between TALER and Ecash as far as I can tell is the ability to spend a part of a coin. It isn't clear to me how important that is. But, this paper is rather weighed down by a lot of other stuff which is not novel and/or of questionable value. DigiCash Ecash as deployed (not as described in the original paper) already did on-line verification. I object to the headlining motivation of "taxable". The scheme is neither necessary nor sufficient for taxation, and should instead be called something like "payer-anonymous, payee-auditable". As far as I understand, there's nothing in TALER that makes it more amenable to tracing/auditing (or as they call it "taxability") than Ecash. Both DigiCash Ecash and TALER seem to be less traceable/auditable than Bitcoin. A few positive comments: Positive: explicitly mentions privacy risks: network (addressed with Tor), mint-selection, merchant-customer metadata Positive: explicitness about when durable writes ("commits") are needed, and about resumption Positive: explicitness about expiration/garbage-collection Positive: explicitness about multiple mints