diff options
| -rw-r--r-- | doc/paper/taler_FC2016.txt | 261 |
1 files changed, 261 insertions, 0 deletions
diff --git a/doc/paper/taler_FC2016.txt b/doc/paper/taler_FC2016.txt new file mode 100644 index 000000000..799957f32 --- /dev/null +++ b/doc/paper/taler_FC2016.txt @@ -0,0 +1,261 @@ + +-------- Forwarded Message -------- +Subject: FC 2016 reviews for paper 10 +Date: Wed, 2 Dec 2015 11:19:05 +0100 +From: FC 2016 <fc2016@easychair.org> +To: Christian Grothoff <grothoff@net.in.tum.de> + +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 <customer, amount> +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 + + + |