exchange

taler_FC2016.txt (19759B)

---

 ----------------------- REVIEW 1 ---------------------
 TITLE: Taler: Taxable Anonymous Libre Electronic Reserves
 
 ----------- 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).
 
 > Withdrawing change matching the next transaction is both highly
 > inconvenient for the user and more importantly likely to assist
 > in deanonymizing the user as it makes it easy to link the withdrawal
 > to the deposit by the amount and the proximity in time.  With
 > Taler, withdrawals can be always the same amount (i.e. 20 USD)
 > regardless of the specific transaction amounts (i.e. 3.1415 USD).
 
 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.
 
 > Yes, this is also true. In fact, in practice it might even be the
 > reverse: the merchant is offline but the user is online (this is
 > a deployment scenario common in India).  But, as either party can
 > obviously proxy the traffic for the other, this is not relevant to
 > the paper as the paper is not about network architecture.
 
 Now this
 arguably still requires linkability between the whole coin and the two
 split coins however…
 
 > Not sure we understand, the goal of the refresh protocol is to
 > provide unlinkable change.
 
 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.
 
 > That is correct, and we never claimed that it does.  In fact,
 > we described the loophole in the paper, and have tried to
 > further clarify the description in the revision.  Also, in theory
 > the refresh procedure could be used during withdrawals once a
 > customer has established a "meta-coin" first that is used for
 > all withdrawals, but the risks from such a meta-coin compromise
 > vs. the (acceptable) withdrawal loophole make this option
 > unattractive in the real world.
 
 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).
 
 > Afterwards protocols are often obvious.  The community has
 > for years failed to address the challenge of efficiently
 > providing unlinkability for change and protocol aborts.  The
 > fact that the solution is comprehensible is an advantage.
 
 
 Other comments:
 
 [1] I didn’t understand why ZeroCoin is particularly suited for
 developing nations?
 
 > Us neither, we did not claim this.
 
 [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.
 
 > Yes. If Alice works, she is selling her labor and thus a merchant,
 > while her employer is the customer.
 
 [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.
 
 > We tracked down Ian Goldberg (author of HINDE, which was never
 > published), asked him about the system, compared it in the paper,
 > and were told the year afterwards by reviewers from the same
 > conference (see FC 2017 reviews) that putting a HINDE reference was
 > inappropriate. We have left the discussion for now.
 
 [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.
 
 > We have stressed the fact that the system produces evidence.
 
 [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.
 
 > Economists have a pretty good idea as to the causes of volatility.
 > The relatively small size of the Bitcoin "economy" is such an
 > indisputable reason.
 
 [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).
 
 > We have adjusted that language, as some like Dogecoin have removed
 > the 21 billion BTC cap to reduce the ponzi-like tendencies.  
 > There remains a large trend towards ponzi schemes in the altcoin
 > world however, amusingly noted by https://ponzico.win/ and 
 > https://www.reddit.com/r/Bitcoin/comments/1zzzq0/ponzicoin_operator_steals_money_investors_get/
 
 [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?)
 
 > The patents have 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)
 
 > There are different versions of the DigiCash protocol, some suitable
 > for offline detection of double-spending.  But any such scheme
 > creates the deanonymization risk we mention in the paper.
 
 [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.
 
 > We have expanded our discussion here.  None of the other systems
 > achieves expected O(log n) performance (the best are still O(n)).
 
 [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)
 
 > Correct.
 
 [3.1] Why does the customer need an anonymous channel when interacting
 with the mint?
 
 > An anonymous channel is needed only when fetching /keys and during
 > refresh, for unlinkability vs. the transaction with the merchant.
 > However, for location privacy it is generally still advisable to
 > always use an anonymous channel, as the exchange should
 > not learn more information than necessary.
 
 [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).
 
 > Right now, we discuss coping coins only in the context of its 
 > inevitability  and its relationship to taxability. In future, we do
 > envision wallets supporting the transfer of coins between friends
 > and family, with the refresh protocol used to recover from problems.
 >
 > There are interesting things one could do with threshold signing
 > and even group signatures of course, but these seems like niche use
 > cases that do not warrant the protocol complexity.  We have not
 > evaluated if a simple change like using a BLS signature scheme
 > might support such use cases at the exchange level, but doing so
 > might make the refresh protocol subject to the ever improving attacks
 > on pairings, so again the complexity seems unwarranted for now.
 
 [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.
 
 > We are aware of this requirement and its importance (and that we
 > satisfy it). But, as it is not a contribution, we did not stress it
 > in the paper.
 
 [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).
 
 > We have added a section about the payback protocol. Note that when
 > the exchange is asked for payback of a coin, it CAN check whether that
 > coin has been spent already (after all, that's the table it has for
 > double-spending detection).  Only the party that has stolen the private
 > key could now mint "fake" coins and claim those. This is prevented
 > by payback asking for the blinding factors and only refunding to
 > the original reserves, thereby limiting the damage.
 
 [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.
 
 > Exchanging a whole coin for two new coins would allow a conspiracy
 > between customer and merchant to launder money. The refresh protocol
 > prevents this.
 
 [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.
 
 > We don't use blind sigs in the DL setting. We use RSA blind signatures
 > and Ed25519 for all _other_ signatures.  Taler has about 30 places
 > in the protocol where different parties sign different types of
 > messages.  Only the validity of coins is attested with RSA signatures,
 > the rest uses Ed25519.  ECDH(E) is used for the refresh protocol.
 
 [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?
 
 > For the refund case, Bob needs to interact again with the exchange,
 > and Alice has to worry about Bob not providing the refund.   Thus it
 > is more efficient and for Alice more secure to directly only pay $75.
 
 
 ----------------------- REVIEW 2 ---------------------
 TITLE: Taler: Taxable Anonymous Libre Electronic Reserves
 ----------- 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.
 
 > We have now been very specific about our instantiations, forsaking
 > the previous generality of the description.
 
 Following from this, there is no evidence any
 part of it has been implemented and evaluated for any system aspect --
 performance, latency.
 
 > The implementation has existed for a while, we have since added
 > a performance evaluation.  However, CPU for the cryptographic
 > primitives (EdDSA, RSA) and network latency dominate the performance
 > characteristics, so they are not terribly interesting.
 
 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;
 
 > We're like 10,000,000x more efficient than Z-Cash.
 > But Taler is not a crypto-currency, so this is comparing apples and oranges.
 
 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.
 
 > We considered various blind signature schemes and left the original
 > protocol description ambivalent as to which instantiation is used.
 > Above, you criticized us for leaving it open.  Regardless, the RSA
 > scheme still seems to offer the best security/performance trade-off,
 > and we also value simplicity and extensive peer-review of the
 > cryptographic primitives used for production systems.  So far, none
 > of the schemes compete.  In particular, the elliptic curve blind
 > signatures mostly require extra round trips. 
 
 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.
 
 > Technically 4.1 is not transferring a coin, as it is issuing a coin.
 > Again, the loophole is/was discussed in the paper.
 
 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.
 
 > Any such credential issuing protocol could still be defeated trivially
 > by Alice sharing her credential with Bob.  We also note that the
 > refresh protocol provides exactly this mechanism, with the original
 > coin serving as this credential.  The problem is that there is no
 > credential we could anchor the initial withdrawal to, without
 > risking catastrophic failure in case the credential is compromised.
 
 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.
 
 > Single-use credentials as proposed by Baldimtsi are inherently
 > dangerous as users can accidentally deanonymize themselves
 > (i.e. by paying from a wallet restored from backup).  This is
 > basically the same problem with offline payments that we discuss
 > in the paper.
 
 
 ----------------------- REVIEW 3 ---------------------
 TITLE: Taler: Taxable Anonymous Libre Electronic Reserves
 
 ----------- 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.
 
 > Yes, but Ecash did not provide unlinkable change with taxability / income
 > auditability / whatever you want to call it.
 
 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.
 
 > Bitcoin does not require users to identify themselves to open a bank
 > account before they can receive funds.  The reason that criminals
 > can extort money this way is one of the reasons for the rise of
 > cryptolocker malware.  Ecash and Taler do not suffer from this problem
 > because the state can (via the existing banking system customer
 > identification processes) establish the owner of a bank account.
 > Auditable is too neutral as a term; Bitcoin is auditable: anyone can
 > check that it operates "correctly", but it is not taxable by our
 > definition as the state cannot apply a 100% crime tax to the cryptolocker
 > criminals. With Taler or Ecash, this would be possible.
 
 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