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

use status codes we actually use in the implementation now

Browse Source
This commit is contained in:
Christian Grothoff 2016-10-25 14:58:24 +02:00
parent 093db2e646
commit f52222ebd5
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/paper/taler.tex
View File

@ -660,14 +660,14 @@ Now the customer carries out the following interaction with the exchange:
The customer sends $S_W(B)$ where $B := B_b(\FDH_K(C_p))$ to The customer sends $S_W(B)$ where $B := B_b(\FDH_K(C_p))$ to
the exchange to request withdrawal of $C$; here, $B_b$ denotes the exchange to request withdrawal of $C$; here, $B_b$ denotes
Chaum-style blinding with blinding factor $b$. Chaum-style blinding with blinding factor $b$.
\item[200 OK / 402 PAYMENT REQUIRED] \item[200 OK / 403 FORBIDDEN]
The exchange checks if the same withdrawal request was issued before; The exchange checks if the same withdrawal request was issued before;
in this case, it sends a Chaum-style blind signature $S_K(B)$ with in this case, it sends a Chaum-style blind signature $S_K(B)$ with
private key $K_s$ to the customer. \\ private key $K_s$ to the customer. \\
If this is a fresh withdrawal request, the exchange performs the following transaction: If this is a fresh withdrawal request, the exchange performs the following transaction:
\begin{enumerate} \begin{enumerate}
\item checks if the reserve $W_p$ has sufficient funds \item checks if the reserve $W_p$ has sufficient funds
for a coin of value corresponding to $K$ for a coin of value corresponding to $K$,
\item stores the withdrawal request and response \item stores the withdrawal request and response
$\langle S_W(B), S_K(B) \rangle$ in its database $\langle S_W(B), S_K(B) \rangle$ in its database
for future reference, for future reference,
@ -680,7 +680,7 @@ Now the customer carries out the following interaction with the exchange:
history for the reserve. history for the reserve.
% FIXME: Is it really the whole history? % FIXME: Is it really the whole history?
\item[Done] The customer computes and verifies the unblinded signature \item[Done] The customer computes and verifies the unblinded signature
$S_K(\FDH_K{C_p}) = U_b(S_K(B))$. $S_K(\FDH_K(C_p)) = U_b(S_K(B))$.
Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$ Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$
to their local wallet on disk. to their local wallet on disk.
\end{description} \end{description}
@ -730,7 +730,7 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
\item[POST {\tt/deposit}] \item[POST {\tt/deposit}]
The merchant gives $(\mathcal{D}, p, r)$ to the exchange, thereby The merchant gives $(\mathcal{D}, p, r)$ to the exchange, thereby
revealing $p$ only to the exchange. revealing $p$ only to the exchange.
\item[200 OK / 409 CONFLICT] \item[200 OK / 403 FORBIDDEN]
The exchange validates $\mathcal{D}$ and checks for double spending. The exchange validates $\mathcal{D}$ and checks for double spending.
If the coin has been involved in previous transactions and the new If the coin has been involved in previous transactions and the new
one would exceed its remaining value, it sends an error one would exceed its remaining value, it sends an error
@ -952,7 +952,7 @@ faulty exchange.
The third case are transient failures, such as network failures or The third case are transient failures, such as network failures or
temporary hardware failures at the exchange service provider. Here, the temporary hardware failures at the exchange service provider. Here, the
client may receive an explicit protocol indication, such as an HTTP client may receive an explicit protocol indication, such as an HTTP
response code 500 ``internal server error'' or simply no response. response code ``500 INTERNAL SERVER ERROR'' or simply no response.
The appropriate behavior for the client is to automatically retry The appropriate behavior for the client is to automatically retry
after 1s, and twice more at randomized times within 1 minute. after 1s, and twice more at randomized times within 1 minute.
If those three attempts fail, the user should be informed about the If those three attempts fail, the user should be informed about the