format for 15 pages

1 files changed, 19 insertions, 20 deletions

diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex
index baa7b14..3fae525 100644
--- a/taler-fc19/paper.tex
+++ b/taler-fc19/paper.tex
@@ -157,7 +157,7 @@ or $\V{refreshed}$ lists nor in $\V{acceptedContracts}$.  We say that a coin is
 being $\V{overspent}$ if recording an operation in $\V{deposited}$ or

 $\V{refreshed}$ would cause the total spent value from both lists to exceed

 the value of the coin's denomination.

-

+%

 Note that the adversary does not have direct read or write access to these

 values; instead the adversary needs to use the oracles (defined in Section~\ref{sec:oracles}) to

 interact with the system.

@@ -241,11 +241,10 @@ of parties maintained by the challenger in the security games which we define la
     denomination requested in the corresponding $\algo{WithdrawRequest}$

     execution.  How exactly $\V{pkD}$ is restored depends on the particular instantiation.

 

-    The resulting coin

-    \[ \V{coin} = (\V{skCoin}, \V{pkCoin}, \V{pkD}, \V{coinCert}) \]

-    (consisting of secret key $\V{skCoin}$, public key

-    $\V{pkCoin}$, denomination public key $\V{pkD}$ and certificate $\V{coinCert}$ from the exchange) is stored

-    in the customers wallet $\V{wallet}[\V{pkCustomer}]$.

+    The resulting coin $\V{coin} := (\V{skCoin}, \V{pkCoin}, \V{pkD}, \V{coinCert})$,

+    consisting of secret key $\V{skCoin}$, public key

+    $\V{pkCoin}$, denomination public key $\V{pkD}$ and certificate $\V{coinCert}$ from the exchange,

+    is stored in the customers wallet $\V{wallet}[\V{pkCustomer}]$.

 

     Executing the $\algo{WithdrawPickup}$ protocol multiple times with the same

     customer and the same withdraw identifier does not result in any change of

@@ -259,20 +258,20 @@ of parties maintained by the challenger in the security games which we define la
     Algorithm to produce and sign a deposit permission \V{depositPermission}

     for a coin under a particular transaction identifier.  The fraction $0 < f \le 1$ determines the

     fraction of the coin's initial value that will be spent.

-

+%

     The contents of the deposit permission depend on the instantiation, but it

     must be possible to derive the public coin identifier $\V{pkCoin}$ from

     them.

 

   \item $\algo{Deposit}(\prt{E}(\V{sksE}, \V{pkMerchant}), \prt{M}(\V{skMerchant}, \V{pksE}, \V{depositPermission})) \mapsto \mathcal{T}_D$:

     Interactive protocol between the exchange and a merchant.

-

+%

     From the deposit permission we obtain the $\V{pkCoin}$ of the coin to be

     deposited.  If $\V{pkCoin}$ is being overspent, the protocol is aborted with

     an error message to the merchant.

-

+%

     On success, we add $\V{depositPermission}$ to $\V{deposited}[\V{pkCoin}]$.

-

+%

     Returns a protocol transcript $\mathcal{T}_D$ of all messages exchanged

     between the exchange and merchant.

 

@@ -280,18 +279,18 @@ of parties maintained by the challenger in the security games which we define la
       \rightarrow (\mathcal{T}_{RR}, \V{rid})$

     Interactive protocol between exchange and customer that initiates a refresh

     of $\V{coin}_0$.  Together with $\algo{RefreshPickup}$, it allows the

-    customer to convert $D(\V{pkD}_u)$ of the remaining value on coin \[

-      \V{coin}_0 = (\V{skCoin}_0, \V{pkCoin}_0, \V{pkD}_0, \V{coinCert}_0) \]

+    customer to convert $D(\V{pkD}_u)$ of the remaining value on coin

+    $\V{coin}_0 = (\V{skCoin}_0, \V{pkCoin}_0, \V{pkD}_0, \V{coinCert}_0)$

     into a new, unlinkable coin $\V{coin}_u$ of denomination $\V{pkD}_u$.

-

+%

     Multiple refreshes on the same coin are allowed, but each run subtracts the

     respective financial value of $\V{coin}_u$ from the remaining value of

     $\V{coin}_0$.

-

+%

     The customer only records the refresh operation identifier $\V{rid}$ in

     $\V{refreshIds}[\V{pkCustomer}]$, but does not yet obtain the new coin.  To

     obtain the new coin, \algo{RefreshPickup} must be used.

-

+%

     Returns the protocol transcript $\mathcal{T}_{RR}$ and a refresh identifier $\V{rid}$.

 

   \item $\algo{RefreshPickup}(\prt{E}(\V{sksE}, \V{pkCustomer}),

@@ -299,28 +298,28 @@ of parties maintained by the challenger in the security games which we define la
     Interactive protocol between exchange and customer to obtain the new coin

     for a refresh operation previously started with \algo{RefreshRequest},

     identified by the refresh identifier $\V{rid}$.

-

+%

     The first time \algo{RefreshPickup} is run for a particular refresh

     identifier, the exchange tries to record the refresh operation of value $D(\V{pkD}_u)$

     in $\V{refreshed}[\V{pkCoin}_0]$, with $\V{pkD}_u$ and $\V{pkCoin}_0$ taken

     from the corresponding $\algo{RefreshRequest}$ that resulted in $\V{rid}$.

     How exactly the exchange obtains $\V{pkD}_u$ and $\V{pkCoin}_0$ depends on

     the instantiation.

-

+%

     If $\V{pkCoin}_0$ is being overspent, the refresh operation is not recorded

     in $\V{refreshed}[\V{pkCoin}_0]$, the exchange sends the customer the

     protocol transcript of the previous deposits and refreshes and aborts the

     protocol.

-

+%

     If the customer \prt{C} plays honestly in \algo{RefreshRequest} and

     \V{RefreshPickup}, the unlinkable coin $\V{coin}_i$ they obtain as change

     will be stored in their wallet $\V{wallet}[\V{pkCustomer}]$.  If \prt{C} is

     caught playing dishonestly, the \algo{RefreshPickup} protocol aborts.

-

+%

     An honest customer must be able to repeat a \algo{RefreshPickup} with the

     same $\V{rid}$ multiple times and (re-)obtain the same coin, even if

     previous $\algo{RefreshPickup}$ executions were aborted.

-

+%

     Returns a protocol transcript $\mathcal{T}_{RP}$.

 

   \item $\algo{Link}(\prt{E}(\V{sksE}), \prt{C}(\V{skCustomer}, \V{pksE}, \V{coin}_0)) \rightarrow (\mathcal{T}, (\V{coin}_1, \dots, \V{coin}_n))$: