wip

1 files changed, 29 insertions, 20 deletions

diff --git a/introduction.tex b/introduction.tex
index 75b6623..aa527bf 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -32,7 +32,7 @@ This thesis covers both categories of payment systems:
    nicely with the modern Web.  Our value-based payment protocol can in
    principle operate on top of any existing register-based system.
   \item For register-based payment systems, we present a new Byzantine consensus
-   protocol.  Consensus is a key component for virtually all robust, distributed
+   protocol.  Consensus is a key component for virtually all robust, distributed,
    register-based systems that is needed to maintain the
    transaction ledger.  Our Byzantine set union consensus (BSC) protocol
    can be used to achieve consensus in a decentralized and robust manner
@@ -40,13 +40,12 @@ This thesis covers both categories of payment systems:
    protocol asymptotically speeds up the implementation of such
    transaction ledgers, compared to classic Byzantine consensus
    protocols.
-  % FIXME: mention other BSC applications!
 \end{itemize}
 
 GNU Taler is an official package of the GNU
 project\footnote{\url{https://gnu.org/}}, and the BSC protocol was
-implemented in the CONSENSUS subsystem of the GNUnet
-framework.\footnote{\url{https://gnunet.org}} Our Free Software
+implemented in the \textsc{CONSENSUS} subsystem of the GNUnet
+framework\footnote{\url{https://gnunet.org}}. Our Free Software
 implementations are freely available from the GNU mirrors.
 
 
@@ -79,9 +78,10 @@ In the world of online payments, credit cards and a sprawling number
 of smaller, proprietary payment processors are currently dominant, and
 market shares vary widely between different
 countries~\cite{adyen2016global,paypers2016ecommerce}.  The resulting
-fragmentation again increases social costs: Online shops can either
+fragmentation again increases social costs: online shops can either
 choose to invest in implementing many proprietary protocols, or only
-implement the most popular ones, thereby reinforcing their oligopolies.
+implement the most popular ones, thereby reinforcing the dominance of
+a handful of dominant proprietary payment systems.
 
 Considering these and other social implications of payment systems, we
 started the development of GNU Taler with a set of high-level design
@@ -119,7 +119,7 @@ supports the more highly ranked goal is preferred:
 
     Privacy should be guaranteed via technical measures, as opposed to mere
     policies.  Especially with micropayments for online content, a
-    disproportionate of rather private data about buyers would be revealed, if
+    disproportionate amount of rather private data about buyers would be revealed, if
     the payment system does not have privacy protections.
 
 %Especially if a payment system is to be used for microtransactions for online
@@ -168,12 +168,14 @@ supports the more highly ranked goal is preferred:
     applies to the integration with merchants, and informs choices about the
     architecture, such as encapsulating procedures that require cryptographic
     operations into an isolated component with a simple API.
+
   \item \textbf{GNU Taler must be efficient.}
 
     % FIXME: provide broader ethical justification (environmental impact,
     % social cost, opportunity cost of lack of micropayments)
-    This rules out the use of approaches such as proof-of-work.  Efficiency is
+    Approaches such as proof-of-work are ruled out by this requirement.  Efficiency is
     necessary for GNU Taler to be used for micropayments.
+
   \item \textbf{GNU Taler must avoid single points of failure.}
 
     While the design we present later is rather centralized, avoiding single
@@ -196,8 +198,8 @@ supports the more highly ranked goal is preferred:
 \section{Features of Value-based Payment Systems}\label{sec:intro:features}
 
 There are many different possible features that have been proposed for
-value-based (or token-based) payment systems in the past.  While we
-will discuss literature in e-cash in more detail in
+value-based (sometimes called token-based) payment systems in the past.  While we
+will discuss existing work on e-cash in more detail in
 Section~\ref{sec:related-work:e-cash}, we will begin by a brief
 summary of the possible features that value-based payment systems
 could provide, and clarify which high-level features we chose to adopt
@@ -227,11 +229,11 @@ This approach is problematic in practice, as customers that restore a wallet
 from backup might accidentally double-spend and would then face punishment for
 it.  Enforcing punishment for double-spenders can be rather difficult as well,
 since the double-spender might have signed up with a false identity or might
-already be in another country, and a large number of merchants might already
+already have fled to another country, and a large number of merchants might already
 have been defrauded with the same coins.
 
 Should the issuer of e-cash be compromised, an attacker could issue coins that
-fail to identify a culprit (or even blame somebody else) when they are
+fail to identify a culprit or even blame somebody else when they are
 double-spent.  In an offline e-cash system, the detection of such an event is
 greatly delayed compared to systems with online spending, which can immediately
 detect when more coins are spent than were issued.
@@ -241,16 +243,16 @@ deposited online during a purchase.  Only either merchant or customer
 need to be online, since one of the two can forward messages to the
 payment service provider for the other.
 
-\subsection{Change and divisibility}
+\subsection{Change and Divisibility}
 
 Customers  do not always have the right set of coins available to exactly cover
 the amount to be paid to a merchant.  With physical cash, the store would
 give the customer change.  For e-cash, the situation is more complex, as
 the customer would have to make sure that the change has not already been
 spent, does not violate their anonymity and the merchant does not have a
-digital ``copy'' of it that the merchant can spend before the customer.  Note
+digital ``copy'' of the change tokens that the merchant can spend before the customer.  Note
 that it would be unwise to always withdraw the correct amount of e-cash
-directly before a purchase, as it creates a correlation between the
+directly before a purchase, as it creates a temporal correlation between the
 non-anonymous withdraw event and the spending event.
 
 Most modern e-cash schemes instead deal with exact spending  by providing
@@ -275,11 +277,18 @@ individual coin pieces must be checked for double spending and recorded,
 possibliy in compressed form to trade storage costs for more computation.
 
 For GNU Taler, we use a rather simple and practical approach, made possible by
-that participants are online during spending:  Coins can be fractionally spent
-without having divisible, unlinkable parts. The remaining value on a coin that
-was spend (and thus revealed) can be used to withdraw fresh, unlinkable coins.
-The protocol to obtain change takes additional measures to ensure that it
-cannot be misused to facilitate untaxed transactions.
+requiring participants to be online during spending:  coins can be fractionally
+spent without having divisible, unlinkable parts. The remaining value on a coin
+that was spend (and thus revealed) can be used to withdraw fresh, unlinkable
+coins.  The protocol to obtain change takes additional measures to ensure that
+it cannot be misused to facilitate untaxed transactions.  Giving change for
+e-cash has been proposed before \cite{brickell1995trustee,tracz2001fair}, but
+to the best of our knowledge, the idea of income-transparent change is novel.
+
+While the exchange need to be available for payments to be processed, payments
+can still be made when either the customer or the merchant is offline, as one
+of them can route their communication with the exchange through the other
+party.
 
 \subsection{Anonymity Control}