add r4r reference, review comment and related work remark

doc/paper/taler.bib

@@ -258,6 +258,15 @@
   publisher={Rand Corporation}
 }
 
+@inproceedings{rupp2013p4r,
+  title={P4R: Privacy-preserving pre-payments with refunds for transportation systems},
+  author={Rupp, Andy and Hinterw{\"a}lder, Gesine and Baldimtsi, Foteini and Paar, Christof},
+  booktitle={International Conference on Financial Cryptography and Data Security},
+  pages={205--212},
+  year={2013},
+  organization={Springer}
+}
+
 
 @article{OneMoreInversion,
   author="Bellare and Namprempre and Pointcheval and Semanko",

doc/paper/taler.tex

@@ -441,6 +441,18 @@ deanonymization risk (see Section~\ref{sec:offline}).
 %macropayment.  It is therefore unclear how Peppercoin would actually
 %reduce the computational burden on the exchange.
 
+The use of refunds for fractional payments has been suggested in the context of
+payment systems for public transit fees \cite{rupp2013p4r}.  This approach
+relies on 2-showable coins that can be used one time for fractional spending
+and another time for refunding the remaining amount without losing anonymity.
+Unfortunately this approach cannot be used for a general-purpose payment
+system, since the refund operation of Rupp et al. allows transfeing money
+in a way that hides income from taxation.  Refunding a coin into a wallet that
+didn't withdraw the coin is possible in their system, but consitutes a
+transaction between two parties that is not recognized by the system for the
+purpose of income taxation.
+
+
 %\vspace{-0.3cm}
 \section{Design}
 %\vspace{-0.3cm}

doc/paper/taler_FC2017.txt

@@ -105,18 +105,30 @@ Specific comments:
   it just mentions some of the tools used in the proposed scheme (i.e. FDH
   signatures, cut-and-choose and what kind of security they offer).
 
+> We added a section with that goes deeper into properties and proofs
+
 - Related work missing: there has been previous work in “payments with
   refunds”. Please look at Rupp et al “P4R: Privacy-Preserving Pre-Payments
   with Refunds for Transportation Systems” where instead of refreshing coins, the
   unused amount is accumulated in some token that can later be used. How would
   you compare with that system?
 
+> We added this to the related work, main problem with this work is that it is
+> meant for public transportation systems.  For general payments,
+> their refund can be abused to create transactions that are not
+> taxable.
+
 - Found the discussion on Bitcoin too long and unnecessary - the proposed
   system is not decentralized anyway
 
+> FIXME: maybe remove some of the bitcoin stuff?
+
 - Referencing a system (Goldberg’s HINDE) that is not published makes
   impossible for the reviewer to check any arguments. 
 
+> In an earlier submission, a reviever insisted that this reference
+> be added.
+
 - Section 4.1, step 1: is W_p = w_s * G? Also where is blinding factor b
   selected from? What does it mean to “commit to disk”? The customer commits
   and keeps the commitment local? Where is this used?
@@ -140,6 +152,8 @@ Specific comments:
 - Section 4.3, doesn’t seem very fair to compare with Zcash or at least it
   should be highlighted that a quite weaker level of anonymity is achieved.
 
+> We added a remark on the high level of anonymity that Zerocash achieves
+
 - Section 4.3, step 1, where is the key t_s^(i) selected from? What does S_{C’}
   denotes? Is that a commitment (as noted in the text) or a signature (as noted
   in notation table?). 
@@ -149,6 +163,12 @@ Specific comments:
   this happening. How does this part of the protocol ensure that a user cannot
   just refresh a coin for one of a much bigger value than the remaining one?
 
+> The exchange records spent coins (with the amount spent) in it's database.
+> When refreshing a coin, the customer must reveal the coin's (unblinded)
+> public key to the exchange, which will then set the remaining value
+> of the coin to zero in it's database.  The new coin is now allowed
+> to exceed the old coin in value.
+
 
 ----------------------- REVIEW 3 ---------------------
 PAPER: 46
@@ -171,3 +191,5 @@ actually is acheived. Furthermore, no proofs of security are given,
 and even the protocol is hard to fully understand. As such, I would
 suggest the authors to first formalize their approach and
 resubmitting.
+
+> We added a section with proofs