stash for merge
This commit is contained in:
Christian Grothoff
parent
39b30ac8c9
commit
f143ee4cea
@ -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}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user