slight improvements

1 files changed, 271 insertions, 178 deletions

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 0b23cfa38..96f074058 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -522,67 +522,6 @@ been spent.
 %deposit permission signed by the coin's owner with the mint, and then
 %proceeds with the contract.
 
-\paragraph{Incremental payments.}
-
-For services that include pay-as-you-go billing, customers can over
-time sign deposit permissions for an increasing fraction of the value
-of a coin to be paid to a particular merchant.  As checking with the
-mint for each increment might be expensive, the coin's owner can
-instead sign a {\em lock permission}, which allows the merchant to get
-an exclusive right to redeem deposit permissions for the coin for a
-limited duration.  The merchant uses the lock permission to determine
-if the coin has already been spent and to ensure that it cannot be
-spent by another merchant for the {\em duration} of the lock as
-specified in the lock permission.  If the coin has been spent or is
-already locked, the mint provides the owner's deposit or locking
-request and signature to prove the attempted fraud by the customer.
-Otherwise, the mint locks the coin for the expected duration of the
-transaction (and remembers the lock permission).  The merchant and the
-customer can then finalize the business transaction, possibly
-exchanging a series of incremental payment permissions for services.
-Finally, the merchant then redeems the coin at the mint before the
-lock permission expires to ensure that no other merchant spends the
-coin first.
-
-
-\paragraph{Probabilistic spending.}
-
-Similar to Peppercoin, Taler supports probabilistic spending of coins to
-support cost-effective transactions for small amounts.  Here, an
-ordinary transaction is performed based on the result of a biased coin
-flip with a probability related to the desired transaction amount in
-relation to the value of the coin.  Unlike Peppercoin, in Taler either
-the merchant wins and the customer looses the coin, or the merchant
-looses and the customer keeps the coin.  Thus, there is no opportunity
-for the merchant and the customer to conspire against the mint.  To
-determine if the coin is to be transferred, merchant and customer
-execute a secure coin flipping protocol~\cite{blum1981}.  The commit
-values are included in the business contract and are revealed after
-the contract has been signed using the private key of the coin.  If
-the coin flip is decided in favor of the merchant, the merchant can
-redeem the coin at the mint.
-
-One issue in this protocol is that the customer may use a worthless
-coin by offering a coin that has already been spent.  This kind of
-fraud would only be detected if the customer actually lost the coin
-flip, and at this point the merchant might not be able to recover from
-the loss.  A fradulent anonymous customer may run the protocol using
-already spent coins until the coin flip is in his favor.  As with
-incremental spending, lock permissions could be used to ensure that
-the customer cannot defraud the merchant by offering a coin that has
-already been spent.  However, as this means involving the mint even if
-the merchant looses the coin flip, such a scheme is unsuitable for
-microdonations as the transaction costs from involving the mint might
-be disproportionate to the value of the transaction, and thus with
-locking the probabilistic scheme has no advantage over simply using
-fractional payments.
-
-Hence, Taler uses probabilistic transactions {\em without} the online
-double-spending detection.  This enables the customer to defraud the
-merchant by paying with a coin that was already spent.  However, as,
-by definition, such microdonations are for tiny amounts, the incentive
-for customers to pursue this kind of fraud is limited.
-
 
 \subsection{Refreshing Coins}
 
@@ -694,7 +633,8 @@ following interaction with the mint:
         local wallet) for future use.
 \end{enumerate}
 
-\subsection{Exact, partial and incremental spending}
+
+\subsection{Exact and partial spending}
 
 A customer can spend coins at a merchant, under the condition that the
 merchant trusts the mint that minted the coin.  Merchants are
@@ -707,103 +647,47 @@ by a mint's denomination key $K$, i.e. the customer posses
 $\widetilde{C} := S_K(C_p)$:
 
 \begin{enumerate}
-\item\label{offer} The merchant sends an \emph{offer:} $\langle S_M(m, f),
-  \vec{D} \rangle$ containing the price of the offer $f$, a transaction
-  ID $m$ and the list of mints $D_1, \ldots, D_n$ accepted by the merchant
-  where each $D_i$ is a mint's public key.
-\item\label{lock} The customer must possess or acquire a coin minted by a mint that is
+\item\label{contract} Let $\vec{D} := D_1, \ldots, D_n$ be the list of
+  mints accepted by the merchant where each $D_i$ is a mint's public
+  key.  The merchant creates a digitally signed contract $\mathcal{A}
+  := S_M(m, f, a, H(p, r), \vec{D})$ where $a$ is data relevant to the
+  contract indicating which services or goods the merchant will
+  deliver to the customer, $f$ is the price of the offer, and $p$ is
+  the merchant's payment information (e.g. his IBAN number) and $r$ is
+  an random nounce.  The merchant commits $\langle \mathcal{A}
+  \rangle$ to disk and sends $\mathcal{A}$ it to the customer.
+\item\label{deposit} The customer must possess or acquire a coin minted by a mint that is
   accepted by the merchant, i.e. $K$ should be publicly signed by some $D_i
-  \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.
-
-  Customer then generates a \emph{lock-permission} $\mathcal{L} :=
-  S_c(\widetilde{C}, t, m, f, M_p)$ where $t$ specifies the time until which the
-  lock is valid and sends $\langle \mathcal{L}, D_i\rangle$ to the merchant,
+  \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$. (The customer
+  can of course also use multiple coins where the total value adds up to
+  the cost of the transaction and run the following steps for each of
+  the coins. However, for simplicity of the description here we will
+  assume that one coin is sufficient.)
+
+  The customer then generates a \emph{deposit-permission} $\mathcal{D} :=
+  S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$ 
+  and sends $\langle \mathcal{D}, D_i\rangle$ to the merchant,
   where $D_i$ is the mint which signed $K$.
-\item The merchant asks the mint to apply the lock by sending $\langle
-  \mathcal{L} \rangle$ to the mint.
-\item The mint validates $\widetilde{C}$ and detects double spending if there is
-  a lock-permission record $S_c(\widetilde{C}, t', m', f', M_p')$ where $(t',
-  m', f', M_p') \neq (t, m, f, M_p)$ or a \emph{deposit-permission} record for
-  $C$ and sends it to the merchant, who can then use it prove to the customer
-  and subsequently ask the customer to issue a new lock-permission.
-
-  If double spending is not found, the mint commits $\langle \mathcal{L} \rangle$ to disk
-  and notifies the merchant that locking was successful.
-\item\label{contract} The merchant creates a digitally signed contract
-  $\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract
-  indicating which services or goods the merchant will deliver to the customer, and $p$ is the
-  merchant's payment information (e.g. his IBAN number) and $r$ is an random nounce.
-  The merchant commits $\langle \mathcal{A} \rangle$ to disk and sends it to the customer.
-\item The customer creates a
-  \emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, f, m, M_p, H(a), H(p, r))$, commits
-  $\langle \mathcal{A}, \mathcal{D} \rangle$ to disk and sends $\mathcal{D}$ to the merchant.
-\item\label{invoice_paid} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk.
 \item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing his
   payment information.
-\item The mint verifies $(\mathcal{D}, p, r)$ for its validity.  A
-  \emph{deposit-permission} for a coin $C$ is valid if:
-  \begin{itemize}
-  \item $C$ is not refreshed already
-  \item there exists no other \emph{deposit-permission} on disk for \\
-    $\mathcal{D'} := S_c(\widetilde{C}, f', m', M_p', H(a'), H(p', r'))$ for $C$
-    such that \\ $(f', m',M_p', H(a')) \neq (f, m, M_p, H(a))$
-  \item  $H(p, r) := H(p', r')$
-  \end{itemize}
-  If $C$ is valid and no other \emph{deposit-permission} for $C$ exists on disk, the
-  mint does the following:
-  \begin{enumerate}
-    \item if a \emph{lock-permission} exists for $C$, it is deleted from disk
-    \item\label{transfer} transfers an amount of $f$ to the merchant's bank account
-      given in $p$.  The subject line of the transaction to $p$ must contain
-      $H(\mathcal{D})$.
-    \item $\langle \mathcal{D}, p, r \rangle$ is commited to disk.
-  \end{enumerate}
-  If the deposit record $\langle \mathcal{D}, p, r \rangle$ already exists,
-  the mint sends it to the merchant, but does not transfer money to $p$ again.
-\end{enumerate}
 
-To facilitate incremental spending of a coin $C$ in a single transaction, the
-merchant makes an offer in Step~\ref{offer} with a maximum amount $f_{max}$ he
-is willing to charge in this transaction from the coin $C$.  After obtaining the
-lock on $C$ for $f_{max}$, the merchant makes a contract in Step~\ref{contract}
-with an amount $f \leq f_{max}$.  The protocol follows with the following steps
-repeated after Step~\ref{invoice_paid} whenever the merchant wants to charge an
-incremental amount up to $f_{max}$:
+\item The mint validates $\mathcal{D}$ and detects double spending.
+  If the coin has been involved in previous transactions, it sends an error
+  with the records from the previous transactions back to the merchant.
 
-\begin{enumerate}
-  \setcounter{enumi}{4}
-\item The merchant generates a new contract $ \mathcal{A}' := S_M(m, f', a', H(p,
-  r)) $ after obtaining the deposit-permission for a previous contract.  Here
-  $f'$ is the accumulated sum the merchant is charging the customer, of which
-  the merchant has received a deposit-permission for $f$ from the previous
-  contract \textit{i.e.}~$f <f' \leq f_{max}$.  Similarly $a'$ is the new
-  contract data appended to older contract data $a$.
-  The merchant commits $\langle \mathcal{A}' \rangle$ to disk and sends it to the customer.
-\item Customer commits $\langle \mathcal{A}' \rangle$ to disk, creates
-  $\mathcal{D}' := S_c(\widetilde{C}, f', m, M_p, H(a'), H(p, r))$, commits
-  $\langle \mathcal{D'} \rangle$ and sends it to the merchant.
-\item The merchant commits the received $\langle \mathcal{D'} \rangle$ and
-  deletes the older $\mathcal{D}$
-\end{enumerate}
-
-%Figure~\ref{fig:spending_protocol_interactions} summarizes the interactions of the
-%coin spending protocol.
-
-For transactions with multiple coins, the steps of the protocol are executed in
-parallel for each coin.
+  If double spending is not found, the mint commits $\langle \mathcal{D} \rangle$ to disk
+  and notifies the merchant that deposit operation was successful.
 
-During the time a coin is locked, it may not be spent at a
-different merchant.  To make the storage costs of the mint more predictable,
-only one lock per coin can be active at any time, even if the lock only covers a
-fraction of the coin's denomination.  The mint will delete the locks when they
-expire.  Thus the coins can be reused once their locks expire.  However, doing
-so may link the new transaction to older transaction.
+\item The merchant commits and forwards the notification from the mint to the
+  customer, confirming the success or failure of the operation.
+\end{enumerate}
 
-Similarly, if a transaction is aborted after Step 2, subsequent transactions
-with the same coin can be linked to the coin, but not directly to the coin's
-owner.  The same applies to partially spent coins.  To unlink subsequent
-transactions from a coin, the customer has to execute the coin refreshing
-protocol with the mint.
+Similarly, if a transaction is aborted after Step~\ref{deposit},
+subsequent transactions with the same coin can be linked to the coin,
+but not directly to the coin's owner.  The same applies to partially
+spent coins (where $f$ is smaller than the actual value of the coin).
+To unlink subsequent transactions from a coin, the customer has to
+execute the coin refreshing protocol with the mint.
 
 %\begin{figure}[h]
 %\centering
@@ -838,33 +722,20 @@ protocol with the mint.
 %\end{figure}
 
 
-\subsection{Probabilistic spending}
-
-The following steps are executed for microdonations with upgrade probability $p$:
-\begin{enumerate}
-  \item The merchant sends an offer to the customer.
-  \item The customer sends a commitment $H(r_c)$ to a random
-    value $r_c \in [0,2^R)$, where $R$ is a system parameter.
-  \item The merchant sends random $r_m \in [0,2^R)$ to the customer.
-    \item The customer computes $p' := (|r_c - r_m|) / (2^R)$.
-    If $p' < p$, the customer sends a coin with deposit-permission to the merchant.
-    Otherwise, the customer sends $r_c$ to the merchant.
-  \item The merchant deposits the coin, or checks if $r_c$ is consistent
-    with $H(r_c)$.
-\end{enumerate}
-
 \subsection{Refreshing}
 
-The following protocol is executed in order to refresh a coin $C'$ of denomination $K$ to
-a fresh coin $\widetilde{C}$ with the same denomination. In the protocol, $\kappa \ge 3$ is a security parameter and $G$ is the generator of the elliptic curve.
+The following protocol is executed in order to refresh a coin $C'$ of
+denomination $K$ to a fresh coin $\widetilde{C}$ with the same
+denomination. In the protocol, $\kappa \ge 3$ is a security parameter
+and $G$ is the generator of the elliptic curve.
 
 \begin{enumerate}
   \item For each $i = 1,\ldots,\kappa$, the customer
     \begin{itemize}
-      \item randomly generates transfer key $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$ where $T^{(i)}_p := t^{(i)}_s \cdot G$,
-      \item randomly generates coin key pair $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$ where $C^{(i)}_p := c^{(i)}_s \cdot G$,
+      \item randomly generates transfer key $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$ where $T^{(i)}_p := t^{(i)}_s G$,
+      \item randomly generates coin key pair $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$ where $C^{(i)}_p := c^{(i)}_s G$,
       \item randomly generates blinding factors $b_i$,
-      \item computes $E_i := E_{K_i}\left(c_s^{(i)}, b_i\right)$ where $K_i := c'_s \cdot T_p^{(i)}$ (The encryption key $K_i$ is
+      \item computes $E_i := E_{K_i}\left(c_s^{(i)}, b_i\right)$ where $K_i := H(c'_s T_p^{(i)})$. (The encryption key $K_i$ is
             computed by multiplying the private key $c'_s$ of the original coin with the point on the curve
             that represents the public key $T^{(i)}_p$ of the transfer key $T^{(i)}$.),
     \end{itemize}
@@ -874,7 +745,7 @@ a fresh coin $\widetilde{C}$ with the same denomination. In the protocol, $\kapp
     here $E_{b_i}$ denotes Chaum-style blinding with blinding factor $b_i$.
   \item The mint generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
     marks $C'_p$ as spent by committing
-    $\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T}) \rangle$ to disk
+    $\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T}) \rangle$ to disk.
   \item The mint sends $S_K(C'_p, \gamma)$ to the customer.\footnote{Instead of $K$, it is also
     possible to use any equivalent mint signing key known to the customer here, as $K$ merely
     serves as proof to the customer that the mint selected this particular $\gamma$.}
@@ -884,19 +755,19 @@ a fresh coin $\widetilde{C}$ with the same denomination. In the protocol, $\kapp
   \item \label{step:refresh-ccheck} The mint checks whether $\mathfrak{R}$ is consistent with the commitments;
         specifically, it computes for $i \not= \gamma$:
     \begin{itemize}
-      \item $\overline{K}_i := t_s^{(i)} \cdot C_p'$,
+      \item $\overline{K}_i := H(t_s^{(i)} C_p')$,
       \item $(\overline{c}_s^{(i)}, \overline{b}_i) := D_{\overline{K}_i}(E_i)$,
-      \item $\overline{C}^{(i)}_p := \overline{c}_s^{(i)} \cdot G$,
+      \item $\overline{C}^{(i)}_p := \overline{c}_s^{(i)} G$,
       \item $\overline{B}_i := E_{b_i}(C_p^{(i)})$,
       \item $\overline{T}_i := t_s^{(i)} G$,
     \end{itemize}
     and checks if $\overline{C}^{(i)}_p = C^{(i)}_p$ and $H(E_i, \overline{B}_i, \overline{T}^{(i)}_p) = H(E_i, B_i, T^{(i)}_p)$
     and $\overline{T}_i = T_i$.
 
-  \item \label{step:refresh-done} If the commitments were consistent, the mint sends the blind signature
-    $\widetilde{C} := S_{K}(B_\gamma)$ to the customer.
-    Otherwise, the mint responds with an error and confiscates the value of $C'$,
-    committing $\langle C', \gamma, S_{C'}(\mathfrak{R}) \rangle$ to disk as proof for the attempted fraud.
+  \item \label{step:refresh-done} If the commitments were consistent,
+    the mint sends the blind signature $\widetilde{C} :=
+    S_{K}(B_\gamma)$ to the customer.  Otherwise, the mint responds
+    with an error the value of $C'$.
 \end{enumerate}
 
 %\subsection{N-to-M Refreshing}
@@ -905,6 +776,7 @@ a fresh coin $\widetilde{C}$ with the same denomination. In the protocol, $\kapp
 
 \subsection{Linking}
 
+% FIXME: explain better...
 For a coin that was successfully refreshed, the mint responds to
 a request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E_{\gamma}, \widetilde{C})$.
 
@@ -992,4 +864,225 @@ transactions.
 
 \bibliographystyle{alpha}
 \bibliography{taler}
+
+\appendix
+
+\section{Optional features}
+
+In this appendix we detail various optional features that can
+be added to the basic protocol.
+
+\subsection{Refunds}
+
+
+\subsection{Incremental spending}
+
+For services that include pay-as-you-go billing, customers can over
+time sign deposit permissions for an increasing fraction of the value
+of a coin to be paid to a particular merchant.  As checking with the
+mint for each increment might be expensive, the coin's owner can
+instead sign a {\em lock permission}, which allows the merchant to get
+an exclusive right to redeem deposit permissions for the coin for a
+limited duration.  The merchant uses the lock permission to determine
+if the coin has already been spent and to ensure that it cannot be
+spent by another merchant for the {\em duration} of the lock as
+specified in the lock permission.  If the coin has been spent or is
+already locked, the mint provides the owner's deposit or locking
+request and signature to prove the attempted fraud by the customer.
+Otherwise, the mint locks the coin for the expected duration of the
+transaction (and remembers the lock permission).  The merchant and the
+customer can then finalize the business transaction, possibly
+exchanging a series of incremental payment permissions for services.
+Finally, the merchant then redeems the coin at the mint before the
+lock permission expires to ensure that no other merchant spends the
+coin first.
+
+\begin{enumerate}
+\item\label{offer2} The merchant sends an \emph{offer:} $\langle S_M(m, f),
+  \vec{D} \rangle$ containing the price of the offer $f$, a transaction
+  ID $m$ and the list of mints $D_1, \ldots, D_n$ accepted by the merchant
+  where each $D_i$ is a mint's public key.
+\item\label{lock2} The customer must possess or acquire a coin minted by a mint that is
+  accepted by the merchant, i.e. $K$ should be publicly signed by some $D_i
+  \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.
+
+  Customer then generates a \emph{lock-permission} $\mathcal{L} :=
+  S_c(\widetilde{C}, t, m, f, M_p)$ where $t$ specifies the time until which the
+  lock is valid and sends $\langle \mathcal{L}, D_i\rangle$ to the merchant,
+  where $D_i$ is the mint which signed $K$.
+\item The merchant asks the mint to apply the lock by sending $\langle
+  \mathcal{L} \rangle$ to the mint.
+\item The mint validates $\widetilde{C}$ and detects double spending if there is
+  a lock-permission record $S_c(\widetilde{C}, t', m', f', M_p')$ where $(t',
+  m', f', M_p') \neq (t, m, f, M_p)$ or a \emph{deposit-permission} record for
+  $C$ and sends it to the merchant, who can then use it prove to the customer
+  and subsequently ask the customer to issue a new lock-permission.
+
+  If double spending is not found, the mint commits $\langle \mathcal{L} \rangle$ to disk
+  and notifies the merchant that locking was successful.
+\item\label{contract2} The merchant creates a digitally signed contract
+  $\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract
+  indicating which services or goods the merchant will deliver to the customer, and $p$ is the
+  merchant's payment information (e.g. his IBAN number) and $r$ is an random nounce.
+  The merchant commits $\langle \mathcal{A} \rangle$ to disk and sends it to the customer.
+\item The customer creates a
+  \emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, f, m, M_p, H(a), H(p, r))$, commits
+  $\langle \mathcal{A}, \mathcal{D} \rangle$ to disk and sends $\mathcal{D}$ to the merchant.
+\item\label{invoice_paid2} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk.
+\item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing his
+  payment information.
+\item The mint verifies $(\mathcal{D}, p, r)$ for its validity.  A
+  \emph{deposit-permission} for a coin $C$ is valid if:
+  \begin{itemize}
+  \item $C$ is not refreshed already
+  \item there exists no other \emph{deposit-permission} on disk for \\
+    $\mathcal{D'} := S_c(\widetilde{C}, f', m', M_p', H(a'), H(p', r'))$ for $C$
+    such that \\ $(f', m',M_p', H(a')) \neq (f, m, M_p, H(a))$
+  \item  $H(p, r) := H(p', r')$
+  \end{itemize}
+  If $C$ is valid and no other \emph{deposit-permission} for $C$ exists on disk, the
+  mint does the following:
+  \begin{enumerate}
+    \item if a \emph{lock-permission} exists for $C$, it is deleted from disk.
+    \item\label{transfer2} transfers an amount of $f$ to the merchant's bank account
+      given in $p$.  The subject line of the transaction to $p$ must contain
+      $H(\mathcal{D})$.
+    \item $\langle \mathcal{D}, p, r \rangle$ is commited to disk.
+  \end{enumerate}
+  If the deposit record $\langle \mathcal{D}, p, r \rangle$ already exists,
+  the mint sends it to the merchant, but does not transfer money to $p$ again.
+\end{enumerate}
+
+To facilitate incremental spending of a coin $C$ in a single transaction, the
+merchant makes an offer in Step~\ref{offer2} with a maximum amount $f_{max}$ he
+is willing to charge in this transaction from the coin $C$.  After obtaining the
+lock on $C$ for $f_{max}$, the merchant makes a contract in Step~\ref{contract2}
+with an amount $f \leq f_{max}$.  The protocol follows with the following steps
+repeated after Step~\ref{invoice_paid2} whenever the merchant wants to charge an
+incremental amount up to $f_{max}$:
+
+\begin{enumerate}
+  \setcounter{enumi}{4}
+\item The merchant generates a new contract $ \mathcal{A}' := S_M(m, f', a', H(p,
+  r)) $ after obtaining the deposit-permission for a previous contract.  Here
+  $f'$ is the accumulated sum the merchant is charging the customer, of which
+  the merchant has received a deposit-permission for $f$ from the previous
+  contract \textit{i.e.}~$f <f' \leq f_{max}$.  Similarly $a'$ is the new
+  contract data appended to older contract data $a$.
+  The merchant commits $\langle \mathcal{A}' \rangle$ to disk and sends it to the customer.
+\item Customer commits $\langle \mathcal{A}' \rangle$ to disk, creates
+  $\mathcal{D}' := S_c(\widetilde{C}, f', m, M_p, H(a'), H(p, r))$, commits
+  $\langle \mathcal{D'} \rangle$ and sends it to the merchant.
+\item The merchant commits the received $\langle \mathcal{D'} \rangle$ and
+  deletes the older $\mathcal{D}$
+\end{enumerate}
+
+%Figure~\ref{fig:spending_protocol_interactions} summarizes the interactions of the
+%coin spending protocol.
+
+For transactions with multiple coins, the steps of the protocol are executed in
+parallel for each coin.
+
+During the time a coin is locked, it may not be spent at a
+different merchant.  To make the storage costs of the mint more predictable,
+only one lock per coin can be active at any time, even if the lock only covers a
+fraction of the coin's denomination.  The mint will delete the locks when they
+expire.  Thus the coins can be reused once their locks expire.  However, doing
+so may link the new transaction to older transaction.
+
+Similarly, if a transaction is aborted after Step 2, subsequent transactions
+with the same coin can be linked to the coin, but not directly to the coin's
+owner.  The same applies to partially spent coins.  To unlink subsequent
+transactions from a coin, the customer has to execute the coin refreshing
+protocol with the mint.
+
+%\begin{figure}[h]
+%\centering
+%\begin{tikzpicture}
+%
+%\tikzstyle{def} = [node distance= 1em, inner sep=.5em, outer sep=.3em];
+%\node (origin) at (0,0) {};
+%\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)};
+%\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)};
+%\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ mint)};
+%\node (C) [def,below=of B]{confirm (or refuse) lock (mint $\rightarrow$ merchant)};
+%\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)};
+%\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)};
+%\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ mint)};
+%\node (G) [def,below=of F]{transfer confirmation (mint $\rightarrow$ merchant)};
+%
+%\tikzstyle{C} = [color=black, line width=1pt]
+%\draw [->,C](offer) -- (A);
+%\draw [->,C](A) -- (B);
+%\draw [->,C](B) -- (C);
+%\draw [->,C](C) -- (D);
+%\draw [->,C](D) -- (E);
+%\draw [->,C](E) -- (F);
+%\draw [->,C](F) -- (G);
+%
+%\draw [->,C, bend right, shorten <=2mm] (E.east)
+%      to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east);
+%\end{tikzpicture}
+%\caption{Interactions between a customer, merchant and mint in the coin spending
+%  protocol}
+%\label{fig:spending_protocol_interactions}
+%\end{figure}
+
+
+
+\subsection{Probabilistic spending}
+
+Similar to Peppercoin, Taler supports probabilistic spending of coins to
+support cost-effective transactions for small amounts.  Here, an
+ordinary transaction is performed based on the result of a biased coin
+flip with a probability related to the desired transaction amount in
+relation to the value of the coin.  Unlike Peppercoin, in Taler either
+the merchant wins and the customer looses the coin, or the merchant
+looses and the customer keeps the coin.  Thus, there is no opportunity
+for the merchant and the customer to conspire against the mint.  To
+determine if the coin is to be transferred, merchant and customer
+execute a secure coin flipping protocol~\cite{blum1981}.  The commit
+values are included in the business contract and are revealed after
+the contract has been signed using the private key of the coin.  If
+the coin flip is decided in favor of the merchant, the merchant can
+redeem the coin at the mint.
+
+One issue in this protocol is that the customer may use a worthless
+coin by offering a coin that has already been spent.  This kind of
+fraud would only be detected if the customer actually lost the coin
+flip, and at this point the merchant might not be able to recover from
+the loss.  A fradulent anonymous customer may run the protocol using
+already spent coins until the coin flip is in his favor.  As with
+incremental spending, lock permissions could be used to ensure that
+the customer cannot defraud the merchant by offering a coin that has
+already been spent.  However, as this means involving the mint even if
+the merchant looses the coin flip, such a scheme is unsuitable for
+microdonations as the transaction costs from involving the mint might
+be disproportionate to the value of the transaction, and thus with
+locking the probabilistic scheme has no advantage over simply using
+fractional payments.
+
+Hence, Taler uses probabilistic transactions {\em without} the online
+double-spending detection.  This enables the customer to defraud the
+merchant by paying with a coin that was already spent.  However, as,
+by definition, such microdonations are for tiny amounts, the incentive
+for customers to pursue this kind of fraud is limited.
+
+
+
+The following steps are executed for microdonations with upgrade probability $p$:
+\begin{enumerate}
+  \item The merchant sends an offer to the customer.
+  \item The customer sends a commitment $H(r_c)$ to a random
+    value $r_c \in [0,2^R)$, where $R$ is a system parameter.
+  \item The merchant sends random $r_m \in [0,2^R)$ to the customer.
+    \item The customer computes $p' := (|r_c - r_m|) / (2^R)$.
+    If $p' < p$, the customer sends a coin with deposit-permission to the merchant.
+    Otherwise, the customer sends $r_c$ to the merchant.
+  \item The merchant deposits the coin, or checks if $r_c$ is consistent
+    with $H(r_c)$.
+\end{enumerate}
+
+
+
 \end{document}