diff options
Diffstat (limited to 'taler/design.tex')
| -rw-r--r-- | taler/design.tex | 70 |
1 files changed, 36 insertions, 34 deletions
diff --git a/taler/design.tex b/taler/design.tex index 4350dfe..c715e70 100644 --- a/taler/design.tex +++ b/taler/design.tex @@ -115,7 +115,7 @@ system% simpler technical means such as keeping balances on tamper-proof smart cards, and thus can lead to an overall more complex system. }. We assume the contact information of the exchange is known to -both customer and merchant from the start, including that the customer +both customer and merchant from the start, and the customer can authenticate the merchant, for example by using X.509 certificates~\cite{rfc6818}. A GNU Taler merchant is expected to deliver the service or goods to the customer upon receiving payment. The @@ -164,17 +164,17 @@ reserve creation. The exchange chosen by the customer must support the wire transfer method used by the bank, which will be automatically checked by the wallet. Typically, an exchange is already selected by default, as banks can suggest a default exchange provider to the wallet, and additionally wallets -have a pre-defined list of trusted exchange providers. Subsequently the wallet +have a pre-defined list of trusted exchange providers. Subsequently, the wallet hands the reserve public key and the bank account information of the selected exchange back to the bank. The bank---typically after asking for a second authentication factor from the customer---will then trigger a wire transfer to the exchange with the information obtained from the wallet. When the customer's bank does not offer tight integration with GNU Taler, the -customer can still manually instruct their wallet create a reserve. The public +customer can still manually instruct their wallet to create a reserve. The public key must then be included in a bank transaction to the exchange. When the -customer's banking app supports pre-filling wire transfer details from URLs or -QR code, the wallet can generate such a URL or QR code that includes the +customer's banking app supports pre-filling wire transfer details from a URL or +a QR code, the wallet can generate such a URL or QR code that includes the pre-filled bank account details of the exchange as well as the reserve public key. The customer clicks on this link or scans the QR code to invoke their banking app with pre-filled transaction details. Since there currently is no @@ -303,7 +303,7 @@ over the funds. A useful application for sharing are peer-to-peer payments between mutually trusting parties, such as families and friends. \subsection{Aggregation} -For each payment, the merchant can specify a deadline after which the exchange +For each payment, the merchant can specify a deadline before which the exchange must issue a wire transfer to the merchant's bank account. Before this deadline occurs, multiple payments from deposited coins to the same merchant can be \emph{aggregated} into one bigger payment. This reduces transaction @@ -338,13 +338,13 @@ is willing to cover. Fees exceeding this amount must be explicitly paid by the customer. Another consideration for fees is the prevention of denial-of-service attacks. -To prevent ``useless'' operations, such as repeated refreshing on coins -(causing the exchange to use relatively expensive storage) unattractive to an +To make ``useless'' operations, such as repeated refreshing on coins +(causing the exchange to use relatively expensive storage), unattractive to an adversary, these operations must charge a fee. Again, for every refresh following a payment, the merchant can cover the costs up to a limit set by the merchant, effectively hiding the fees from the customer. -Yet another type of fees are the \emph{wire transfer fees}, which are charged +Yet another type of fee are the \emph{wire transfer fees}, which are charged by the exchange for every wire transfer to a merchant in order to compensate for the cost of making a transaction in the underlying bank system. The wire transfer fees encourage merchants to choose longer aggregation periods, as the @@ -391,7 +391,7 @@ before the customer is allowed to withdraw again. However since the withdraw loophole allows only one additional ``payment'' (without any cryptographic evidence that can be used in disputes) before the coin must be deposited, -these additional mitigations might not even justified considering their additional cost. +these additional mitigations might not even be justified considering their additional cost. \section{Auditing} @@ -440,7 +440,7 @@ coin. If a denomination key has been revoked, the wallets use the \emph{payback} protocol to recover funds from coins of revoked denominations. Once a denomination is revoked, new coins of this denomination can't be withdrawn or used as the target denomination for a refresh operation. A revoked -coin cannot be spend, and can only be refreshed if its public key was recorded +coin cannot be spent, and can only be refreshed if its public key was recorded in the exchange's database (as spending/refresh operations) before it was revoked. @@ -466,7 +466,7 @@ The following cases are possible for payback: These rules limit the maximum financial damage that the exchange can incur from a compromised denomination key $D$ to $2nv$, with $n$ being the -maximum amount of $D$-coins simultaneously in circulation and $v$ the financial +maximum number of $D$-coins simultaneously in circulation and $v$ the financial value of a single $D$-coin. Say denomination $D$ was withdrawn by legitimate users $n$ times. As soon as the exchange sees more than $n$ pairwise different $D$-coins, it must immediately @@ -475,15 +475,16 @@ refreshing into other non-revoked denominations or spending the forged $D$-coins The legitimate users can then request a payback for their coins, resulting in a total financial damage of at most $2nv$. -The payback protocol preserves anonymity except in one special situation. -Specifically in case (1), the coin obtained from the credited reserve is -blindly singed, in case (2) the refresh protocol guarantees unlinkability of -the non-revoked change, and in case (3) the revoked coin $C_R$ is assumed to be -fresh. If $C_R$ from case (3) has been seen by a merchant before in an -aborted/unfinished transaction, this transaction would be linkable to -transactions on $C_A$. Thus, anonymity is not preserved when an aborted -transaction coincides with revoked denomination, which should be rare in -practice. +With one rare exception, the payback protocol does not negatively impact the +anonymity of customers. We show this by looking at the three different cases +for payback on a revoked coin. Specifically, in case (1), the coin obtained +from the credited reserve is blindly signed, in case (2) the refresh protocol +guarantees unlinkability of the non-revoked change, and in case (3) the revoked +coin $C_R$ is assumed to be fresh. If $C_R$ from case (3) has been seen by a +merchant before in an aborted/unfinished transaction, this transaction would be +linkable to transactions on $C_A$. Thus, anonymity is not preserved when an +aborted transaction coincides with revoked denomination, which should be rare +in practice. Unlike most other operations, the payback protocol does not incur any transaction fees. The primary use of the @@ -579,7 +580,7 @@ probabilistic deposit auditing, and honest merchants have proper incentives to participate in the process. \subsubsection{Compromise of the Database} -If an adversary would be abe to modify the exchange, this would be detected +If an adversary would be able to modify the exchange, this would be detected rather quickly by the auditor, provided that the database has appropriate integrity mechanisms. An attacker could also prevent database updates to block the recording of spend operations, and then double spend. This is effectively @@ -687,10 +688,10 @@ double-spending at the finest granularity. Thus, highly divisible coins incur large storage and computational costs for the exchange. An e-cash system with multiple denominations with different financial values -was proposed by Canard \cite{canard2006handy} in the context of a divisible +was proposed by Canard and Gouget~\cite{canard2006handy} in the context of a divisible coupon system. -On of the earliest mentions of an explicit change protocol can be found in +One of the earliest mentions of an explicit change protocol can be found in \cite{brickell1995trustee}. Ian Goldberg's HINDE system is another design that allows the merchant to provide change, but the mechanism could be abused to hide income from taxation.\footnote{Description based on personal @@ -926,7 +927,8 @@ GNU Taler \subsection{Blockchains} The term ``blockchain'' refers to a wide variety of protocols and systems concerned with maintaining a ledger---typically involving financial transactions---in a -distributed and decentralized manner. +distributed and decentralized manner.\footnote{Even though there is a centralization tendency +from various sources in practice \cite{walch2019deconstructing}.} The first and most prominent system that would be categorized as a ``blockchain'' today\footnote{The paper that introduces Bitcoin does not @@ -963,7 +965,7 @@ Some of the most important decisions for the design of blockchains are the follo that the hash $H(n \Vert c)$ ends with a certain number of zeroes (as determined by the difficulty derived from previous blocks). Under the random oracle, the only way to find such a nonce is by trial-and-error. - This nonce proves to a verifier that the creator of the block spend + This nonce proves to a verifier that the creator of the block spent computational resources to construct it, and the correctness is easily verified by computing $H(n \Vert c)$. The creator of a block is rewarded with a mining reward and transaction fees for transactions within the @@ -1024,7 +1026,7 @@ Some of the most important decisions for the design of blockchains are the follo inflation, and a basic income mechanism for participants. \item Expressivity of transactions. Transactions in Bitcoin are small programs - in a stack-based programming languages that are guaranteed to terminate. + in a stack-based programming language that are guaranteed to terminate. Ethereum \cite{wood2014ethereum} takes this idea further and allows smart contracts with Turing-complete computation and access to external oracles. @@ -1041,7 +1043,7 @@ Some of the most important decisions for the design of blockchains are the follo find a ``meta-consensus'' on the rules that govern such systems, and how these rules can be adapted and changed in a consensus process. - \item Anonymity and Zero Knowledge Proofs. Bitcoin transactions are only + \item Anonymity and Zero-Knowledge Proofs. Bitcoin transactions are only pseudoymous, the full transaction history is publicly available and leads to reduced anonymity in practice \cite{reid2013analysis}. Tumblers \cite{bonneau2014mixcoin,heilman2017tumblebit} are an approach to increase @@ -1114,7 +1116,7 @@ final receiver can only receive a payment on a payment channel if it correctly forwards it to the next node. Experimental deployments of the Lightning network recently suffered heavily -from denial of service attacks. % FIXME: citation needed! +from denial-of-service attacks. % FIXME: citation needed! BOLT \cite{green2016bolt} is an anonymous payment channel for ZeroCash, and is intended to be used as a building block for a second-layer payment protocol @@ -1136,7 +1138,7 @@ side-chain according to the side-chain's rules. At the time of writing, Plasma is not yet implemented. Potential problems with Plasma include the high costs of exits, lack of access to data needed to verify -exit claims, and associated potential for denial of service attacks. +exit claims, and associated potential for denial-of-service attacks. %\subsection{Other Payment Systems} @@ -1176,7 +1178,7 @@ the customer lock-in. \subsection{Web Integration} -Finally, we will discuss software solutions to Web payments. We +Finally, we will discuss software solutions to web payments. We consider other types of payments, including general payments and in particular hardware solutions as out of scope for this thesis. @@ -1199,10 +1201,10 @@ payment system handlers. In order to integrate Taler as a payment method, browsers would need to either offer Taler as a native, built-in payment method or allow an extension to -register Web payment handlers. +register web payment handlers. -The Web Payments working group discontinued work on a HTTP-based API for +The Web Payments Working Group discontinued work on a HTTP-based API for machine-to-machine payments.\footnote{See \url{https://www.w3.org/TR/webpayments-http-api/}.} @@ -1256,7 +1258,7 @@ online shopping~\cite[p. 50]{ibi2014}. \subsubsection{Other Proprietary Payment APIs} The Electronic Payment Standard URI scheme \texttt{epspayment:} is a proprietary/unregistered URI scheme used by predominantly Austrian banks and -merchants to trigger payments from within Websites on mobile devices. +merchants to trigger payments from within websites on mobile devices. Merchants can register an invoice with a central server. The user's banking app is associated with the \texttt{epspayment} URI scheme and will open to settle the invoice. It lies conceptually between \texttt{payto://} and |