397 lines
19 KiB
Plaintext
397 lines
19 KiB
Plaintext
----------------------- 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
|