Add some FIXMEs to section 4 on naming and describing protocols

1 files changed, 22 insertions, 6 deletions

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 911090b46..1344d728f 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -693,9 +693,10 @@ resumed at any step.  Commitments to disk are cumulative, that is an
 additional commitment does not erase the previously committed
 information.  Keys and thus coins always have a well-known expiration
 date; information committed to disk can be discarded after the
-expiration date of the respective public key.  Customers can also
-discard information once the respective coins have been fully spent,
-and merchants may discard information once payments from the exchange have
+expiration date of the respective public key.  
+Customers may discard information once the respective coins have been
+fully spent, so long as refunds are not required.  
+Merchants may discard information once payments from the exchange have
 been received, assuming the records are also no longer needed for tax
 purposes.  The exchange's bank transfers dealing in traditional currency
 are expected to be recorded for tax authorities to ensure taxability.
@@ -706,6 +707,14 @@ Let $G$ be the generator of an elliptic curve.  To withdraw anonymous
 digital coins, the customer performs the following interaction with
 the exchange:
 
+% FIXME: We say withdrawal key in this document, but say reserve key in
+% others, so probably withdrawal key should be renamed to reserve key.
+
+% FIXME: These steps occur at very different points in time, so probably
+% they should be restructured into more of a protocol discription. 
+% It does create some confusion, like is a withdrawal key semi-ephemeral
+% like a linking key?
+
 \begin{enumerate}
   \item The customer identifies a exchange with an auditor-approved
         denomination public-private key pair $K := (K_s, K_p)$
@@ -752,6 +761,9 @@ for a transaction in which the customer spends a coin $C := (c_s, C_p)$
 with signature $\widetilde{C} := S_K(C_p)$
  where $K$ is the exchange's demonination key.
 
+% FIXME: Again, these steps occur at different points in time, maybe
+% that's okay, but refresh is slightly different.
+
 \begin{enumerate}
 \item\label{contract}
   Let $\vec{D} := D_1, \ldots, D_n$ be the list of exchanges accepted by
@@ -790,7 +802,7 @@ in practice a customer can use multiple coins from the same exchange where
 the total value adds up to $f$ by running the following steps for
 each of the coins.  There is a risk of metadata leakage if a customer
 acquires a coin in responce to the merchant, or if a customer uses
-coings issued by multiple exchanges together.
+coins issued by multiple exchanges together.
 
 If a transaction is aborted after Step~\ref{deposit},
 subsequent transactions with the same coin could be linked to the coin,
@@ -842,6 +854,8 @@ enable giving precise change matching any amount.
 In the protocol, $\kappa \ge 3$ is a security parameter and $G$ is the
 generator of the elliptic curve.
 
+% FIXME: I'm explicit about the rounds in postquantum.tex
+
 \begin{enumerate}
   \item For each $i = 1,\ldots,\kappa$, the customer randomly generates
     \begin{itemize}
@@ -905,6 +919,8 @@ generator of the elliptic curve.
 
 \subsection{Linking}
 
+% FIXME: What is \mathtt{link} ?
+
 For a coin that was successfully refreshed, the exchange responds to a
 request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E^{(\gamma)},
 \widetilde{C})$.
@@ -1026,8 +1042,8 @@ withdrawals, which we believe is a better trade-off than the
 problematic escrow systems where the necessary intransparency
 actually facilitates voluntary cooperation between the exchange and
 criminals~\cite{sander1999escrow} and where state can selectively
-deanonymize activists to support the deep state's quest for absolute
-security.
+deanonymize activists to support the deep state's quixotic pursute of
+absolute security.
 
 \subsection{Offline Payments}