path: root/doc
diff options
authorFlorian Dold <>2017-05-17 16:14:53 +0200
committerFlorian Dold <>2017-05-17 16:14:53 +0200
commit4432cf362831ad5e181dd494efa58882f0c55303 (patch)
treeeb91779ff1580a459c09ae3736f0d6c6e6216327 /doc
parent0f7a0bbed54e197444792bb5cb1885fc6c8bdd8b (diff)
add r4r reference, review comment and related work remark
Diffstat (limited to 'doc')
3 files changed, 43 insertions, 0 deletions
diff --git a/doc/paper/taler.bib b/doc/paper/taler.bib
index 5d59d31b..1d3fcd98 100644
--- a/doc/paper/taler.bib
+++ b/doc/paper/taler.bib
@@ -258,6 +258,15 @@
publisher={Rand Corporation}
+ 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}
author="Bellare and Namprempre and Pointcheval and Semanko",
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 5e981199..8683d27a 100644
--- a/doc/paper/taler.tex
+++ b/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.
diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt
index d6071ac4..b00eb067 100644
--- a/doc/paper/taler_FC2017.txt
+++ b/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 ---------------------
@@ -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
+> We added a section with proofs