stash for merge

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}
-