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.tex534
1 files changed, 288 insertions, 246 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index aaeb72b25..4a4f741a3 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,42 +1165,277 @@ certification process.
%destroying the link between the refunded or aborted transaction and
%the new coin.
+\section{Correctness}
+
+\subsection{Taxability arguments}
+
+We assume the exchange operates honestly when discussing taxability.
+We feel this assumption is warranted mostly because a Taler exchange
+requires licenses to operate as a financial institution, which it
+risks loosing if it knowingly facilitates tax evasion.
+We also expect an auditor monitors the exchange similarly to how
+government regulators monitor financial institutions.
+In fact, our auditor software component gives the auditor read access
+to the exchange's database, and carries out test operations anonymously,
+which expands its power over conventional auditors.
+
+\begin{proposition}
+Assuming the exchange operates the refresh protocol honestly,
+a customer operating the refresh protocol dishonestly expects to
+loose $1 - {1 \over \kappa}$ of the value of their coins.
+\end{proposition}
+
+\begin{proof}
+An honest exchange keeps any funds being refreshed if the reveal
+phase is never carried out, does not match the commitment, or shows
+an incorrect commitment. As a result, a customer dishonestly
+refreshing a coin looses their money if they have more than one
+dishonest commitment. If they make exactly one dishonest
+commitment, they have a $1 \over \kappa$ chance of their
+dishonest commitment being selected for the refresh.
+\end{proof}
+
+We say a coin $C$ is {\em controlled} by a user if the user's wallet knows
+its secret scalar $c_s$, the signature $S$ of the appropriate denomination
+key on its public key $C_s$, and the residual value of the coin.
+
+We assume the wallet cannot loose knowledge of a particular coin's
+key material, and the wallet can query the exchange to learn the
+residual value of the coin, so a wallet cannot loose control of
+a coin. A wallet may loose the monetary value associated with a coin
+if another wallet spends it however.
+
+We say a user Alice {\em owns} a coin $C$ if only Alice's wallets can
+gain control of $C$ using standard interactions with the exchange.
+In other words, ownership means exclusive control not just in the
+present, but in the future even if another user interacts with the
+exchange.
+
+\begin{theorem}
+Let $C$ denote a coin controlled by users Alice and Bob.
+Suppose Bob creates a coin $C'$ from $C$ following the refresh protocol.
+Assuming the exchange and Bob operated the refresh protocol correctly,
+and that the exchange continues to operate the linking protocol
+(\S\ref{subsec:linking}) correctly,
+then Alice can gain control of $C'$ using the linking protocol.
+\end{theorem}
+
+\begin{proof}
+Alice may run the linking protocol to obtain all transfer keys $T^i$,
+bindings $B^i$ associated to $C$, and those coins denominations,
+including the $T'$ for $C'$.
+
+We assumed both the exchange and Bob operated the refresh protocol
+correctly, so now $c_s T'$ is the seed from which $C'$ was generated.
+Alice rederives both $c_s$ and the blinding factor to unblind the
+denomination key signature on $C'$. Alice finally asks the exchange
+for the residual value on $C'$ and runs the linking protocol to
+determine if it was refreshed too.
+\end{proof}
+
+\begin{corollary}
+ Abusing the refresh protocol to transfer ownership has an
+ expected loss of $1 - \frac{1}{\kappa}$ of the transaction value.
+\end{corollary}
+
+
+\subsection{Privacy arguments}
+
+The {\em linking problem} for blind signature is,
+if given coin creation transcripts and possibly fewer
+coin deposit transcripts for coins from the creation transcripts,
+then produce a corresponding creation and deposit transcript.
+
+We say an adversary {\em links} coins if it has a non-negligible
+advantage in solving the linking problem, when given the private
+keys of the exchange.
+
+In Taler, there are two forms of coin creation transcripts,
+withdrawal and refresh.
+
+\begin{lemma}
+If there are no refresh operations, any adversary with an
+advantage in linking coins is polynomially equivalent to an
+adversary with the same advantage in recognizing blinding factors.
+\end{lemma}
+
+\begin{proof}
+Let $n$ denote the RSA modulus of the denomination key.
+Also let $d$ and $e$ denote the private and public exponents, respectively.
+In effect, coin withdrawal transcripts consist of numbers
+$b m^d \mod n$ where $m$ is the FDH of the coin's public key
+and $b$ is the blinding factor, while coin deposits transcripts
+consist of only $m^d \mod n$.
+
+Of course, if the adversary can link coins then they can compute
+the blinding factors as $b m^d / m^d \mod n$. Conversely, if the
+adversary can recognize blinding factors then they link coins after
+first computing $b_{i,j} = b_i m_i^d / m_j^d \mod n$ for all $i,j$.
+\end{proof}
+
+We now know the following because Taler uses SHA512 adopted to be
+ a FDH to be the blinding factor.
+
+\begin{corollary}
+Assuming no refresh operation,
+any adversary with an advantage for linking Taler coins gives
+rise to an adversary with an advantage for recognizing SHA512 output.
+\end{corollary}
+
+We will now consider the impact of the refresh operation. For the
+sake of the argument, we will first consider an earlier
+encryption-based version of the protocol in which refresh operated
+consisted of $\kappa$ normal coin withdrawals where the commitment
+consisted of the blinding factors and private keys of the fresh coins
+encrypted using the secret $t^{(i)} C_s$ where $C_s = c_s G$ of the
+dirty coin $C$ being refreshed and $T^{(i)} = t^{(i)} G$ is the
+transfer key.\footnote{We abandoned that version as it required
+ slightly more storage space and the additional encryption
+ primitive.}
+
+\begin{proposition}
+Assuming the encryption used is semantically (IND-CPA) secure, and
+that the independence of $c_s$, $t$, and the new coins' key materials,
+then any probabilistic polynomial time (PPT) adversary with an
+advantage for linking Taler coins gives rise to an adversary with
+ an advantage for recognizing SHA512 output.
+\end{proposition}
+
+In fact, the exchange can launch an chosen cphertext attack against
+the customer by providing different ciphertexts. Yet, the resulting
+plaintext is implicitly authenticated becuase after decryption
+the customer unblinds and checks the signature by the denomination
+key.
+
+If this check does not check out, then the wallet must abandon
+this coin and report the exchange's fraudulent activity.
+
+% TODO: Is independence here too strong?
+
+We may now remove the encrpytion by appealing to the random oracle
+model~\cite{BR-RandomOracles}.
+
+\begin{lemma}[\cite{??}]
+Consider a protocol that commits to random data by encrypting it
+using a secret derived from a Diffe-Hellman key exchange.
+In the random oracle model, we may replace this encryption with
+a hash function which derives the random data by applying hash
+functions to the same secret.
+\end{lemma}
+% TODO: IND-CPA again? Anything else?
+
+\begin{proof}
+We work with the usual instantiation of the random oracle model as
+returning a random string and placing it into a database for future
+queries.
+
+We take the random number generator that drives one random oracle $R$
+to be the random number generator used to produce the random data
+that we encrypt in the old encryption based version of Taler.
+Now our random oracle scheme with $R$ gives the same result as our
+scheme that encrypts random data, so the encryption becomes
+superfluous and may be omitted.
+\end{proof}
+
+We may now conclude that Taler remains unlinkable even with the refresh protocol.
+
+\begin{theorem}
+In the random oracle model, any PPT adversary with an advantage
+in linking Taler coins has an advantage in breaking elliptic curve
+Diffie-Hellman key exchange on Curve25519.
+\end{theorem}
+
+We do not distinguish between information known by the exchange and
+information known by the merchant in the above. As a result, this
+proves that out linking protocol \S\ref{subsec:linking} does not
+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.
+
+\subsection{Exculpability arguments}
+
+\begin{lemma}
+The exchange can detect and prove double-spending.
+\end{lemma}
+
+\begin{proof}
+\end{proof}
+
+\begin{lemma}
+Merchants and customers can verify double-spending proofs.
+\end{lemma}
+
+\begin{proof}
+\end{proof}
+
+
+\begin{lemma}
+Customers can either obtain proof-of-payment or their money back.
+\end{lemma}
+
+\begin{proof}
+\end{proof}
+
+\begin{lemma}
+If a customer paid for a contract, they can prove it.
+\end{lemma}
+
+\begin{proof}
+\end{proof}
+
+\begin{lemma}
+The merchant can issue refunds, and only to the original customer.
+\end{lemma}
+
+\begin{proof}
+\end{proof}
+
+
+
+\begin{theorem}
+ The protocol prevents double-spending and provides exculpability.
+\end{theorem}
+
+
+
+\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}
+\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{figure}[b!]
+ \includegraphics[width=\columnwidth]{db_read.png}
+ \caption{DB read operations per second.}
+ \label{fig:read}
+ \end{figure}
+ \begin{figure}[b!]
+ \includegraphics[width=\columnwidth]{db_write.png}
+ \caption{DB write operations per second.}
+ \label{fig:write}
+ \end{figure}
+ \begin{figure}[b!]
+ \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{figure}
+ \begin{figure}[b!]
+ \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{figure}
% \caption{Selected EC2 performance monitors for the experiment in the EC2
% (after several hours, once the system was ``warm'').}
% \label{fig:ec2}
@@ -1215,23 +1450,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
@@ -1415,8 +1650,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 +1671,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}
@@ -1446,198 +1681,6 @@ data being persisted are represented in between $\langle\rangle$.
\item[$\overline{C^{(i)}_p}$]{Public coin keys computed from $\overline{c_s^{(i)}}$ by the verifier}
\end{description}
-\newpage
-\section{Taxability arguments}
-
-We assume the exchange operates honestly when discussing taxability.
-We feel this assumption is warranted mostly because a Taler exchange
-requires licenses to operate as a financial institution, which it
-risks loosing if it knowingly facilitates tax evasion.
-We also expect an auditor monitors the exchange similarly to how
-government regulators monitor financial institutions.
-In fact, our auditor software component gives the auditor read access
-to the exchange's database, and carries out test operations anonymously,
-which expands its power over conventional auditors.
-
-\begin{proposition}
-Assuming the exchange operates the refresh protocol honestly,
-a customer operating the refresh protocol dishonestly expects to
-loose $1 - {1 \over \kappa}$ of the value of their coins.
-\end{proposition}
-
-\begin{proof}
-An honest exchange keeps any funds being refreshed if the reveal
-phase is never carried out, does not match the commitment, or shows
-an incorrect commitment. As a result, a customer dishonestly
-refreshing a coin looses their money if they have more than one
-dishonest commitment. If they make exactly one dishonest
-commitment, they have a $1 \over \kappa$ chance of their
-dishonest commitment being selected for the refresh.
-\end{proof}
-
-We say a coin $C$ is {\em controlled} by a user if the user's wallet knows
-its secret scalar $c_s$, the signature $S$ of the appropriate denomination
-key on its public key $C_s$, and the residual value of the coin.
-
-We assume the wallet cannot loose knowledge of a particular coin's
-key material, and the wallet can query the exchange to learn the
-residual value of the coin, so a wallet cannot loose control of
-a coin. A wallet may loose the monetary value associated with a coin
-if another wallet spends it however.
-
-We say a user Alice {\em owns} a coin $C$ if only Alice's wallets can
-gain control of $C$ using standard interactions with the exchange.
-In other words, ownership means exclusive control not just in the
-present, but in the future even if another user interacts with the
-exchange.
-
-\begin{theorem}
-Let $C$ denote a coin controlled by users Alice and Bob.
-Suppose Bob creates a coin $C'$ from $C$ following the refresh protocol.
-Assuming the exchange and Bob operated the refresh protocol correctly,
-and that the exchange continues to operate the linking protocol
-(\S\ref{subsec:linking}) correctly,
-then Alice can gain control of $C'$ using the linking protocol.
-\end{theorem}
-
-\begin{proof}
-Alice may run the linking protocol to obtain all transfer keys $T^i$,
-bindings $B^i$ associated to $C$, and those coins denominations,
-including the $T'$ for $C'$.
-
-We assumed both the exchange and Bob operated the refresh protocol
-correctly, so now $c_s T'$ is the seed from which $C'$ was generated.
-Alice rederives both $c_s$ and the blinding factor to unblind the
-denomination key signature on $C'$. Alice finally asks the exchange
-for the residual value on $C'$ and runs the linking protocol to
-determine if it was refreshed too.
-\end{proof}
-
-\begin{corollary}
- Abusing the refresh protocol to transfer ownership has an
- expected loss of $1 - \frac{1}{\kappa}$ of the transaction value.
-\end{corollary}
-
-
-\section{Privacy arguments}
-
-The {\em linking problem} for blind signature is,
-if given coin creation transcripts and possibly fewer
-coin deposit transcripts for coins from the creation transcripts,
-then produce a corresponding creation and deposit transcript.
-
-We say an adversary {\em links} coins if it has a non-negligible
-advantage in solving the linking problem, when given the private
-keys of the exchange.
-
-In Taler, there are two forms of coin creation transcripts,
-withdrawal and refresh.
-
-\begin{lemma}
-If there are no refresh operations, any adversary with an
-advantage in linking coins is polynomially equivalent to an
-adversary with the same advantage in recognizing blinding factors.
-\end{lemma}
-
-\begin{proof}
-Let $n$ denote the RSA modulus of the denomination key.
-Also let $d$ and $e$ denote the private and public exponents, respectively.
-In effect, coin withdrawal transcripts consist of numbers
-$b m^d \mod n$ where $m$ is the FDH of the coin's public key
-and $b$ is the blinding factor, while coin deposits transcripts
-consist of only $m^d \mod n$.
-
-Of course, if the adversary can link coins then they can compute
-the blinding factors as $b m^d / m^d \mod n$. Conversely, if the
-adversary can recognize blinding factors then they link coins after
-first computing $b_{i,j} = b_i m_i^d / m_j^d \mod n$ for all $i,j$.
-\end{proof}
-
-We now know the following because Taler uses SHA512 adopted to be
- a FDH to be the blinding factor.
-
-\begin{corollary}
-Assuming no refresh operation,
-any adversary with an advantage for linking Taler coins gives
-rise to an adversary with an advantage for recognizing SHA512 output.
-\end{corollary}
-
-We will now consider the impact of the refresh operation. For the
-sake of the argument, we will first consider an earlier
-encryption-based version of the protocol in which refresh operated
-consisted of $\kappa$ normal coin withdrawals where the commitment
-consisted of the blinding factors and private keys of the fresh coins
-encrypted using the secret $t^{(i)} C_s$ where $C_s = c_s G$ of the
-dirty coin $C$ being refreshed and $T^{(i)} = t^{(i)} G$ is the
-transfer key.\footnote{We abandoned that version as it required
- slightly more storage space and the additional encryption
- primitive.}
-
-\begin{proposition}
-Assuming the encryption used is semantically (IND-CPA) secure, and
-that the independence of $c_s$, $t$, and the new coins' key materials,
-then any probabilistic polynomial time (PPT) adversary with an
-advantage for linking Taler coins gives rise to an adversary with
- an advantage for recognizing SHA512 output.
-\end{proposition}
-
-In fact, the exchange can launch an chosen cphertext attack against
-the customer by providing different ciphertexts. Yet, the resulting
-plaintext is implicitly authenticated becuase after decryption
-the customer unblinds and checks the signature by the denomination
-key.
-
-If this check does not check out, then the wallet must abandon
-this coin and report the exchange's fraudulent activity.
-
-% TODO: Is independence here too strong?
-
-We may now remove the encrpytion by appealing to the random oracle
-model~\cite{BR-RandomOracles}.
-
-\begin{lemma}[\cite{??}]
-Consider a protocol that commits to random data by encrypting it
-using a secret derived from a Diffe-Hellman key exchange.
-In the random oracle model, we may replace this encryption with
-a hash function which derives the random data by applying hash
-functions to the same secret.
-\end{lemma}
-% TODO: IND-CPA again? Anything else?
-
-\begin{proof}
-We work with the usual instantiation of the random oracle model as
-returning a random string and placing it into a database for future
-queries.
-
-We take the random number generator that drives one random oracle $R$
-to be the random number generator used to produce the random data
-that we encrypt in the old encryption based version of Taler.
-Now our random oracle scheme with $R$ gives the same result as our
-scheme that encrypts random data, so the encryption becomes
-superfluous and may be omitted.
-\end{proof}
-
-We may now conclude that Taler remains unlinkable even with the refresh protocol.
-
-\begin{theorem}
-In the random oracle model, any PPT adversary with an advantage
-in linking Taler coins has an advantage in breaking elliptic curve
-Diffie-Hellman key exchange on Curve25519.
-\end{theorem}
-
-We do not distinguish between information known by the exchange and
-information known by the merchant in the above. As a result, this
-proves that out linking protocol \S\ref{subsec:linking} does not
-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.
-
-
-
\end{document}
@@ -1956,4 +1999,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}
-