ref fixes

3 files changed, 31 insertions, 30 deletions

diff --git a/taler/design.tex b/taler/design.tex
index f583757..712cdd0 100644
--- a/taler/design.tex
+++ b/taler/design.tex
@@ -18,9 +18,8 @@ payments is discussed in Chapter~\ref{chapter:implementation}.
 
 GNU Taler is based on the idea of Chaumian e-cash, with some differences and
 additions explained in the following sections.  Other variants and extensions
-of e-cash are discussed in Section~\ref{section:related-work:ecash}, and
-different blind signature algorithms are discussed in
-Section~\ref{section:related-work:blind-signatures}.
+of e-cash and blind signatures are discussed in
+Section~\ref{sec:related-work:e-cash}.
 
 
 \subsection{Entities and Trust Model}
@@ -80,8 +79,9 @@ parties.
 
 \subsection{System Assumptions}
 
+% FIXME: Tor might not be strong enough, so it's not really an example!
 We assume that an anonymous bi-directional communication channel such as
-Tor~\cite{tor-design} is used for all communication between the customer and
+Tor~\cite{dingledine2004tor} is used for all communication between the customer and
 the merchant, as well as for obtaining unlinkable change for partially spent
 coins from the exchange and for retrieving the exchange's
 denomination keys.
@@ -164,7 +164,7 @@ pre-filled bank account details of the exchange as well as the reserve public
 key.  The customer clicks on this link or scans the QR code to invoke their
 banking app with pre-filled transaction details.  Since there currently is no
 standardized format for pre-filled wire transfer details, we are proposing the
-\texttt{payto://} URI format explained in section \ref{sec:payto}, currently
+\texttt{payto://} URI format explained in section \ref{appendix:payto}, currently
 under review for acceptance as an IETF Internet Standard.
 
 
@@ -189,7 +189,7 @@ once more coins are redeemed than the total that was signed into existence
 using that denomination key.  In this case, the exchange can allow authentic
 customers to redeem their unspent coins that were signed with the compromised
 private key, while refusing further deposits involving coins signed by the
-compromised denomination key (see Section~\ref{sec:payback}).  As a result, the
+compromised denomination key (see Section~\ref{sec:revocation-payback}).  As a result, the
 financial damage of losing a private signing key is limited to at most the
 amount originally signed with that key, and denomination key rotation can be
 used to bound that risk.
@@ -238,7 +238,7 @@ withdraw the refreshed coins makes them unlinkable from the old coin.
 
 % FIXME: talk about logarithmic time, simulation
 
-\subsection{Refreshing and Taxability}\cite{sec:design-refresh}
+\subsection{Refreshing and Taxability}\label{sec:design-refresh}
 % FIXME:  maybe put section on how to avoid withdraw loophole here!
 One goal of Taler is to make merchants' income transparent to state auditors,
 so that income can be taxed appropriately.  Naively implemented, however, a simple
@@ -330,7 +330,7 @@ merchant, effectively hiding the fees from the customer.
 % FIXME: explain wire fee amortization
 
 
-\subsection{The Withdraw Loophole and Tipping}
+\subsection{The Withdraw Loophole and Tipping}\label{taler:design:tipping}
 The withdraw protocol can be (ab)used to illicitly transfer money, when the
 receiver generates the coin's secret key, and gives the public key to the party
 executing the withdraw protocol.  We call this the ``withdraw loophole''.  This
@@ -344,7 +344,7 @@ agreement.
 
 % FIXME:  argue that this can't be done on scale for money laundering
 
-\subsubsection{Fixing the Withdraw Loophole}
+\subsubsection{Fixing the Withdraw Loophole}\label{taler:design:fixing-withdraw-loophole}
 
 In order to discourage the usage of the withdraw loophole for untaxed payments,
 the following approach would be possible:  Normal withdraw operations and
@@ -541,7 +541,7 @@ to export evidence and upholds the core principles described
 in~\cite{fc2014murdoch}.  In particular, in providing the cryptographic proofs
 as evidence none of the participants have to disclose their core secrets.
 
-\subsection{Perfect Crime Scenarios}
+\subsection{Perfect Crime Scenarios}\label{sec:design:blackmailing}
 The key revokation and emergency payback mechanism described in Section
 \ref{sec:revocation-payback} can also be used against criminals in perfect
 crime / kidnapping scenarios where the adversary demands to be paid a ransom in
diff --git a/taler/implementation.tex b/taler/implementation.tex
index f9221ca..e1cd6b0 100644
--- a/taler/implementation.tex
+++ b/taler/implementation.tex
@@ -709,7 +709,7 @@ URL. A HTTP GET on that URL will return a list of refund confirmations that the
 merchant received from the exchange.
 
 \subsection{Tipping}
-Tipping in Taler uses the ``withdraw loophole'' (see \ref{XXX}) to allow the
+Tipping in Taler uses the ``withdraw loophole'' (see \ref{taler:design:tipping}) to allow the
 merchant\footnote{We still use the term ``merchant'', since donations use the same software component
 as the merchant, but ``donor'' would be more accurate.} to donate small amounts (without any associated contract terms or legal
 obligations) into the user's wallet.
@@ -773,7 +773,7 @@ syntax makes parsing of \texttt{payto} URIs trivial with existing parsers.
 
 Formally, a \texttt{payto} URI is an encoding of a partially filled out pro
 forma invoice.  The full specification (in the form of an IETF draft currently
-at the time of writing) of the \texttt{payto} URI is in Appendix \ref{XXX}.
+at the time of writing) of the \texttt{payto} URI is in Appendix~\ref{appendix:payto}.
 
 In the implementation of Taler, \texttt{payto} URIs are used in various places:
 \begin{enumerate}
@@ -897,6 +897,7 @@ certifies these keys with the \texttt{taler-auditor-sign} tool.
 \begin{figure}
     \includegraphics[width=\textwidth]{diagrams/taler-diagram-keyup.png}
     \caption{Dataflow for updating the exchange's keys.}
+    \label{figure:keyup}
 \end{figure}
 
 This process is illustrated in Figure~\ref{figure:keyup}.
@@ -1190,7 +1191,7 @@ Instead, an overlay or separate tab/window displays the prompt to the user.
 
 In this section, we describe the main cryptographic protocols for Taler in more
 detail.  Effectively this corresponds to a concrete instantiation of the
-protocols in Section \ref{sec:abstract-instantiation}.
+protocols in Section \ref{sec:crypto:instantiation}.
 
 For ease of presentation, we do not provide a bit-level description of the
 cryptographic protocol.  Some details from the implementation are left out,
@@ -1606,12 +1607,12 @@ to provide service many merchants and all of their customers.  Thus the exchange
 is the bottleneck for the performance of the system.
 
 We provide a microbenchmark for the performance of cryptographic operations in
-the wallet (Table~\ref{table:wallet-benchmark)}.  Even on a low-end smartphone
+the wallet (Table~\ref{table:wallet-benchmark}.  Even on a low-end smartphone
 devices, the most expensive cryptographic operations remains well under
 $150ms$, a threshold for user-interface latency under which user happyiness and
 productivity is considered to be unaffected \cite{tolia2006quantifying}.
 
-\begin{table}\label{table:wallet-benchmark}
+\begin{table}
   \centering
   \begin{subtable}[t]{0.4\linewidth}
   \centering{
@@ -1783,7 +1784,7 @@ hash context finish         & 0.28  &  1215   & 1227   \\
   \bottomrule
   \end{tabular}
   \caption{Cryptographic operations in the benchmark with one client and $10000$ operations.}
-  \label{table:baseline-benchmark}
+  \label{table:benchmark:ops-baseline}
 \end{table}
 
 
diff --git a/taler/security.tex b/taler/security.tex
index ee4ca0d..051eca0 100644
--- a/taler/security.tex
+++ b/taler/security.tex
@@ -1651,13 +1651,13 @@ In particular, the following features are left out of the formal discussion:
     exchange to know (or learn from the customer) the exact amount to be payed
     for the contract.
 
-    A complication in practice is that merchants may not want to reveal their
-    full bank account information to the customer, but this information is
-    necessary for the exchange to process the deposit, since we do not require
-    merchants to register beforehand the exchange (as the merchant might
-    support all exchanges audited by a specific auditor). We discuss a protocol
-    extension that allows customers to deposit coins on behalf of merchants
-    in~\ref{XXX}.
+    %A complication in practice is that merchants may not want to reveal their
+    %full bank account information to the customer, but this information is
+    %necessary for the exchange to process the deposit, since we do not require
+    %merchants to register beforehand the exchange (as the merchant might
+    %support all exchanges audited by a specific auditor). We discuss a protocol
+    %extension that allows customers to deposit coins on behalf of merchants
+    %in~\ref{XXX}.
 
   \item The fees incurred for operations, the protocols for backup and
     synchronization as well as other possible extensions like tick payments are
@@ -1666,12 +1666,12 @@ In particular, the following features are left out of the formal discussion:
   %\item FIXME: auditor
 \end{itemize}
 
-We note that customer tipping (see \ref{XXX}) basically amounts to an execution
+We note that customer tipping (see \ref{taler:design:tipping}) basically amounts to an execution
 of the \algo{Withdraw} protocol where the party that generates the coin keys
 and blinding factors (in that case the merchant's customer) is different from
 the party that signs the withdraw request (the merchant with a ``customer'' key
 pair tied to the merchant's bank account).  While this is desirable in some
-cases, we discussed in \ref{XXX} how this ``loophole'' for a one-hop untaxed
+cases, we discussed in \ref{taler:design:fixing-withdraw-loophole} how this ``loophole'' for a one-hop untaxed
 payment could be avoided.
 
 \subsection{Other Properties}
@@ -1689,14 +1689,14 @@ hard drive), the next payment will cause a double spend, resulting in anonymity
 loss and a penalty for the customer.
 
 % FIXME: move this to design or implementation
-\subsubsection{Fair Exchange}
+\subsubsection{Fair Exchange}\label{sec:security:atomic-swaps}
 
 % FIXME: we should mention "atomic swap" here
 
-The Endorsed E-Cash system by Camenisch et al. (described in Section
-\ref{sec:security-related-work}) allows for fair exchange of (online or
-offline) e-cash against digital goods.  The online version does not protect the
-customer against loss of anonymity from linkability of aborted fair exchanges.
+The Endorsed E-Cash system by Camenisch et al. \cite{camenisch2007endorsed}
+allows for fair exchange of (online or offline) e-cash against digital goods.
+The online version does not protect the customer against loss of anonymity from
+linkability of aborted fair exchanges.
 
 Taler's refresh protocol can be used for fair exchange of online e-cash against
 digital goods, without any loss of anonymity due to linkability of aborted