[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [taler-exchange] branch master updated (4492821 -> 02a3f3d)
From: |
gnunet |
Subject: |
[GNUnet-SVN] [taler-exchange] branch master updated (4492821 -> 02a3f3d) |
Date: |
Thu, 18 May 2017 00:01:06 +0200 |
This is an automated email from the git hooks/post-receive script.
burdges pushed a change to branch master
in repository exchange.
from 4492821 Spelling
new 4689610 Minor edits to implementation section
new 02a3f3d Make double pending Exculpability section about prevention
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
doc/paper/taler.tex | 61 ++++++++++++++++++++++++++++-------------------------
1 file changed, 32 insertions(+), 29 deletions(-)
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 58a1c4a..a2b9680 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -1407,7 +1407,7 @@ protocol is never used.
\subsection{Exculpability arguments}
\begin{lemma}\label{lemma:double-spending}
-The exchange can detect and prove double-spending.
+The exchange can detect, prevent, and prove double-spending.
\end{lemma}
\begin{proof}
@@ -1417,13 +1417,15 @@ obtains either a deposit-permission or a
refresh-record, both of which
contain a signature made with the public key of coin to authorizing the
respective operation. If the exchange has a set of refresh-records and
deposit-permissions whose total value exceed the value of the coin, the
-exchange can show this set to prove that double-spending was attempted.
+exchange can show this set to prove that double-spending is being
+attempted and justify rejecting the operation.
\end{proof}
\begin{corollary}
-Merchants and customers can verify double-spending proofs by verifying that the
-signatures in the set of refresh-records and deposit-permissions are correct
and
-that the total value exceeds the coin's value.
+Merchants and customers can verify proofs of double-spending attempts
+by verifying that the signatures in the set of refresh-records and
+deposit-permissions are correct and that the total value would exceed
+the coin's value.
\end{corollary}
\begin{lemma}
@@ -1474,38 +1476,39 @@ customer owns, only the original customer can use the
increased balance.
\section{Implementation}
-We implemented the Taler protocol in the context of a payment system for the
-Web, as shown in Figure~\ref{fig:taler-arch}. The system was 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
-(non-anonymous) balance, called a \emph{reserve}, at the exchange. The
-customer can subsequently withdraw coins from this \emph{reserve} into their
-\emph{wallet}, which stores and manages coins.
-
-
-Upon withdrawal of coins from the exchange, the user authenticates themselves
-using an Ed25519 private key, where the corresponding public key needs to be
-included in the payment instruction from the customer's bank to the exchange's
-bank. With a bank that directly supports Taler on their online banking
website,
-this process is streamlined for the user, since the wallet automatically
-creates the key pair for the reserve and adds the public key to the
-payment instruction.
+We implemented the Taler protocol in the context of a payment system
+for the Web, as shown in Figure~\ref{fig:taler-arch}. The system was
+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 (non-anonymous) balance, called a \emph{reserve}, at the
+exchange. The customer can subsequently withdraw coins from this
+reserve into their \emph{wallet}, which stores and manages coins.
+
+To withdrawal of coins from the exchange, the customer's wallet authenticates
+itself using an Ed25519 private key for the customer's reserve.
+The customer must include the corresponding reserve public key in the
+payment instruction from the customer's bank to the exchange's bank
+that funded their reserve. With a bank that directly supports Taler
+on their online banking website, this process is streamlined for the
+user, since the wallet automatically creates the key pair for the
+reserve and adds the public key to the payment instruction.
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
or reject this proposal. The merchant deposits coins received from
the customer's wallet at the exchange. Since bank transfers are
usually costly, the exchange delays and aggregates multiple deposits
-into a bigger wire transfer. This allows our system to be used even
-for microtransactions of amounts smaller than usually handled by the
+into a bigger wire transfer. This allows Taler to be used even for
+microtransactions of amounts smaller than usually handled by the
underlying banking system.
-As shown in Figure~\ref{fig:taler-arch}, the merchant is internally split into
-multiple components. The implementation of the Taler prococol and
-cryptographic operations is isolated into a separate component (called the
-\emph{merchant backend}), which the merchant accesses through an API or
software
-development kit (SDK) of their choice.
+As shown in Figure~\ref{fig:taler-arch}, the merchant is internally split
+into multiple components. The implementation of the Taler prococol and
+cryptographic operations is isolated into a separate component, called
+the \emph{merchant backend}, which the merchant accesses through an API
+or software development kit (SDK) of their choice.
Our implementations of the exchange (70,000 LOC) and merchant backend
(20,000 LOC) are written in C using PostgreSQL as the database and
--
To stop receiving notification emails like this one, please contact
address@hidden
- [GNUnet-SVN] [taler-exchange] branch master updated (4492821 -> 02a3f3d),
gnunet <=