aboutsummaryrefslogtreecommitdiff
path: root/doc/paper/taler.tex
diff options
context:
space:
mode:
Diffstat (limited to 'doc/paper/taler.tex')
-rw-r--r--doc/paper/taler.tex128
1 files changed, 65 insertions, 63 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 1f5058d11..6787fcd71 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -78,7 +78,7 @@
%Conference
\acmConference[WOODSTOCK'97]{ACM Woodstock conference}{July 1997}{El
- Paso, Texas USA}
+ Paso, Texas USA}
\acmYear{1997}
\copyrightyear{2016}
@@ -97,8 +97,8 @@
%\affiliation{%
% \institution{Institute for Clarity in Documentation}
% \streetaddress{P.O. Box 1212}
-% \city{Dublin}
-% \state{Ohio}
+% \city{Dublin}
+% \state{Ohio}
% \postcode{43017-6221}
%}
%\email{trovato@corporation.com}
@@ -137,7 +137,7 @@ citizen's needs for private economic activity.
%
% The code below should be generated by the tool at
% http://dl.acm.org/ccs.cfm
-% Please copy and paste the code instead of the example below.
+% Please copy and paste the code instead of the example below.
%
\begin{CCSXML}
<ccs2012>
@@ -161,7 +161,7 @@ citizen's needs for private economic activity.
<concept_desc>Networks~Network reliability</concept_desc>
<concept_significance>100</concept_significance>
</concept>
-</ccs2012>
+</ccs2012>
\end{CCSXML}
\ccsdesc[500]{Computer systems organization~Embedded systems}
@@ -306,13 +306,13 @@ blockchain's decentralized nature to escape anti-money laundering
regulation~\cite{molander1998cyberpayments} as they provide anonymous,
disintermediated transactions.
-%GreenCoinX\footnote{\url{https://www.greencoinx.com/}} is a more
-%recent AltCoin where the company promises to identify the owner of
-%each coin via e-mail addresses and phone numbers. While it is unclear
-%from their technical description how this identification would be
-%enforced against a determined adversary, the resulting payment system
-%would also merely impose a financial panopticon on a Bitcoin-style
-%money supply and transaction model.
+GreenCoinX\footnote{\url{https://www.greencoinx.com/}} is a more
+recent AltCoin where the company promises to identify the owner of
+each coin via e-mail addresses and phone numbers. While it is unclear
+from their technical description how this identification would be
+enforced against a determined adversary, the resulting payment system
+would also merely impose a financial panopticon on a Bitcoin-style
+money supply and transaction model.
%\subsection{Chaum-style electronic cash}
@@ -1165,46 +1165,51 @@ certification process.
%destroying the link between the refunded or aborted transaction and
%the new coin.
+\section{Correctness}
+
+
+
+
+\section{Implementation}
\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!]
+ \includegraphics[width=\columnwidth]{bw_in.png}
+ \caption{Incoming traffic at the exchange, in bytes per 5 minutes.}
+ \label{fig:in}
+\end{figure}\hfill
+ \begin{figure}[b!]
+ \includegraphics[width=\columnwidth]{bw_out.png}
+ \caption{Outgoing traffic from the exchange, in bytes per 5 minutes.}
+ \label{fig:out}
+ \end{figure}
+ \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
@@ -1215,23 +1220,23 @@ FDH operations we used~\cite{rfc5869} with SHA-512 as XTR and SHA-256
for PRF as suggested in~\cite{rfc5869}. 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})
+(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})
+(Figure~\ref{fig:out})
and 160 kbit/sec to the exchange.
-%(Figure~\ref{fig:in}).
+(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
+(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
@@ -1354,9 +1359,9 @@ We thank people (anonymized).
\newpage
\bibliographystyle{ACM-Reference-Format}
-\bibliography{taler}
+\bibliography{taler}
-\end{document}
+%\end{document}
%\vfill
%\begin{center}
@@ -1415,8 +1420,8 @@ data being persisted are represented in between $\langle\rangle$.
\item[$H()$]{Hash function}
\item[$p$]{Payment details of a merchant (i.e. wire transfer details for a bank transfer)}
\item[$r$]{Random nonce}
- \item[${\cal A}$]{Complete contract signed by the merchant}
- \item[${\cal D}$]{Deposit permission, signing over a certain amount of coin to the merchant as payment and to signify acceptance of a particular contract}
+ \item[${\mathcal A}$]{Complete contract signed by the merchant}
+ \item[${\mathcal D}$]{Deposit permission, signing over a certain amount of coin to the merchant as payment and to signify acceptance of a particular contract}
\item[$\kappa$]{Security parameter $\ge 3$}
\item[$i$]{Index over cut-and-choose set, $i \in \{1,\ldots,\kappa\}$}
\item[$\gamma$]{Selected index in cut-and-choose protocol, $\gamma \in \{1,\ldots,\kappa\}$}
@@ -1436,7 +1441,7 @@ data being persisted are represented in between $\langle\rangle$.
% \item[$E_{L^{(i)}}()$]{Symmetric encryption using key $L^{(i)}$}
% \item[$E^{(i)}$]{$i$-th encryption of the private information $(c_s^{(i)}, b_i)$}
% \item[$\vec{E}$]{Vector of $E^{(i)}$}
- \item[$\cal{R}$]{Tuple of revealed vectors in cut-and-choose protocol,
+ \item[$\mathcal{R}$]{Tuple of revealed vectors in cut-and-choose protocol,
where the vectors exclude the selected index $\gamma$}
\item[$\overline{L^{(i)}}$]{Link secrets derived by the verifier from DH}
\item[$\overline{B^{(i)}}$]{Blinded values derived by the verifier}
@@ -1622,9 +1627,7 @@ degrade privacy. We note that the exchange could lie in the linking
protocol about the transfer public key to generate coins that it can
link (at a financial loss to the exchange that it would have to square
with its auditor). However, in the normal course of payments the link
-protocol is never used. Furthermore, if a customer needs to recover
-control over a coin using the linking protocol, they can use the
-refresh protocol on the result to again obtain an unlinkable coin.
+protocol is never used.
\section{Exculpability arguments}
@@ -1988,4 +1991,3 @@ provides a payment system with the following key properties:
The payment system handles both small and large payments in
an efficient and reliable manner.
\end{description}
-