taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Add some FIXMEs to section 4 on naming and describing protocols

Browse Source
This commit is contained in:
Jeff Burdges 2016-05-22 17:13:44 +02:00
parent 4615cea151
commit 8565132c2c
1 changed files with 22 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/paper/taler.tex
View File

@ -693,9 +693,10 @@ resumed at any step. Commitments to disk are cumulative, that is an
additional commitment does not erase the previously committed additional commitment does not erase the previously committed
information. Keys and thus coins always have a well-known expiration information. Keys and thus coins always have a well-known expiration
date; information committed to disk can be discarded after the date; information committed to disk can be discarded after the
expiration date of the respective public key. Customers can also expiration date of the respective public key.
discard information once the respective coins have been fully spent, Customers may discard information once the respective coins have been
and merchants may discard information once payments from the exchange have 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 been received, assuming the records are also no longer needed for tax
purposes. The exchange's bank transfers dealing in traditional currency purposes. The exchange's bank transfers dealing in traditional currency
are expected to be recorded for tax authorities to ensure taxability. 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 digital coins, the customer performs the following interaction with
the exchange: 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} \begin{enumerate}
\item The customer identifies a exchange with an auditor-approved \item The customer identifies a exchange with an auditor-approved
denomination public-private key pair $K := (K_s, K_p)$ 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)$ with signature $\widetilde{C} := S_K(C_p)$
where $K$ is the exchange's demonination key. 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} \begin{enumerate}
\item\label{contract} \item\label{contract}
Let $\vec{D} := D_1, \ldots, D_n$ be the list of exchanges accepted by 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 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 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 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}, If a transaction is aborted after Step~\ref{deposit},
subsequent transactions with the same coin could be linked to the coin, 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 In the protocol, $\kappa \ge 3$ is a security parameter and $G$ is the
generator of the elliptic curve. generator of the elliptic curve.
% FIXME: I'm explicit about the rounds in postquantum.tex
\begin{enumerate} \begin{enumerate}
\item For each $i = 1,\ldots,\kappa$, the customer randomly generates \item For each $i = 1,\ldots,\kappa$, the customer randomly generates
\begin{itemize} \begin{itemize}
@ -905,6 +919,8 @@ generator of the elliptic curve.
\subsection{Linking} \subsection{Linking}
% FIXME: What is \mathtt{link} ?
For a coin that was successfully refreshed, the exchange responds to a For a coin that was successfully refreshed, the exchange responds to a
request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E^{(\gamma)}, request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E^{(\gamma)},
\widetilde{C})$. \widetilde{C})$.
@ -1026,8 +1042,8 @@ withdrawals, which we believe is a better trade-off than the
problematic escrow systems where the necessary intransparency problematic escrow systems where the necessary intransparency
actually facilitates voluntary cooperation between the exchange and actually facilitates voluntary cooperation between the exchange and
criminals~\cite{sander1999escrow} and where state can selectively criminals~\cite{sander1999escrow} and where state can selectively
deanonymize activists to support the deep state's quest for absolute deanonymize activists to support the deep state's quixotic pursute of
security. absolute security.
\subsection{Offline Payments} \subsection{Offline Payments}