diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/paper/taler.tex | 128 |
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} - |