taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

FC17 formatting, stress refresh protocol in title and abstract; stress cut-and-choose is practical with kappa=3

Browse Source
This commit is contained in:
Christian Grothoff 2016-10-07 13:34:54 +02:00
parent 56efe31c40
commit 581ca30052
1 changed files with 136 additions and 116 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

216
doc/paper/taler.tex
View File

@ -34,7 +34,7 @@
\usetikzlibrary{calc}
% \usepackage{enumitem}
\usepackage{caption}
\usepackage{subcaption}
%\usepackage{subcaption}
\usepackage{subfig}
% \usepackage{sidecap}
% \usepackage{wrapfig}
@ -63,7 +63,7 @@
% - sharing = coin copying that should not be taxed
\title{Taler: Taxable Anonymous Libre Electronic Reserves}
\title{Refreshing Coins for Giving Change and Refunds \\ in Chaum-style Anonymous Payments}
\begin{document}
\mainmatter
@ -84,13 +84,19 @@ fully audited. 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
systems that do not provide for privacy. Taler unique {\em refresh
protocol} allows fractional payments and refunds while maintaining
anonymity of the customer and unlinkability of transactions.
systems that do not provide for privacy.
The key technical contribution underpinning Taler is a new {\em
refresh protocol} which allows fractional payments and refunds while
maintaining anonymity of the customer and unlinkability of
transactions. The refresh protocol combines an efficient
cut-and-choose mechanism with a {\em link} step to ensure that
refreshing is not abused for transactional payments.
We argue that Taler provides a secure digital currency for modern
liberal societies as it is a flexible, libre and efficient protocol
and adequately balances the state's need for monetary control with
the citizen's needs for private economic activity.
and adequately balances the state's need for monetary control with the
citizen's needs for private economic activity.
\end{abstract}
\section{Introduction}
@ -702,11 +708,11 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
$p$ is the merchant's payment information (e.g. his IBAN number), and
$r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$
to disk and sends $\mathcal{A}$ to the customer.
\item[Customer Setup] % \label{deposit}
\item[Customer Setup]
The customer should already possess a coin issued by a exchange that is
accepted by the merchant, meaning $K$ should be publicly signed by
some $X_j$ from $\vec{X}$, and has a value $\geq f$.
\item[POST {\tt /???}]
\item[POST {\tt /???}] \label{deposit}
The customer generates a \emph{deposit-permission}
$\mathcal{D} := S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$
and sends $\langle \mathcal{D}, X_j\rangle$ to the merchant,
@ -779,9 +785,18 @@ denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$
with the same denomination. In practice, Taler uses a natural
extension where multiple fresh coins are generated a the same time to
enable giving precise change matching any amount.
In the protocol, $\kappa \ge 3$ is a security parameter and $G$ is the
In the protocol, $\kappa \ge 3$ is a security parameter for the
cut-and-choose part of the protocol and $G$ is the
generator of the elliptic curve.
We note that $\kappa = 3$ is actually perfectly sufficient in most
cases in practice, as the cut-and-choose protocol does not need to
provide cryptographic security: If the maximum applicable tax is less
than $\frac{2}{3}$, then detecting $\kappa = 3$ ensures that cheating
results in a negative return on average as $\kappa - 1$ out of
$\kappa$ attempts to cheat are detected. This makes the use of
cut-and-choose practical and efficient in this context.
% FIXME: I'm explicit about the rounds in postquantum.tex
\begin{description}
@ -969,62 +984,66 @@ transaction.
\section{Experimental results}
\begin{figure}[b!]
\begin{subfigure}{0.45\columnwidth}
\includegraphics[width=\columnwidth]{bw_in.png}
\caption{Incoming traffic at the exchange, in bytes per 5 minutes.}
\label{fig:in}
\end{subfigure}\hfill
\begin{subfigure}{0.45\columnwidth}
\includegraphics[width=\columnwidth]{bw_out.png}
\caption{Outgoing traffic from the exchange, in bytes per 5 minutes.}
\label{fig:out}
\end{subfigure}
\begin{subfigure}{0.45\columnwidth}
\includegraphics[width=\columnwidth]{db_read.png}
\caption{DB read operations per second.}
\label{fig:read}
\end{subfigure}
\begin{subfigure}{0.45\columnwidth}
\includegraphics[width=\columnwidth]{db_write.png}
\caption{DB write operations per second.}
\label{fig:write}
\end{subfigure}
\begin{subfigure}{0.45\columnwidth}
\includegraphics[width=\columnwidth]{cpu_balance.png}
\caption{CPU credit balance. Hitting a balance of 0 shows the CPU is
the limiting factor.}
\label{fig:cpu}
\end{subfigure}\hfill
\begin{subfigure}{0.45\columnwidth}
\includegraphics[width=\columnwidth]{cpu_usage.png}
\caption{CPU utilization. The t2.micro instance is allowed to use 10\% of
one CPU.}
\label{fig:usage}
\end{subfigure}
\caption{Selected EC2 performance monitors for the experiment in the EC2
(after several hours, once the system was ``warm'').}
\label{fig:ec2}
\end{figure}
%\begin{figure}[b!]
% \begin{subfigure}{0.45\columnwidth}
% \includegraphics[width=\columnwidth]{bw_in.png}
% \caption{Incoming traffic at the exchange, in bytes per 5 minutes.}
% \label{fig:in}
% \end{subfigure}\hfill
% \begin{subfigure}{0.45\columnwidth}
% \includegraphics[width=\columnwidth]{bw_out.png}
% \caption{Outgoing traffic from the exchange, in bytes per 5 minutes.}
% \label{fig:out}
% \end{subfigure}
% \begin{subfigure}{0.45\columnwidth}
% \includegraphics[width=\columnwidth]{db_read.png}
% \caption{DB read operations per second.}
% \label{fig:read}
% \end{subfigure}
% \begin{subfigure}{0.45\columnwidth}
% \includegraphics[width=\columnwidth]{db_write.png}
% \caption{DB write operations per second.}
% \label{fig:write}
% \end{subfigure}
% \begin{subfigure}{0.45\columnwidth}
% \includegraphics[width=\columnwidth]{cpu_balance.png}
% \caption{CPU credit balance. Hitting a balance of 0 shows the CPU is
% the limiting factor.}
% \label{fig:cpu}
% \end{subfigure}\hfill
% \begin{subfigure}{0.45\columnwidth}
% \includegraphics[width=\columnwidth]{cpu_usage.png}
% \caption{CPU utilization. The t2.micro instance is allowed to use 10\% of
% one CPU.}
% \label{fig:usage}
% \end{subfigure}
% \caption{Selected EC2 performance monitors for the experiment in the EC2
% (after several hours, once the system was ``warm'').}
% \label{fig:ec2}
%\end{figure}
We ran the Taler exchange v0.0.2 on an Amazon EC2 t2.micro instance
(10\% of a Xeon E5-2676 at 2.4 GHz) based on Ubuntu 14.04.4 LTS, using
a db.t2.micro instance with Postgres 9.5 for the database. Using 16
concurrent clients performing withdraw, deposit and refresh operations
we then pushed the t2.micro instance to the resource limit
(Figure~\ref{fig:cpu}) from a network with $\approx$ 160 ms latency to
%(Figure~\ref{fig:cpu})
from a network with $\approx$ 160 ms latency to
the EC2 instance. At that point, the instance managed about 8 HTTP
requests per second, which roughly corresponds to one full business
transaction (as a full business transaction is expected to involve
withdrawing and depositing several coins). The network traffic was
modest at approximately 50 kbit/sec from the exchange
(Figure~\ref{fig:out}) and 160 kbit/sec to the exchange
(Figure~\ref{fig:in}). At network latencies above 10 ms, the delay
%(Figure~\ref{fig:out})
and 160 kbit/sec to the exchange.
%(Figure~\ref{fig:in}).
At network latencies above 10 ms, the delay
for executing a transaction is dominated by the network latency, as
local processing virtually always takes less than 10 ms.
Database transactions are dominated by writes (Figure~\ref{fig:read}
vs. Figure~\ref{fig:write}), as Taler mostly needs to log
Database transactions are dominated by writes
%(Figure~\ref{fig:read} vs. Figure~\ref{fig:write})
, as Taler mostly needs to log
transactions and occasionally needs to read to guard against
double-spending. Given a database capacity of 2 TB---which should
suffice for more than one year of full transaction logs---the
@ -1047,52 +1066,7 @@ payment system.
\section{Discussion}
Taler was designed for use in a modern social-liberal society and
provides a payment system with the following key properties:
\begin{description}
\item[Customer Anonymity]
It is impossible for exchanges, merchants and even a global active
adversary, to trace the spending behavior of a customer.
As a strong form of customer anonymity, it is also infeasible to
link a set of transactions to the same (anonymous) customer.
%, even when taking aborted transactions into account.
There is, however, a risk of metadata leakage if a customer
acquires coins matching exactly the price quoted by a merchant, or
if a customer uses coins issued by multiple exchanges for the same
transaction. Hence, our implementation does not allow this.
\item[Taxability]
In many current legal systems, it is the responsibility of the merchant
to deduct sales taxes from purchases made by customers, or for workers
to pay income taxes for payments received for work.
Taler ensures that merchants are easily identifiable and that
an audit trail is generated, so that the state can ensure that its
taxation regime is obeyed.
\item[Verifiability]
Taler minimizes the trust necessary between
participants. In particular, digital signatures are retained
whenever they would play a role in resolving disputes.
Additionally, customers cannot defraud anyone, and
merchants can only defraud their customers by not
delivering on the agreed contract. Neither merchants nor customers
are able to commit fraud against the exchange.
Only the exchange needs be tightly audited and regulated.
\item[No speculation] % It's actually "Specualtion not required"
The digital coins are denominated in existing currencies,
such as EUR or USD. This avoids exposing citizens to unnecessary risks
from currency fluctuations.
\item[Low resource consumption]
The design minimizes the operating costs and environmental impact of
the payment system. It uses few public key operations per
transaction and entirely avoids proof-of-work computations.
The payment system handles both small and large payments in
an efficient and reliable manner.
\end{description}
\subsection{Well-known attacks}
% \subsection{Well-known attacks}
Taler's security is largely equivalent to that of Chaum's original
design without online checks or the cut-and-choose revelation of
@ -1557,3 +1531,49 @@ microdonations, it can always choose to switch to the macropayment
system with slightly higher transaction costs to remain in business.
\newpage
Taler was designed for use in a modern social-liberal society and
provides a payment system with the following key properties:
\begin{description}
\item[Customer Anonymity]
It is impossible for exchanges, merchants and even a global active
adversary, to trace the spending behavior of a customer.
As a strong form of customer anonymity, it is also infeasible to
link a set of transactions to the same (anonymous) customer.
%, even when taking aborted transactions into account.
There is, however, a risk of metadata leakage if a customer
acquires coins matching exactly the price quoted by a merchant, or
if a customer uses coins issued by multiple exchanges for the same
transaction. Hence, our implementation does not allow this.
\item[Taxability]
In many current legal systems, it is the responsibility of the merchant
to deduct sales taxes from purchases made by customers, or for workers
to pay income taxes for payments received for work.
Taler ensures that merchants are easily identifiable and that
an audit trail is generated, so that the state can ensure that its
taxation regime is obeyed.
\item[Verifiability]
Taler minimizes the trust necessary between
participants. In particular, digital signatures are retained
whenever they would play a role in resolving disputes.
Additionally, customers cannot defraud anyone, and
merchants can only defraud their customers by not
delivering on the agreed contract. Neither merchants nor customers
are able to commit fraud against the exchange.
Only the exchange needs be tightly audited and regulated.
\item[No speculation] % It's actually "Specualtion not required"
The digital coins are denominated in existing currencies,
such as EUR or USD. This avoids exposing citizens to unnecessary risks
from currency fluctuations.
\item[Low resource consumption]
The design minimizes the operating costs and environmental impact of
the payment system. It uses few public key operations per
transaction and entirely avoids proof-of-work computations.
The payment system handles both small and large payments in
an efficient and reliable manner.
\end{description}