Merge branch 'master' of ssh://taler.net/exchange
This commit is contained in:
commit
09cd669283
@ -871,7 +871,9 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
|
|||||||
public key.
|
public key.
|
||||||
\item
|
\item
|
||||||
The merchant creates a signed contract
|
The merchant creates a signed contract
|
||||||
$\mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})$
|
\begin{equation*}
|
||||||
|
\mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})
|
||||||
|
\end{equation*}
|
||||||
where $m$ is an identifier for this transaction, $f$ is the price of the offer,
|
where $m$ is an identifier for this transaction, $f$ is the price of the offer,
|
||||||
and $a$ is data relevant
|
and $a$ is data relevant
|
||||||
to the contract indicating which services or goods the merchant will
|
to the contract indicating which services or goods the merchant will
|
||||||
@ -1011,9 +1013,12 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
|
|||||||
for $i \in \{1,\ldots,\kappa\}$ and sends a signed commitment
|
for $i \in \{1,\ldots,\kappa\}$ and sends a signed commitment
|
||||||
$S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
|
$S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
|
||||||
\item % [200 OK / 409 CONFLICT]
|
\item % [200 OK / 409 CONFLICT]
|
||||||
The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
|
The exchange checks that $C'_p$ is a valid coin of sufficient balance
|
||||||
marks $C'_p$ as spent by persisting
|
to cover the value of the fresh coins to be generated and prevent
|
||||||
$\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$.
|
double-spending. Then,
|
||||||
|
the exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
|
||||||
|
marks $C'_p$ as spent by persisting the \emph{refresh-record}
|
||||||
|
$\mathcal{F} = \langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$.
|
||||||
Auditing processes should assure that $\gamma$ is unpredictable until
|
Auditing processes should assure that $\gamma$ is unpredictable until
|
||||||
this time to prevent the exchange from assisting tax evasion. \\
|
this time to prevent the exchange from assisting tax evasion. \\
|
||||||
%
|
%
|
||||||
@ -1372,47 +1377,67 @@ protocol is never used.
|
|||||||
|
|
||||||
\subsection{Exculpability arguments}
|
\subsection{Exculpability arguments}
|
||||||
|
|
||||||
\begin{lemma}
|
\begin{lemma}\label{lemma:double-spending}
|
||||||
The exchange can detect and prove double-spending.
|
The exchange can detect and prove double-spending.
|
||||||
\end{lemma}
|
\end{lemma}
|
||||||
|
|
||||||
\begin{proof}
|
\begin{proof}
|
||||||
|
A coin can only be spent by running the deposit protocol or the refresh
|
||||||
|
protocol with the exchange. Thus every time a coin is spent, the exchange
|
||||||
|
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 a coin was double-spend.
|
||||||
\end{proof}
|
\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.
|
||||||
|
\end{corollary}
|
||||||
|
|
||||||
\begin{lemma}
|
\begin{lemma}
|
||||||
Merchants and customers can verify double-spending proofs.
|
% only holds given sufficient time
|
||||||
|
Customers can either obtain proof-of-payment or their money back, even
|
||||||
|
when the merchant is faulty.
|
||||||
\end{lemma}
|
\end{lemma}
|
||||||
|
|
||||||
\begin{proof}
|
\begin{proof}
|
||||||
|
When the customer sends the deposit-permission for a coin
|
||||||
|
to a correct merchant, the merchant will pass it on to the
|
||||||
|
exchange, and pass the exchange's response, a deposit-confirmation, on
|
||||||
|
to the customer. If a faulty merchant deposits the coin
|
||||||
|
but does not pass the deposit-confirmation to the customer,
|
||||||
|
the customer will receive the deposit-confirmation as an error
|
||||||
|
response from the refreshing protocol. Otherwise if the merchant
|
||||||
|
doesn't deposit the coin, the customer can get a new, unlinkable
|
||||||
|
coin by running the refresh protocol.
|
||||||
\end{proof}
|
\end{proof}
|
||||||
|
|
||||||
|
\begin{corollary}
|
||||||
\begin{lemma}
|
If a customer paid for a contract, they can prove it by showing
|
||||||
Customers can either obtain proof-of-payment or their money back.
|
the deposit permissions for all coins.
|
||||||
\end{lemma}
|
\end{corollary}
|
||||||
|
|
||||||
\begin{proof}
|
|
||||||
\end{proof}
|
|
||||||
|
|
||||||
\begin{lemma}
|
|
||||||
If a customer paid for a contract, they can prove it.
|
|
||||||
\end{lemma}
|
|
||||||
|
|
||||||
\begin{proof}
|
|
||||||
\end{proof}
|
|
||||||
|
|
||||||
\begin{lemma}
|
\begin{lemma}
|
||||||
The merchant can issue refunds, and only to the original customer.
|
The merchant can issue refunds, and only to the original customer.
|
||||||
\end{lemma}
|
\end{lemma}
|
||||||
|
|
||||||
\begin{proof}
|
\begin{proof}
|
||||||
|
Since the refund only increases the balance of a coin that the original
|
||||||
|
customer owns, only the original customer can spend the refunded coin again.
|
||||||
\end{proof}
|
\end{proof}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\begin{theorem}
|
\begin{theorem}
|
||||||
The protocol prevents double-spending and provides exculpability.
|
The protocol prevents double-spending and provides exculpability.
|
||||||
\end{theorem}
|
\end{theorem}
|
||||||
|
\begin{proof}
|
||||||
|
Follows from Lemma \ref{lemma:double-spending} and the assumption
|
||||||
|
that the exchange can't forge signatures to obtain an incriminating
|
||||||
|
set of deposit-permissions and/or refresh-records.
|
||||||
|
\end{proof}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -1580,6 +1605,24 @@ upholds the core principles described in~\cite{fc2014murdoch}. In
|
|||||||
particular, in providing the cryptographic proofs as evidence none of
|
particular, in providing the cryptographic proofs as evidence none of
|
||||||
the participants have to disclose their core secrets.
|
the participants have to disclose their core secrets.
|
||||||
|
|
||||||
|
\subsection{Business concerns}
|
||||||
|
|
||||||
|
The Taler system implementation includes additional protocol elements
|
||||||
|
to address real-world concerns. To begin with, the exchange
|
||||||
|
automatically transfers any funds that have been left for an extended
|
||||||
|
amount of time in a customer's reserve back to the customer's bank
|
||||||
|
account. Furthermore, we allow the exchange to revoke denomination
|
||||||
|
keys, and wallets periodically check for such revocations. If a
|
||||||
|
denomination key has been revoked, the wallets use the {\em payback}
|
||||||
|
protocol to deposit funds back to the customer's reserve, from where
|
||||||
|
they are either withdrawn with a new denomination key or sent back to
|
||||||
|
the customer's bank account. Unlike ordinary deposits, the payback
|
||||||
|
protocol does not incur any transaction fees. The primary use of the
|
||||||
|
protocol is to limit the financial loss in cases where an audit
|
||||||
|
reveals that the exchange's private keys were compromised, and to
|
||||||
|
automatically pay back balances held in a customers' wallet if an
|
||||||
|
exchange ever goes out of business.
|
||||||
|
|
||||||
|
|
||||||
%\subsection{System Performance}
|
%\subsection{System Performance}
|
||||||
%
|
%
|
||||||
@ -1798,7 +1841,10 @@ coin first.
|
|||||||
the exchange persists $\langle \mathcal{L} \rangle$
|
the exchange persists $\langle \mathcal{L} \rangle$
|
||||||
and notifies the merchant that locking was successful.
|
and notifies the merchant that locking was successful.
|
||||||
\item\label{contract2} The merchant creates a digitally signed contract
|
\item\label{contract2} The merchant creates a digitally signed contract
|
||||||
$\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract
|
\begin{equation*}
|
||||||
|
\mathcal{A} := S_M(m, f, a, H(p, r))
|
||||||
|
\end{equation*}
|
||||||
|
where $a$ is data relevant to the contract
|
||||||
indicating which services or goods the merchant will deliver to the customer, and $p$ is the
|
indicating which services or goods the merchant will deliver to the customer, and $p$ is the
|
||||||
merchant's payment information (e.g. his IBAN number) and $r$ is an random nonce.
|
merchant's payment information (e.g. his IBAN number) and $r$ is an random nonce.
|
||||||
The merchant persists $\langle \mathcal{A} \rangle$ and sends it to the customer.
|
The merchant persists $\langle \mathcal{A} \rangle$ and sends it to the customer.
|
||||||
|
Loading…
Reference in New Issue
Block a user