taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Minor edits to implementation section

Browse Source
This commit is contained in:
Jeffrey Burdges 2017-05-17 23:50:41 +02:00
parent 4492821b46
commit 4689610a1f
No known key found for this signature in database
GPG Key ID: ABAC7FD1CC100A74
1 changed files with 23 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
doc/paper/taler.tex
View File

@ -1474,38 +1474,39 @@ customer owns, only the original customer can use the increased balance.
\section{Implementation} \section{Implementation}
We implemented the Taler protocol in the context of a payment system for the We implemented the Taler protocol in the context of a payment system
Web, as shown in Figure~\ref{fig:taler-arch}. The system was designed for real-world usage with for the Web, as shown in Figure~\ref{fig:taler-arch}. The system was
current Web technology and within the existing financial system. designed for real-world usage with current Web technology and within
the existing financial system.
By instructing their bank to send money to an exchange, the customer creates a By instructing their bank to send money to an exchange, the customer
(non-anonymous) balance, called a \emph{reserve}, at the exchange. The creates a (non-anonymous) balance, called a \emph{reserve}, at the
customer can subsequently withdraw coins from this \emph{reserve} into their exchange. The customer can subsequently withdraw coins from this
\emph{wallet}, which stores and manages coins. reserve into their \emph{wallet}, which stores and manages coins.
To withdrawal of coins from the exchange, the customer's wallet authenticates
Upon withdrawal of coins from the exchange, the user authenticates themselves itself using an Ed25519 private key for the customer's reserve.
using an Ed25519 private key, where the corresponding public key needs to be The customer must include the corresponding reserve public key in the
included in the payment instruction from the customer's bank to the exchange's payment instruction from the customer's bank to the exchange's bank
bank. With a bank that directly supports Taler on their online banking website, that funded their reserve. With a bank that directly supports Taler
this process is streamlined for the user, since the wallet automatically on their online banking website, this process is streamlined for the
creates the key pair for the reserve and adds the public key to the user, since the wallet automatically creates the key pair for the
payment instruction. reserve and adds the public key to the payment instruction.
While browsing a merchant's website, the website can signal the wallet While browsing a merchant's website, the website can signal the wallet
to request a payment from a user. The user is then asked to confirm to request a payment from a user. The user is then asked to confirm
or reject this proposal. The merchant deposits coins received from or reject this proposal. The merchant deposits coins received from
the customer's wallet at the exchange. Since bank transfers are the customer's wallet at the exchange. Since bank transfers are
usually costly, the exchange delays and aggregates multiple deposits usually costly, the exchange delays and aggregates multiple deposits
into a bigger wire transfer. This allows our system to be used even into a bigger wire transfer. This allows Taler to be used even for
for microtransactions of amounts smaller than usually handled by the microtransactions of amounts smaller than usually handled by the
underlying banking system. underlying banking system.
As shown in Figure~\ref{fig:taler-arch}, the merchant is internally split into As shown in Figure~\ref{fig:taler-arch}, the merchant is internally split
multiple components. The implementation of the Taler prococol and into multiple components. The implementation of the Taler prococol and
cryptographic operations is isolated into a separate component (called the cryptographic operations is isolated into a separate component, called
\emph{merchant backend}), which the merchant accesses through an API or software the \emph{merchant backend}, which the merchant accesses through an API
development kit (SDK) of their choice. or software development kit (SDK) of their choice.
Our implementations of the exchange (70,000 LOC) and merchant backend Our implementations of the exchange (70,000 LOC) and merchant backend
(20,000 LOC) are written in C using PostgreSQL as the database and (20,000 LOC) are written in C using PostgreSQL as the database and