diff options
Diffstat (limited to 'doc/paper/taler.tex')
| -rw-r--r-- | doc/paper/taler.tex | 74 |
1 files changed, 43 insertions, 31 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 20193f5cb..19b1b19f5 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -118,7 +118,7 @@ activity, and this limits the ability of the state to shape the society. As bribery is virtually impossible to detect, corruption is widespread and not limited to social elites. % -Zerocoin~\cite{miers2013zerocoin} is an example for translating an +Zerocash~\cite{zerocash} is an example for translating an anarchistic economy into the digital realm. This paper describes Taler, a simple and practical payment system for @@ -188,7 +188,7 @@ in this class is Bitcoin~\cite{nakamoto2008bitcoin}. An initial concern with Bitcoin was the lack of anonymity, as all Bitcoin transactions are recorded for eternity, which can enable identification of users. In theory, this concern has been addressed -with the Zerocoin extension to the protocol~\cite{miers2013zerocoin}. +in the alternatve Zerocash protocol~\cite{zerocash}. The key contribution of blockchain-based protocols is that they dispense with the need for a central, trusted @@ -201,7 +201,7 @@ Yet, there are several major irredeemable problems inherent in their designs: So Bitcoin is an environmentally irresponsible design. \item Bitcoin transactions have pseduononymous recipients, making taxation hard to systematically enforce. - The Zerocoin extension makes this worse. + The Zerocash extension makes this worse. \item Bitcoin introduces a new currency, creating additional financial risks from currency fluctuation. \item Anyone can start an alternative Bitcoin transaction chain, @@ -216,13 +216,14 @@ Yet, there are several major irredeemable problems inherent in their designs: % currency exchange and exacerbates the problems with currency fluctuations. \end{itemize} -Anonymity extensions for BitCoin such as Zerocoin~\cite{miers2013zerocoin} -and BOLT~\cite{BOLT} are also limited to transactions with coins -of fixed discrete value, creating problems with giving change we -outlined in the introduction. Furthermore, these extensions have -problems with aborted transactions, which can reduce the anonymity -set. Taler's refresh protocol also addresses the problem of aborted -transactions, ensuring that aborts cannot be used to attack the +Anonymous alternatives to BitCoin such as Monero~\cite{??}, +Zerocash~\cite{zerocash}, its predecessor Zerocoin~\cite{miers2013zerocoin}, +and the recently proposed BOLT~\cite{BOLT} each have different technical +limitations. Yet, all exacerbate BitCoin's inherent issues with +transaction certenty and performance by require excessive +computation, more blockchain transactions, etc. By comparison, +Taler's refresh protocol handles aborted transactions with minimal +overhead, and ensures that aborts cannot be used to attack the privacy assurances of the system. %GreenCoinX\footnote{\url{https://www.greencoinx.com/}} is a more @@ -276,26 +277,29 @@ Chaum's original digital cash system~\cite{chaum1983blind} was extended by Brands~\cite{brands1993efficient} with the ability to {\em divide} coins and thus spend certain fractions of a coin using restrictive blind signatures. Restrictive blind signatures create -privacy risks: if a transaction is interrupted, then any coins sent to -the merchant become tainted, but may never arrive or be spent. It -becomes tricky to extract the value of the tainted coins without +privacy risks: if a transaction is interrupted, then any coins sent +to the merchant become tainted, but may never arrive or be spent. +It becomes tricky to extract the value of the tainted coins without linking to the aborted transaction and risking deanonymization. Ian Goldberg's HINDE system allowed the merchant to provide change, but the mechanism could be abused to hide income from taxation.\footnote{Description based on personal communication. HINDE - was never published.} $k$-show -signatures~\cite{brands1993efficient} were proposed to achieve -divisibility for coins. However, with $k$-show signatures multiple -transactions can be linked to each other. Performing fractional -payments using $k$-show signatures is also rather expensive. + was never published.} +In \cite{brands1993efficient}, $k$-show signatures were proposed to +achieve divisibility for coins. However, with $k$-show signatures +multiple transactions can be linked to each other. +Performing fractional payments using $k$-show signatures is also +rather expensive. + +% For longer non-conference version : +% -Add note on Carmenisch's compact e-cash withdrawals \cite{Camenisch05compacte-cash} +% -Add note on Merkle tree based scheme that inspired Zerocash -% %Some argue that the focus on technically perfect but overwhelmingly %complex protocols, as well as the the lack of usable, practical %solutions lead to an abandonment of these ideas by %practitioners~\cite{selby2004analyzing}. -% % FIXME: ask OpenCoin dev's about this! Then make statement firmer! To our knowledge, the only publicly available effort to implement @@ -395,11 +399,15 @@ who is performing the authentication to authorize the withdrawal. Preventing the owner of the reserve from deliberately authorizing someone else to withdraw electronic coins would require extreme measures, including preventing them from communicating with anyone but -the exchange terminal during withdrawal. As such measures would be +the exchange terminal during withdrawal. +% FIXME: Oddly phrased: + As such measures would be totally impractical for a minor loophole, we are not concerned with enabling the state to strongly identify the recipient of coins from a withdrawal operation. +% FIXME: Seems to kinda duplicate the previous paragraph, albeit doing +% a better job. We view ownership of a coin's private key as a ``capability'' to spend the funds. A taxable transaction occurs when a merchant entity gains control over the funds while at the same time a customer entity looses @@ -438,7 +446,9 @@ as well as for refreshing tainted coins with the exchange and for retrieving the exchange's denomination key. Ideally, the customer's anonymity is limited only by this channel; however, the payment system does additionally reveal that the customer -is one of the patrons of the exchange. +is one of the patrons of the exchange who withdrew enough coin of +given denominations. +% FIXME: What does customer-merchant business operation mean? There are naturally risks that the customer-merchant business operation may leak identifying information about the customer. We consider information leakage specific to the business logic to be @@ -486,10 +496,10 @@ exposes these events as anchors for tax audits on income. A \emph{coin} in Taler is a public-private key pair where the private key is only known to the owner of the coin. A coin derives its -financial value from an RSA signature over the FDH -of the coin's public key. The exchange has multiple RSA {\em - denomination key} pairs available for blind-signing coins of -different value. +financial value from an RSA signature over the full doman hash (FDH) +of the coin's public key. The exchange has multiple RSA +{\em denomination key} pairs available for blind-signing coins of +different values. Denomination keys have an expiration date, before which any coins signed with it must be spent or refreshed. This allows the exchange @@ -667,7 +677,7 @@ Now the customer carries out the following interaction with the exchange: The exchange receives the transaction and credits the reserve $W_p$ with the respective amount in its database. \item[POST {\tt /withdraw/sign}] - The customer sends $S_W(B)$ where $B := B_b(\FDH_K(C_p))$ to + The customer computes $B := B_b(\FDH_K(C_p))$ and sends $S_W(B)$ to the exchange to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with blinding factor $b$. \item[200 OK / 403 FORBIDDEN] @@ -688,8 +698,8 @@ Now the customer carries out the following interaction with the exchange: error back to the customer, with proof that it operated correctly. Assuming the signature was valid, this would involve showing the transaction history for the reserve. - \item[Done] The customer computes and verifies the unblinded signature - $S_K(\FDH_K(C_p)) = U_b(S_K(B))$. + \item[Done] The customer computes the unblinded signature $U_b(S_K(B))$ and + verifies that $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$ to their local wallet on disk. \end{description} @@ -719,7 +729,7 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$ exchanges accepted by the merchant where each $X_j$ is a exchange's public key. \item[Proposal] - The merchant creates a digitally signed contract + The merchant creates a signed contract $\mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})$ where $m$ is an identifier for this transaction, $f$ is the price of the offer, and $a$ is data relevant @@ -1081,7 +1091,9 @@ perfectly balanced in between frontend and backend. Nevertheless, these experimental results show that computing-related business costs will only marginally contribute to the operational costs of the Taler payment system. - +% FIXME: Say that storage costs dominated? Are storage costs comparable +% for a self hosted system? Didn't we reduce the storage costs with the +% key generation trick? \section{Discussion} |