diff options
Diffstat (limited to 'doc/paper')
| -rw-r--r-- | doc/paper/taler.tex | 188 |
1 files changed, 100 insertions, 88 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 706cf70f3..a728471c0 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -18,9 +18,9 @@ % 'transaction' already when we talk about taxable % transfers of Taler coins and database 'transactions'. % - wallet = coins at customer -% - reserve = currency entrusted to mint waiting for withdrawl +% - reserve = currency entrusted to mint waiting for withdrawal % - deposit = SEPA to mint -% - withdrawl = mint to customer +% - withdrawal = mint to customer % - spending = customer to merchant % - redeeming = merchant to mint (and then mint SEPA to merchant) % - refreshing = customer-mint-customer @@ -403,11 +403,11 @@ information leakage is outside of the scope of this work. The customer may use an anonymous communication channel for the communication with the mint to avoid leaking IP address information; however, the mint will anyway be able to determine the customer's -identity from the (SEPA) transfer that the customer initiates to -obtain anonymous digital cash. The scheme is anonymous -because the mint will be unable to link the known identity of the -customer that withdrew anonymous digital currency to the {\em - purchase} performed later at the merchant. +identity from the wire transfer or some other authentication process +that the customer initiates to withdraw anonymous digital cash. The +scheme is anonymous because the mint will be unable to link the known +identity of the customer that withdrew anonymous digital currency to +the {\em purchase} performed later at the merchant. % All the mint will be %able to confirm is that the customer is {\em one} of its patrons who %previously obtained the anonymous digital currency --- and of course @@ -466,17 +466,22 @@ private {\em master signing key} of the mint and possibly the auditor. Before a customer can withdraw a coin from the mint, he has to pay the mint the value of the coin, as well as processing fees. This is done -using other means of payments, such as SEPA transfers~\cite{sepa}. -The subject line of the transfer must contain {\em withdrawal - authorization key}, a public key for digital signatures generated by -the customer. When the mint receives a transfer with a public key in -the subject, it adds the funds to a {\em reserve} identified by the -withdrawl authorization key. By signing the withdrawl messages using -the withdrawl authorization key, the customer can prove to the mint -that he is authorized to withdraw anonymous digital coins from the -reserve. The mint will record the withdrawl messages with the reserve -record as proof that the anonymous digital coin was created for the -correct customer. +using other means of payments, such as wire transfers~\cite{sepa} or +by having a personal {\em reserve} at the mint (which is equivalent to +a bank account with a positive balance). Taler assumes that the +customer has a {\em withdrawal authorization key} to identify himself +as authorized to withdraw funds from the reserved. By signing the +withdrawal request messages using the withdrawal authorization key, +the customer can prove to the mint that he is the individual +authorized to withdraw anonymous digital coins from the reserve. The +mint will record the withdrawal messages with the reserve record as +proof that the anonymous digital coin was created for the correct +customer. We note that the specifics of how the customer +authenticates to the mint are orthogonal to the rest of the system, +and multiple methods can be supported. To put it differently, unlike +modern cryptocurrencies like BitCoin, Taler's design simply +acknowledges that primitive accumulation~\cite{engels1844} predates +the system and that a secure method to authenticate owners exists. After a coin is minted, the customer is the only entity that knows the private key of the coin, making him the \emph{owner} of the coin. The @@ -495,16 +500,11 @@ private key. A merchant can then transfer this permission of the coin's owner to the mint to obtain the amount in traditional currency. If the customer is cheating and the coin was already spent, the mint provides cryptographic proof of the fraud to the merchant, who will -then refuse the transaction. -% The mint is typically expected -%to transfer the funds to the merchant using a SEPA transfer or similar -%methods appropriate to the domain of the traditional currency. +then refuse the transaction. The mint is typically expected to +transfer the funds to the merchant using a wire transfer or by +crediting the merchant's individual account, depending on what is +appropriate to the domain of the traditional currency. -%The mint needs to ensure that a coin can only be spent once. This is -%done by storing the public keys of all deposited coins (together with -%the deposit request and the owner's signature confirming the -%transaction). The mint's state can be limited as coins signed with -%expired coin sigining keys do not have to be retained. \paragraph{Partial spending.} @@ -514,13 +514,13 @@ spending of coins. Consequently, the mint the must not only store the identifiers of spent coins, but also the fraction of the coin that has been spent. -%\paragraph{Online checks.} -% -%For secure transactions (non-microdonations), the merchant is expected -%to perform an online check to detect double-spending. In the simplest -%case, the merchant simply directly confirms the validity of the -%deposit permission signed by the coin's owner with the mint, and then -%proceeds with the contract. +\paragraph{Online checks.} + +For secure transactions, the merchant is expected to perform an online +check to detect double-spending. Thus, the merchant must deposit the +coin with the mint (and validate the signature from the mint +confirming the validity of the transaction) before proceeding with its +business logic. \subsection{Refreshing Coins} @@ -569,13 +569,14 @@ in relation to the value of the melted coins. % In this section, we describe the protocols for Taler in detail. -For the sake of brevity, we do not specifically state that the -recipient of a signed message always first checks that the signature -is valid. Also, whenever a signed message is transmitted, it is -assumed that the receiver is told the public key (or knows it from the -context) and that the signature contains additional identification as -to the purpose of the signature (such that it is not possible to -use a signature from one protocol step in a different context). +For the sake of brevity, we assume that a recipient of a signed +message always first checks that the signature is valid, even though +this is not explicitly stated below. Also, whenever a signed message +is transmitted, it is assumed that the receiver is told the public key +(or knows it from the context) and that the signature contains +additional identification as to the purpose of the signature (such +that it is not possible to use a signature from one protocol step in a +different context). When the mint signs messages (not coins), an {\em online message signing key} of the mint is used. The mint's long-term offline key @@ -584,7 +585,7 @@ message signing key of the mint. The mint's long-term offline key is assumed to be well-known to both customers and merchants, for example because it is certified by the auditors. -As we are dealing with financial transactions, we explicitly state +As we are dealing with financial transactions, we explicitly describe whenever entities need to safely commit data to persistent storage. As long as those commitments persist, the protocol can be safely resumed at any step. Commitments to disk are cummulative, that is an @@ -665,7 +666,7 @@ $\widetilde{C} := S_K(C_p)$: 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)$ + 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 gives $(\mathcal{D}, p, r)$ to the mint, revealing his @@ -722,7 +723,7 @@ execute the coin refreshing protocol with the mint. %\end{figure} -\subsection{Refreshing} +\subsection{Refreshing} \label{sec: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 @@ -784,40 +785,48 @@ This allows the owner of the old coin to also obtain the private key of the new coin, even if the refreshing protocol was illicitly executed by another party who learned $C'_s$ from the old owner. +\subsection{Refunds} + +The refresh protocol offers an easy way to enable refunds to +customers, even if they are anonymous. Refunds can be supported +by including a public signing key of the mechant in the transaction +details, and having the customer keep the private key of the spent +coins on file. + +Given this, the merchant can simply sign a {\em refund confirmation} +and share it with the mint (and the customer). Assuming the mint has +a way to recover the funds from the merchant (or simply not performed +the wire transfer yet), the mint can simply add the value of the +refunded transaction back to the original coin, re-enabling those +funds to be spent again by the original customer. + +The (anonymous) customer -- but nobody else -- can then use the +refresh protocol to melt the refunded coin and create a fresh coin +that is unlinkable to the refunded transaction. + \section{Discussion} \subsection{Offline Payments} -Chaum's original proposals for anonymous digital cash avoided the -locking and online spending steps detailed in this proposal by +Chaum's original proposals for anonymous digital cash avoided the need +for online interactions with the mint to detect double spending by providing a means to deanonymize customers involved in double-spending. We believe that this is problematic as the mint or the merchant will then still need out-of-band means to recover funds from the customer, which may be impossible in practice. In contrast, in our design only the mint may try to defraud the other participants -and disappear. While this is still a risk, this is likely manageable, -especially compared to recovering funds via the court system from -customers. - - -\subsection{Bona-fide microdonations} - -Evidently the customer can ``cheat'' by aborting the transaction in -Step 3 of the microdonation protocol if the outcome is unfavourable --- -and repeat until he wins. This is why Taler is suitable for -microdonations --- where the customer voluntarily contributes --- -and not for micropayments. - -Naturally, if the donations requested are small, the incentive to -cheat for minimal gain should be quite low. Payment software could -embrace this fact by providing an appeal to conscience in form of an -option labeled ``I am unethical and want to cheat'', which executes -the dishonest version of the payment protocol. - -If an organization detects that it cannot support itself with -microdonations, it can always choose to switch to the macropayment -system with slightly higher transaction costs to remain in business. +and disappear. While this is still a risk, and regular financial +audits are required to protect against it, this is more manageable and +significantly cheaper compared to recovering funds via the court +system from customers. + +Chaum's method for offline payments would also be incompatible with +the refreshing protocol (Section~\ref{sec:refreshing}) which enables +the crucial feature of giving unlinkable change. The reason is that +if the owner's identity were embedded in coins, it would be leaked to +the mint as part of the reveal operation in the cut-and-choose +operation of the refreshing protocol. \subsection{Merchant Tax Audits} @@ -872,25 +881,12 @@ transactions. In this appendix we detail various optional features that can be added to the basic protocol. -\subsection{Refunds} - -The refresh protocol offers an easy way to enable refunds to -customers, even if they are anonymous. Refunds can be supported -by including a public signing key of the mechant in the transaction -details, and having the customer keep the private key of the spent -coins on file. - -Given this, the merchant can simply sign a {\em refund confirmation} -and share it with the mint (and the customer). Assuming the mint has -a way to recover the funds from the merchant (or simply not performed -the transfer yet), the mint can simply add the value of the refunded -transaction back to the original coin, re-enabling those funds to be -spent again by the original customer. - -The (anonymous) customer -- but nobody else -- can then use the -refresh protocol to melt the refunded coin and create a fresh coin -that is unlinkable to the previous transaction. - +However, we note that Taler's transaction costs are expected to be so +low that these features are not particularly useful, as they are about +reducing interactions with the mint to reduce costs. In particular, +we expect that transactions with amounts below Taler's transaction +costs to be economically meaningless. Nevertheless, we document +various ways how this could be achieved. \subsection{Incremental spending} @@ -1079,7 +1075,7 @@ 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. +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 @@ -1112,4 +1108,20 @@ The following steps are executed for microdonations with upgrade probability $p$ with $H(r_c)$. \end{enumerate} +Evidently the customer can ``cheat'' by aborting the transaction in +Step 3 of the microdonation protocol if the outcome is unfavourable --- +and repeat until he wins. This is why Taler is suitable for +microdonations --- where the customer voluntarily contributes --- +and not for micropayments. + +Naturally, if the donations requested are small, the incentive to +cheat for minimal gain should be quite low. Payment software could +embrace this fact by providing an appeal to conscience in form of an +option labeled ``I am unethical and want to cheat'', which executes +the dishonest version of the payment protocol. + +If an organization detects that it cannot support itself with +microdonations, it can always choose to switch to the macropayment +system with slightly higher transaction costs to remain in business. + \end{document} |