diff options
| -rw-r--r-- | .gitignore | 2 | ||||
| -rw-r--r-- | doc/paper/taler.tex | 22 | ||||
| -rw-r--r-- | doc/paper/taler_FC2016.txt | 261 |
3 files changed, 276 insertions, 9 deletions
diff --git a/.gitignore b/.gitignore index 9dac85a62..3c79e09fa 100644 --- a/.gitignore +++ b/.gitignore @@ -55,3 +55,5 @@ src/util/taler-arm doc/paper/llncs.cls doc/paper/taler.bbl doc/paper/taler.blg +doc/paper/postquantum.bbl +doc/paper/postquantum.blg diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 649e12de6..4f3e16f0a 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -103,6 +103,9 @@ state to shape the society. As bribery is virtually impossible to detect, corruption is widespread and not limited to social elites. ZeroCoin~\cite{miers2013zerocoin} is an example for translating such an economy into the digital realm. +% FIXME: Unclear referee comment : +% I didn’t understand why ZeroCoin is particularly suited for +% developing nations? This paper describes Taler, a simple and practical payment system for a modern social-liberal society, which is not being served well by @@ -155,8 +158,8 @@ believe needs a payment system with the following properties: %, even when taking aborted transactions into account. \item[Taxability] In many current legal systems, it is the responsibility of the merchant - to deduct (sales) taxes from purchases made by customers, or to - pay (income) taxes for payments received for work. + to deduct (sales) taxes from purchases made by customers, or for workers + to pay (income) taxes for payments received for work. %Taxation is necessary for the state to %provide legitimate social functions, such as education. Thus, a payment %system must facilitate sales, income and transaction taxes. @@ -268,8 +271,8 @@ Yet, there are several major irredeemable problems inherent in their designs: of securing the block chain consume a considerable amount of computational resources and energy. So Bitcoin does not an environmentally responsible design. - \item Bitcoin transactions are not easily taxable, leading to legal hurdles. - % The legality and legitimacy of this aspect is questionable. + \item Bitcoin transactions have pseduononymous recipients, making taxation + problematic, and leading to legal hurdles. The Zerocoin extension would only make this worse. \item Bitcoins can not easily be bound to any fiat currency, leading to significant fluctuations in value. These fluctuations may be desirable in @@ -394,11 +397,12 @@ assures customers and merchants that the exchange operates correctly. Taler's security model assumes that cryptographic primitives are secure and that each participant is under full control of his system. The contact information of the exchange is known to both customer and -merchant from the start. Furthermore, the merchant communication's -authenticity is assured to the customer, such as by using X.509 -certificates~\cite{rfc5280}, and we assume that an anonymous, reliable -bi-directional communication channel can be established by the -customer to both the exchange and the merchant, such as by using Tor. +merchant from the start. +We further assume that the customer can authenticate the merchant, +such as by using X.509 certificates~\cite{rfc5280}. % or Tor hidden services. +Finally, we assume that customer has an anonymous, reliable bi-directional +communication channel to both the exchange and the merchant, such as Tor. +% even without hidden services. The exchange is trusted to hold funds of its customers and to forward them when receiving the respective deposit instructions from the merchants. 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 + + + |