review formatting

1 files changed, 52 insertions, 28 deletions

diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt
index 95fd94627..d6071ac43 100644
--- a/doc/paper/taler_FC2017.txt
+++ b/doc/paper/taler_FC2017.txt
@@ -96,34 +96,58 @@ is also very overloaded (there is a 2 page notation table!).
 
 Specific comments:
 
-- I would expect the “Security Model” section (Section 1.3) to actually explain (even in an informal way) the desired properties of the proposed scheme. These should include double-spending detection security, unforgeability, user anonymity and more importantly the new type of security introduced by coin refresh (this should be a property that guarantees that a user cannot re-fresh a coin for value more than the one that the “dirty” coin is carrying) Instead 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).
-
-- 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?
-
--Found the discussion on Bitcoin too long and unnecessary - the proposed system is not decentralized anyway
-
--Referencing a system (Goldberg’s HINDE) that is not published makes impossible for the reviewer to check any arguments. 
-
--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?
-
--Section 4.1, step 3, what is the key K used in FDH? Also is S_w(B) a standard signature?
-
--Section 4.1, step 4, How can the exchange know that this was indeed a new withdrawal request? If a new blinding factor b is used, then a customer can create multiple “freshly” looking requests for the same C_p.  (Also a minor point: 2nd line also reads as “if the same withdrawal request was issued before the exchange will send S_K(B)”
-
--Section 4.2, it seems that a customer can use a coin of value say $10 to multiple transactions of <= $10 in total. I.e. it can first a pay a merchant M1 $2 and then a merchant M2 another $5 dollars. In that case the exchange can link those two payments together. Sure, it might not know who is the owner of the coin (i.e. cannot link with withdrawal) but this is still an anonymity problem.
-
--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.
-
--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?). 
-
--Section 4.3 In this protocol I would expect the customer to somehow “prove” to the exchange what is the remaining value of the dirty coin. I do not see 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?
-
-
-
-Typos
-Sec. 3.1 “cryptographily” -> cryptographically
-Sec 4.2, Step 1 “a exchange” -> an exchange
-Sec 4.3, 3rd line should be -> at the same time
+- I would expect the “Security Model” section (Section 1.3) to actually explain
+  (even in an informal way) the desired properties of the proposed scheme.
+  These should include double-spending detection security, unforgeability, user
+  anonymity and more importantly the new type of security introduced by coin
+  refresh (this should be a property that guarantees that a user cannot re-fresh
+  a coin for value more than the one that the “dirty” coin is carrying) Instead
+  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).
+
+- 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?
+
+- Found the discussion on Bitcoin too long and unnecessary - the proposed
+  system is not decentralized anyway
+
+- Referencing a system (Goldberg’s HINDE) that is not published makes
+  impossible for the reviewer to check any arguments. 
+
+- 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?
+
+- Section 4.1, step 3, what is the key K used in FDH? Also is S_w(B) a standard
+  signature?
+
+- Section 4.1, step 4, How can the exchange know that this was indeed a new
+  withdrawal request? If a new blinding factor b is used, then a customer can
+  create multiple “freshly” looking requests for the same C_p.  (Also a minor
+  point: 2nd line also reads as “if the same withdrawal request was issued before
+  the exchange will send S_K(B)”
+
+- Section 4.2, it seems that a customer can use a coin of value say $10 to
+  multiple transactions of <= $10 in total. I.e. it can first a pay a merchant
+  M1 $2 and then a merchant M2 another $5 dollars. In that case the exchange can
+  link those two payments together. Sure, it might not know who is the owner of
+  the coin (i.e. cannot link with withdrawal) but this is still an anonymity
+  problem.
+
+- 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.
+
+- 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?). 
+
+- Section 4.3 In this protocol I would expect the customer to somehow “prove”
+  to the exchange what is the remaining value of the dirty coin. I do not see
+  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?
 
 
 ----------------------- REVIEW 3 ---------------------