gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] [taler-exchange] branch master updated: add r4r reference,


From: gnunet
Subject: [GNUnet-SVN] [taler-exchange] branch master updated: add r4r reference, review comment and related work remark
Date: Wed, 17 May 2017 16:14:56 +0200

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository exchange.

The following commit(s) were added to refs/heads/master by this push:
     new 4432cf3  add r4r reference, review comment and related work remark
4432cf3 is described below

commit 4432cf362831ad5e181dd494efa58882f0c55303
Author: Florian Dold <address@hidden>
AuthorDate: Wed May 17 16:14:53 2017 +0200

    add r4r reference, review comment and related work remark
---
 doc/paper/taler.bib        |  9 +++++++++
 doc/paper/taler.tex        | 12 ++++++++++++
 doc/paper/taler_FC2017.txt | 22 ++++++++++++++++++++++
 3 files changed, 43 insertions(+)

diff --git a/doc/paper/taler.bib b/doc/paper/taler.bib
index 5d59d31..1d3fcd9 100644
--- a/doc/paper/taler.bib
+++ b/doc/paper/taler.bib
@@ -258,6 +258,15 @@
   publisher={Rand Corporation}
 }
 
address@hidden,
+  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}
+}
+
 
 address@hidden,
   author="Bellare and Namprempre and Pointcheval and Semanko",
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 5e98119..8683d27 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.
+
+
 %\vspace{-0.3cm}
 \section{Design}
 %\vspace{-0.3cm}
diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt
index d6071ac..b00eb06 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 ---------------------
 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

-- 
To stop receiving notification emails like this one, please contact
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]