intro

1 files changed, 99 insertions, 34 deletions

diff --git a/introduction.tex b/introduction.tex
index bd7cc77..829259d 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -8,7 +8,7 @@ Cryptocurrencies based on Blockchains gained immense popularity over the last
 years, and promise a universal, global and decentralized payment system that is
 independent from country boundaries and legislations.  In practice, however,
 current incarnations of these technologies can only handle a handful of
-transactions, and are suprisingly centralized
+transactions, have high transation fees and are suprisingly centralized
 \cite{beikverdi2015trend,bohme2015bitcoin}.  Bitcoin, the most popular
 cryptocurrency, can handle around 3-7 transactions per second, globally.  While
 there are various plans to make blockchains more scalable, there is no concrete
@@ -346,8 +346,22 @@ deanonymize customers involved in double-spending, typically by encoding the
 customer's identity into their coins in a way that makes it only possible to
 decode the identity with two spending transcripts.
 
-% fragility, enforcement problems
+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
+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 someboy 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.
+
+Thus in GNU Taler, all coins are immediately 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.
 
 \subsubsection*{Change and divisibility}
 Customers  do not always have the right set of coins available to exactly cover
@@ -381,55 +395,106 @@ $10.00\$$ with a coin that supports division into cent pieces, $1000$
 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.
 
-\subsubsection*{Traceability and Anonymity Control}
-\subsubsection*{Transferability}
-\subsubsection*{User Suspension}
-Electronic Cash with Anonymous User Suspension
-\subsubsection*{Recoverability}
-(Ecash vs off-line recovery)
+\subsubsection*{Anonymity Control}
+Some proposed e-cash protocols contain mechanisms to allow selective
+deanonymization of transactions for scenarios involving crime
+\cite{sander1999escrow}, specifically blackmailing and tax evasion.
 
-FIXME:  discuss ways to handle extortion / perfect crime / kidnapping
-\subsubsection*{Atomic Swaps}
+Unfortunately this does not really work as a countermeasure against
+blackmailing in practice.  As noted in the paper that initialy described such a
+mechanism for blind signatures \cite{stadler1995fair}, a blackmailer could
+simply request to be paid directly with plain blindly signed coins.
+
+GNU Taler provides \emph{income transparency} as a measure against tax evasion.
+We furthermore describe a different approach in a blackmailing scenario in
+Section \ref{sec:design:blackmailing}, which we believe is more practical in
+dissuading blackmailers in practice.
 
-\paragraph{Refunds}
-\paragraph{Tipping}
-\paragraph{Income Transparency}
+\subsubsection*{User Suspension}
+Anonymous user suspension \cite{au2011electronic} has been proposed as another
+mechanism to punish users suspected in illicit activities by preventing then
+from making transactions until the suspension is lifted.  Anonymous suspension
+is based on transactions; the user involved in an transaction is suspended, but
+their identity is not revealed.
+
+While the approach is interesting, it is not practical, as it requires a single
+permanent key pair to be associated with each user.  If a user claims they lost
+their private key and requests a new key pair, their suspension would be
+effectively lifted.
 
-Our implementation also supports two rather simple extensions to e-cash: (1)
-refunds, which allow the customer to provide a refund on a completed payment
-during a limited time, and (2) customer tipping, which allows the merchant to
-directly pay small amounts into a customer's wallet as a reward for certain
-actions (such as signing up, completing a survey, etc.).
+\subsubsection*{Transferability}
+Transferability is a feature of certain e-cash systems that allows transfer of
+e-cash between two parties without breaking anonymity properties
+\cite{fuchsbauer2009transferable}.
 
-\subsection{Security Properties}
+GNU Taler specifically provides roughly the \emph{opposite} of this property,
+namely \emph{income transparency}, to guarantee that e-cash is not easily
+abused for tax evasion.  Mutually trusting users, however, can share ownership
+of a coin.
 
-We define the following security and correctness properties for GNU Taler (formally defined in Chapter \ref{chapter:security}:
+\subsubsection*{Atomic Swaps}
+Atomic swaps (often called fair exchange in the e-cash literature) are a
+feature of some e-cash systems that allows e-cash
+to be exchanged against some service or (digital) product, with a trusted third
+party ensuring that payee receives the payment if and only if they correctly
+provided the merchandise.
+
+GNU Taler supports Camenisch-style atomic swaps \cite{camenisch2007endorsed},
+as explained in Section \ref{sec:security:atomic-swaps}.
+
+\subsubsection*{Refunds}
+GNU Taler allows merchants to provide refunds to customers during a limited
+time after the coins for the payment were deposited.  The merchant signs a
+statement that effectively allows the customer to reclaim a previously spent
+coin.  Customers can request anonymous change for the reclaimed amount.
+
+While this is a rather simple extension, we are not aware of any other e-cash
+system that allows it.
+
+\subsection{Security Properties}\label{sec:intro:security}
+We have the following security and correctness properties for GNU Taler
+(formally defined in Chapter \ref{chapter:security}:
 \begin{itemize}
-  \item 
+  \item \emph{Anonymity} guarantees that transactions cannot be correlated with withdrawals.
+  \item \emph{Unforgeability} guarantees that users cannot spend more e-cash than they withdrew.
+  \item \emph{Conservation} guaratees that customers do not lose money due to
+    interrupted protocols or malicious merchants; they can always obtain
+    anonymous change or a proof of successful spending.
+  \item \emph{Income transparency} guarantees that mutually distrusting parties
+    are unable to reliably transfer e-cash between them without the income of
+    participants being visible to tax auditors.
 \end{itemize}
 
-(do second list with ours, first list with the common properties)
+While anonymity and unforgeability are common properties of e-cash, we are not
+aware of any other treatments of income transparency and conservation.
 
-\section{Distributed Ledgers and Byzantine Consensus}
+%\section{Distributed Ledgers and Byzantine Consensus}
 
 \section{Contributions}
 
 \begin{itemize}
-  \item we design, implement and analyze an efficient Byzantine consensus
+  \item We design, implement and analyze an efficient Byzantine consensus
     protocol on set structures that allows an optimized implementation of
-    permissioned blockchains
-  \item Notion of income transparency, with an instantiation in Chaum-style
-    e-cash and proofs
-  \item consideration of practical aspects including aborts, network failures,
-    refunds, multi-coin payments, faults from synchronization and their effects
-    on anonymity; showing the necessity of a refresh operation
-  \item seamless/native integration of e-cash into web architecture, discussion
-    of pitfalls / security and privacy problems
-  \item implementation of GNU Taler with performance evaluation
+    distributed transaction ledgers
+  \item We introduce the notion of income transparency for e-cash, with an
+    instantiation in Chaum-style e-cash and proofs
+  \item We design the GNU Taler payment system under consideration of practical
+    aspects of e-cash including aborts, network failures, refunds, multi-coin
+    payments, faults from synchronization and their effects on anonymity;
+    showing the necessity of a refresh operation.
+  \item We design and implement the seamless/native integration of e-cash into the Web architecture, and discuss
+    security and privacy problems of this integration.
+  \item We implemented the GNU Taler payment system and evaluate its
+    performance.
 \end{itemize}
 
-
 \section{Roadmap}
 
 Our overall thesis statement is the following: