diff options
| -rw-r--r-- | stuff.txt | 23 | ||||
| -rw-r--r-- | taler/design.tex | 65 | ||||
| -rw-r--r-- | taler/implementation.tex | 10 | ||||
| -rw-r--r-- | taler/security.tex | 2 | ||||
| -rw-r--r-- | thesis.tex | 6 |
5 files changed, 76 insertions, 30 deletions
@@ -1,3 +1,20 @@ +Priorities: + +1. Christian's feedback for chapter 2 +2. Add full protocol to chapter 3 +3. go over implementation +4. add benchmarks +5. do wallet benchmark + + +-------------------------- +Questions: + +KYC: part of bank? + + +-------------------------- + - probabilistic checks for deposit confirmation auditor: @@ -29,19 +46,17 @@ auditor: - what happens if the auditor detects a problem? -- not discussed: emergency key revocation - - byz consensus chapter does *not* currently contain any references to the blockchain stuff. it should discuss the application in more detail - should the RSA blind signature algorithm be shown somewhere? - -- use conservation instead of fairness +=> yes, complete concrete instantiation - salting of wire hash info? +=> should not happen in the "/wire" response - mention explicitly that taler does not do automatic tax collection diff --git a/taler/design.tex b/taler/design.tex index ccadacb..ebb575b 100644 --- a/taler/design.tex +++ b/taler/design.tex @@ -24,10 +24,10 @@ Section~\ref{section:related-work:blind-signatures}. \subsection{Entities and Trust Model} -GNU Taler consists of the following entities: +GNU Taler consists of the following entities (see \ref{fig:taler-arch}): \begin{itemize} \item The \emph{exchanges} serve as payment service provider for a - financial transaction between a customer and a merchant. It hold bank money + financial transaction between a customer and a merchant. It holds bank money in escrow in exchange for anonymous digital \emph{coins}. \item The \emph{customers} keep e-cash in their electronic \emph{wallets}. \item The \emph{merchants} accept digital coins in exchange for digital or physical @@ -41,10 +41,25 @@ GNU Taler consists of the following entities: \end{itemize} \begin{figure} - \includegraphics[width=\columnwidth]{taler-arch-full.pdf} - \caption{The different components of the Taler system in the - context of a banking system providing money creation, - wire transfers and authentication. (Auditor omitted.)} + \begin{center} + \begin{tikzpicture} + \tikzstyle{def} = [node distance= 5em and 6.5em, inner sep=1em, outer sep=.3em]; + \node (origin) at (0,0) {}; + \node (exchange) [def,above=of origin,draw]{Exchange}; + \node (customer) [def, draw, below left=of origin] {Customer}; + \node (merchant) [def, draw, below right=of origin] {Merchant}; + \node (auditor) [def, draw, above right=of origin]{Auditor}; + + \tikzstyle{C} = [color=black, line width=1pt] + + \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins}; + \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins}; + \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins}; + \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify}; + + \end{tikzpicture} + \end{center} + \caption{High-level overview of the different components of GNU Taler, banks excluded.} \label{fig:taler-arch} \end{figure} @@ -151,15 +166,15 @@ private signing key is limited to at most the amount originally signed with that key, and denomination key rotation can be used to bound that risk. To prevent the exchange from deanonymizing users by signing each coin with a -fresh denomination key, exchanges are publicly announce their denomination keys +fresh denomination key, exchanges publicly announce their denomination keys in advance with validity periods that imply sufficiently strong anonymity sets. These announcements are expected to be signed with an off-line long-term private \emph{master signing key} of the exchange and the auditor. -Additionally, customers should obtain these announcements using an anonymous +Customers should obtain these announcements using an anonymous communication channel. After a coin is issued, the customer is the only entity that knows the -private key of the coin, making him the \emph{owner} of the coin. Due +private key of the coin, making them the \emph{owner} of the coin. Due to the use of blind signatures, the exchange does not learn the public key during the withdrawal process. If the private key is shared with others, they become co-owners of the coin. Knowledge of @@ -197,7 +212,7 @@ withdraw the refreshed coins makes them unlinkable from the old coin. \subsection{Refreshing and Taxability} % FIXME: maybe put section on how to avoid withdraw loophole here! One goal of Taler is to make merchants' income transparent to state auditors, -so that income can be taxed appropriately. Naively implemented, however, the +so that income can be taxed appropriately. Naively implemented, however, a simple refresh protocol could be used to evade taxes: the payee of an untaxed transaction would generate the private keys for the coins that result from refreshing a (partially spent) old coin, and sent the corresponding public keys @@ -215,28 +230,29 @@ and could deposit them before the merchant gets a chance to do so. This disincentivizes the circulation of unreported income among untrusted parties in the system. -In Taler's implementation of the refresh and linking protocol, there is a -non-neglegible success chance (typically 1/3, depending on system parameters) -for attempts to cheat during the refresh protocol, resulting in refreshed coins -that can't be recovered from the old coin via the linking protocol. Cheating -during refresh, however, is still not \emph{profitable}, as an unsuccessful -attempt at cheating can always be discovered, and results in completely losing -the amount that was intended to be refreshed. +In Taler's implementation of the refresh and linking protocols, there is a +non-neglegible success chance ($1\kappa$, depending on system parameter +$\kappa$, typically $\ge 3$) for attempts to cheat during the refresh protocol, +resulting in refreshed coins that cannot be recovered from the old coin via the +linking protocol. Cheating during refresh, however, is still not +\emph{profitable}, as an unsuccessful attempt results in completely losing the +amount that was intended to be refreshed. % FIXME: mention that we don't want to use DRM/HSMs for this For purposes of anti-money-laundering and taxation, a more detailed audit of -the merchant's transactions can be desirable. An auditor can request the -merchant to reveal the business agreement details that match the contract terms -hash recorded with the exchange. If a merchant is not able to provide theses -values, they can be subjected to financial penalties by the state in relation -to the amount transferred by the traditional currency transfer. +the merchant's transactions can be desirable. A government tax authority can +request the merchant to reveal the business agreement details that match the +contract terms hash recorded with the exchange. If a merchant is not able to +provide theses values, they can be subjected to financial penalties by the +state in relation to the amount transferred by the traditional currency +transfer. \subsection{Transactions vs. Sharing} Sharing---in contrast to a transaction---happens when mutually trusted parties simultaneously have access to the private keys and signatures on coins. -Sharing is not considered a transaction, as both parties have equal control +Sharing is not considered a transaction, as subsequently both parties have equal control over the funds. A useful application for sharing are peer-to-peer payments between mutually trusting parties, such as families and friends. @@ -930,9 +946,10 @@ transaction between two parties that is not recognized by the system for the purpose of income taxation. \subsubsection{Tick Payments} +% FIXME: also works off-line Tick payments were proposed by Pedersen \cite{pedersen1996electronic} as a general technique to amortize the cost for small, recurring payments to the -same payee. The payer first makes up-front deposit as one larger payment +same payee. The payer first makes an up-front deposit as one larger payment that involves the payment processor. To make a micropayment, the payer sends a message to the payee that authorizes the payee to claim a fraction of this deposit. Each further micropayment simply increases the fraction of the diff --git a/taler/implementation.tex b/taler/implementation.tex index 1bf75ed..b7ec807 100644 --- a/taler/implementation.tex +++ b/taler/implementation.tex @@ -109,7 +109,15 @@ into a bigger wire transfer. This allows Taler to be used even for microtransactions of amounts smaller than usually handled by the underlying banking system. -As shown in Figure~\ref{fig:taler-arch}, the merchant is internally split +\begin{figure} + \includegraphics[width=\columnwidth]{taler-arch-full.pdf} + \caption{The different components of the Taler system in the + context of a banking system providing money creation, + wire transfers and authentication. (Auditor omitted.)} + \label{fig:taler-arch-full} +\end{figure} + +As shown in Figure~\ref{fig:taler-arch-full}, the merchant is internally split into multiple components. The implementation of the Taler prococol and cryptographic operations is isolated into a separate component, called the \emph{merchant backend}, which the merchant accesses through an API diff --git a/taler/security.tex b/taler/security.tex index ad42078..4d2a26c 100644 --- a/taler/security.tex +++ b/taler/security.tex @@ -863,7 +863,7 @@ Hence we ensure that: \item if a coin was refreshed, the customer ``owns'' the resulting coins, even if the operation was aborted, and \item if the customer withdraws, they can always obtain a coin whenever the - exchange accounted for a withdrawl, even when protocol executions are + exchange accounted for a withdrawal, even when protocol executions are intermittently aborted. \end{itemize} @@ -61,6 +61,12 @@ \usepackage[usenames,dvipsnames,svgnames,table]{xcolor} +\usepackage{tikz} +\usetikzlibrary{shapes,arrows} +\usetikzlibrary{positioning} +\usetikzlibrary{calc} + + \usepackage{mdframed} \KOMAoption{titlepage}{firstiscover} |