[GNUnet-SVN] [taler-exchange] branch master updated: review formatting

[gnunet]

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 0f7a0bb  review formatting
0f7a0bb is described below

commit 0f7a0bbed54e197444792bb5cb1885fc6c8bdd8b
Author: Florian Dold <address@hidden>
AuthorDate: Wed May 17 15:25:25 2017 +0200

    review formatting
---
 doc/paper/taler_FC2017.txt | 80 ++++++++++++++++++++++++++++++----------------
 1 file changed, 52 insertions(+), 28 deletions(-)

diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt
index 95fd946..d6071ac 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  [...]
-
-- 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 ---------------------

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