adding reviews

1 files changed, 111 insertions, 0 deletions

diff --git a/taler-fc19/reviewsfc19.txt b/taler-fc19/reviewsfc19.txt
new file mode 100644
index 0000000..be142c7
--- /dev/null
+++ b/taler-fc19/reviewsfc19.txt
@@ -0,0 +1,111 @@
+
+Subject:
+[FC19] Paper #166 "Robust and Income-transparent Online..."
+From:
+<hotcrp@submit19.ifca.ai>
+Date:
+11/14/18, 2:45 PM
+To:
+Christian Grothoff <christian.grothoff@bfh.ch>
+
+Dear Christian Grothoff,
+
+We are sorry to notify you that your paper #166, Robust and
+Income-transparent Online E-Cash, has not been accepted to the Financial
+Cryptography and Data Security 2019 conference.  The reviews for your paper
+are appended below.
+
+We received a record number of submissions this year (178), of which we
+accepted 33 regular papers and 7 short papers.
+
+You may wish to submit your paper to one of the associated workshops. As
+none of the workshops' submission deadlines have yet passed, we are leaving
+it up to the authors to decide whether to resubmit, rather than moving
+rejected papers automatically.
+
+Thanks for submitting to the conference, and we hope you will nonetheless
+attend the event.
+
+   - Ian and Tyler
+
+Review #166A
+===========================================================================
+
+Overall merit
+-------------
+3. Weak accept
+
+Reviewer expertise
+------------------
+3. Knowledgeable
+
+Paper summary
+-------------
+This paper describes an "online" e-cash protocol that provides the following properties:
+- a "recoverability" property that allows a user to recover coins from backups if a wallet is lost
+- a "change protocol" that allows partially-spent coins to be renewed for smaller denominations
+- and a probabilistic "auditability" property that allows a user to reveal the source of coins in their wallet
+The paper spends a great deal of time giving game-based definitions for these properties, then gives a "generic" protocol that meets these goals when instantiated with discrete-log based primitives (the security proofs and instantiations are given in the appendix.)  Overall, the paper seems correct, but does not really make a compelling case for the change and auditing properties.
+
+Comments for author
+-------------------
+The paper is written in a way that makes it quite difficult to read: Since it is clear that you have a specific instantiation of most of the primitives in mind, I think just describing the protocol, and giving a UC-style functionality, rather than spending 4 pages on syntax/types, and 3 pages on oracles, and another 2 pages on notation for things that will be instantiated by standard DH/DLog primitives, would make the paper much more approachable for readers and reviewers.
+
+
+* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
+
+
+Review #166B
+===========================================================================
+
+Overall merit
+-------------
+3. Weak accept
+
+Reviewer expertise
+------------------
+2. Some familiarity
+
+Paper summary
+-------------
+The paper presents a new e-cash protocol that involves exchanges, customers and merchants. Briefly, the customer can have a coin minted from the exchange (i.e. blind-signature) and spend it with a merchant. The coins appear to be dividable too (and anything that is "too small" is considered a fee to exchange). The paper mostly focuses on defining the security goals anonymity, conservation, unforgeability, and income transparency. It provides games on how the properties can be achieved, they instantiate the protocol and provide a proof that the instantiation satisfies these goals.
+
+Comments for author
+-------------------
+The paper is well-written and easy to read. It appears to be more of a theoretical paper as it outlines both the security game + the instantiated protocol, but there is no implementation or assessment of its efficiency. i.e. how well does the protocol work and how can it be compared with the related works? 
+
+I feel the paper doesn't really present a good case why income-transparency is a desirable goal. There are some really good ethical questions that could be explored (i.e. should people have financial privacy? is there something desirable? how does it impact the power structures in society?).
+
+
+* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
+
+
+Review #166C
+===========================================================================
+
+Overall merit
+-------------
+2. Weak reject
+
+Reviewer expertise
+------------------
+3. Knowledgeable
+
+Paper summary
+-------------
+The authors propose conservation as a new security property for e-cash schemes. Conservation ensures that aborted withdraws and spends do not deprive the user of money.
+
+Comments for author
+-------------------
+The paper is heavy on syntax, with no intuition, exposition, or relation to existing work. The actual construction is not until page 11!.   The majority of this is not part of the claimed contribution of the paper, but the details required to flesh out a full fledged scheme. You were allowed unlimited appendices. Please use them.
+
+The lack of discussion and comparison to related work makes it particularly challenging to evaluate the work. Conservation seems like a property that would be implied by most ideal functionality/UC defined schemes.  These are rarer than game based schemes, but not non-existent. In light of those, is the property actually novel?  (see e.g. the first result for universal Composable E-cash https://eprint.iacr.org/2005/341.pdf) 
+
+Beyond that, is the property challenging to achieve? Take CHL06 Compact E-cash, which operates in the harder offline setting and uses the signed PRF as wallet/token dispenser where coins are generated as the output of a prf with the key signed by the bank. It seems that this scheme or on substantially similar  achieves conservation.  The user obtains their wallet (the signed PRF seed) only in the last step of an interactive withdraw protocol. Upon completting that set. the bank where debits the account. The user can always ask the exchange to repeated this step (on the same prf seed).
+
+
+Similarly, for that tax protocol. How does this compare to e.g. GNU Taller?
+ 
+Do the authors believe there is anything novel about the e-cash scheme they propose or is the novelty in defining the property appropriately? It seems the answer is just the property.
+
+