typos and lots of FIXME/TODO

1 files changed, 38 insertions, 5 deletions

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 7fe58d854..51d661314 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -74,13 +74,20 @@
 
 \maketitle
 
+% FIXME: As a general comment, I think we're mixing the crypto stuff and the systems
+%        stuff too much.  It might be more appropriate to have to systems stuff in a separate
+%        section, and the "pure" crypto stuff for the crypto people?
+
+
 \begin{abstract}
 This paper introduces {\em Taler}, a Chaum-style digital payment system that
 enables anonymous payments while ensuring that entities that receive
 payments are auditable.  In Taler, customers can
 never defraud anyone, merchants can only fail to deliver the
 merchandise to the customer, and payment service providers can be
-fully audited.  All parties receive cryptographic evidence for all
+fully audited.
+% FIXME:  above, we're still using auditor
+All parties receive cryptographic evidence for all
 transactions; still, each party only receives the minimum information
 required to execute transactions.  Enforcement of honest behavior is
 timely, and is at least as strict as with legacy credit card payment
@@ -108,6 +115,7 @@ bank transactions such as SWIFT.  These systems enable mass surveillance
 by both governments and private companies.  Aspects of this surveillance
 sometimes benefit society by providing information about tax evasion or
 crimes like extortion. 
+% FIXME: reads too much like political propaganda
 In particular, bribery and corruption are limited to elites who can
 afford to escape the dragnet.
 %
@@ -129,7 +137,11 @@ current payment systems.
 The Taler protocol is influenced by ideas from
 Chaum~\cite{chaum1983blind} and also follows Chaum's basic
 architecture of customer, merchant and exchange
-(Figure~\ref{fig:cmm}).  The two designs share the key first step
+(Figure~\ref{fig:cmm}).
+% FIXME: Our design is an improvement on top of Chaums stuff,
+%        this reads like it's completely new, which makes it sound
+%        too much like marketing for an academic paper
+The two designs share the key first step
 where the {\em customer} withdraws digital {\em coins} from the {\em
   exchange} with unlinkability provided via blind signatures.  The
 coins can then be spent at a {\em merchant} who {\em deposits} them at
@@ -168,6 +180,8 @@ withdraw exact change from her account, as doing so reduces anonymity
 due to the obvious correlation.  A practical payment system must thus
 support giving change.
 
+% FIXME:  make the connection to Camenisch's fair exchange paper here,
+%         since refresh solves the same problem in a much more elegant way
 Taler solves the problem of giving change by introducing a new
 {\em refresh protocol}.  Using this protocol, a customer can obtain
 change or refunds in the form of fresh coins that other parties cannot
@@ -182,6 +196,8 @@ the same entity which owned the original coin.
 
 %\subsection{Blockchain-based currencies}
 
+% FIXME:  SHORTEN.  This is probably too much information for the audience, they
+%         all know this
 In recent years, a class of decentralized electronic payment systems,
 based on collectively recorded and verified append-only public
 ledgers, have gained immense popularity.  The most well-known protocol
@@ -297,15 +313,19 @@ In pure blind signature based schemes like Taler, withdrawal and spend
 operations require bandwidth logarithmic in the value being withdrawn
 or spent.  In \cite{Camenisch05compacte-cash}, there is a zero-knoledge
 scheme that improves upon this, requiring only constant bandwidth for
-withdrawals and spend operations, but sadly the exchanges' storage and
-search costs become lienar in the total value of all transactions. 
-In princile, one could correct this by adding multiple denominations, 
+withdrawals and spend operations, but unfortunately the exchanges' storage and
+search costs become linear in the total value of all transactions. 
+In principle, one could correct this by adding multiple denominations, 
 an open problem stated already in \cite{Camenisch05compacte-cash}.
 As described, the scheme employs offline double spending protection,
 which inherently makes it fragile and create an wholey unneccasry 
 deanonymization risk.  We believe the offline protection from double
 spending could be removed, thus switching the scheme to only protection
 against online doulbe spending, like Taler. 
+% FIXME: this doesn't belong in an introduction
+% FIXME: also mention the practical divisible ecash stuff
+% FIXME: mention storage costs and computation cost for exchange (still 2^n for 2^n coins)
+%        and customer (has to do ZKPs)
 Along with fixing these two issues, an interesting applied research project
 would be to add partial spending and a form of Taler's refresh protocol.
 At present, we feel these relatively new cryptographic techniques incur
@@ -334,6 +354,10 @@ to what degree the implementation is even complete.  Only a partial
 description of the Opencoin protocol is available to date.
 
 
+% FIXME:  If we ever add peppercoin stuff, cite Matt Green paper
+%         and talk about economics when encoding a punishment-coin
+%         as the identity, whith limited ticket lifespan
+
 %\subsection{Peppercoin}
 
 %Peppercoin~\cite{rivest2004peppercoin} is a microdonation protocol.
@@ -371,6 +395,7 @@ assures customers and merchants that the exchange operates correctly.
 \subsection{Security model}
 %\vspace{-0.3cm}
 
+% FIXME:  Is this too obvious for a crypto paper?
 Taler assumes that each participant has full control over their
 system.  We assume the contact information of the exchange is known to
 both customer and merchant from the start, including that the customer
@@ -403,6 +428,9 @@ impossible even with a quantum computers.  For a refreshed coin,
 unlinkabiltiy requires the hardness of the discrete logarithm for
 Curve25519.
 
+% FIXME:  should we cite the policy paper about cryptocurrencies
+%         from the 90s near here?
+
 The cut-and-choose protocol prevents merchants and customers from
 conspiring to conceal a merchants income.  We assume that the maximum
 tax rate is below $1/\kappa$, and that expected transaction losses of
@@ -413,6 +441,7 @@ a factor of $\kappa$ for tax evasion are thus unacceptable.
 
 Taler ensures that the state can tax {\em transactions}.  We must,
 howerver, clarify what constitutes a transaction that can be taxed.
+% FIXME: Ethical??
 For ethical and practical reasons, we assume that coins can freely be
 copied between machines, and that coin deletion cannot be verified.
 Avoiding these assumptions would require extreme measures, like custom
@@ -931,6 +960,10 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
      the location of the failure.
 \end{description}
 
+% FIXME: Maybe explain why we don't need n-m refreshing?
+% FIXME: What are the privacy implication of not having n-m refresh?
+%        What about the resulting number of large coins, doesn't this reduce the anonymity set?
+
 %\subsection{N-to-M Refreshing}
 %
 %TODO: Explain, especially subtleties regarding session key / the spoofing attack that requires signature.