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

mint->exchange renaming in paper

Browse Source
This commit is contained in:
Christian Grothoff 2016-03-01 15:21:30 +01:00
parent 9f837ad6cd
commit e406833eab
1 changed files with 212 additions and 212 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

398
doc/paper/taler.tex
View File

@ -41,17 +41,17 @@
% 'transaction' already when we talk about taxable % 'transaction' already when we talk about taxable
% transfers of Taler coins and database 'transactions'. % transfers of Taler coins and database 'transactions'.
% - wallet = coins at customer % - wallet = coins at customer
% - reserve = currency entrusted to mint waiting for withdrawal % - reserve = currency entrusted to exchange waiting for withdrawal
% - deposit = SEPA to mint % - deposit = SEPA to exchange
% - withdrawal = mint to customer % - withdrawal = exchange to customer
% - spending = customer to merchant % - spending = customer to merchant
% - redeeming = merchant to mint (and then mint SEPA to merchant) % - redeeming = merchant to exchange (and then exchange SEPA to merchant)
% - refreshing = customer-mint-customer % - refreshing = customer-exchange-customer
% - dirty coin = coin with exposed public key % - dirty coin = coin with exposed public key
% - fresh coin = coin that was refreshed or is new % - fresh coin = coin that was refreshed or is new
% - coin signing key = mint's online key used to (blindly) sign coin % - coin signing key = exchange's online key used to (blindly) sign coin
% - message signing key = mint's online key to sign mint messages % - message signing key = exchange's online key to sign exchange messages
% - mint master key = mint's key used to sign other mint keys % - exchange master key = exchange's key used to sign other exchange keys
% - owner = entity that knows coin private key % - owner = entity that knows coin private key
% - transaction = coin ownership transfer that should be taxed % - transaction = coin ownership transfer that should be taxed
% - sharing = coin copying that should not be taxed % - sharing = coin copying that should not be taxed
@ -74,7 +74,7 @@ blind signatures that enables anonymous payments while ensuring that
entities that receive payments are auditable and thus taxable. Taler entities that receive payments are auditable and thus taxable. Taler
differs from Chaum's original proposal in that customers can never differs from Chaum's original proposal in that customers can never
defraud anyone, merchants can only fail to deliver the merchandise to defraud anyone, merchants can only fail to deliver the merchandise to
the customer, and mints can be fully audited. Consequently, the customer, and exchanges can be fully audited. Consequently,
enforcement of honest behavior is better and more timely than with enforcement of honest behavior is better and more timely than with
Chaum, and is at least as strict as with legacy credit card payment Chaum, and is at least as strict as with legacy credit card payment
systems that do not provide for privacy. Furthermore, Taler allows systems that do not provide for privacy. Furthermore, Taler allows
@ -112,11 +112,11 @@ anarchistic economies.
The Taler protocol is heavily based on ideas from The Taler protocol is heavily based on ideas from
Chaum~\cite{chaum1983blind} and also follows Chaum's basic architecture of Chaum~\cite{chaum1983blind} and also follows Chaum's basic architecture of
customer, merchant and mint (Figure~\ref{fig:cmm}). The two designs customer, merchant and exchange (Figure~\ref{fig:cmm}). The two designs
share the key first step where the {\em customer} withdraws digital share the key first step where the {\em customer} withdraws digital
{\em coins} from the {\em mint} with unlinkability provided via blind {\em coins} from the {\em exchange} with unlinkability provided via blind
signatures. The coins can then be spent at a {\em merchant} who {\em signatures. The coins can then be spent at a {\em merchant} who {\em
deposits} them at the mint. Taler uses online detection of deposits} them at the exchange. Taler uses online detection of
double-spending, thus assuring the merchant instantly that a double-spending, thus assuring the merchant instantly that a
transaction is valid. transaction is valid.
@ -125,17 +125,17 @@ transaction is valid.
\begin{tikzpicture} \begin{tikzpicture}
\tikzstyle{def} = [node distance= 5em and 7em, inner sep=1em, outer sep=.3em]; \tikzstyle{def} = [node distance= 5em and 7em, inner sep=1em, outer sep=.3em];
\node (origin) at (0,0) {}; \node (origin) at (0,0) {};
\node (mint) [def,above=of origin,draw]{Mint}; \node (exchange) [def,above=of origin,draw]{Exchange};
\node (customer) [def, draw, below left=of origin] {Customer}; \node (customer) [def, draw, below left=of origin] {Customer};
\node (merchant) [def, draw, below right=of origin] {Merchant}; \node (merchant) [def, draw, below right=of origin] {Merchant};
\node (auditor) [def, draw, above right=of origin]{Auditor}; \node (auditor) [def, draw, above right=of origin]{Auditor};
\tikzstyle{C} = [color=black, line width=1pt] \tikzstyle{C} = [color=black, line width=1pt]
\draw [<-, C] (customer) -- (mint) node [midway, above, sloped] (TextNode) {withdraw coins}; \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
\draw [<-, C] (mint) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins}; \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
\draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins}; \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
\draw [<-, C] (mint) -- (auditor) node [midway, above, sloped] (TextNode) {verify}; \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};
\end{tikzpicture} \end{tikzpicture}
\caption{Taler's system model for the payment system is based on Chaum~\cite{chaum1983blind}.} \caption{Taler's system model for the payment system is based on Chaum~\cite{chaum1983blind}.}
@ -147,7 +147,7 @@ believe needs a payment system with the following properties:
\begin{description} \begin{description}
\item[Customer Anonymity] \item[Customer Anonymity]
It must be impossible for mints, merchants and even a global active It must be impossible for exchanges, merchants and even a global active
adversary, to trace the spending behavior of a customer. adversary, to trace the spending behavior of a customer.
\item[Unlinkability] \item[Unlinkability]
As a strong form of customer anonymity, it must be infeasible to As a strong form of customer anonymity, it must be infeasible to
@ -170,11 +170,11 @@ believe needs a payment system with the following properties:
Nevertheless, customers must never be able to defraud anyone, and Nevertheless, customers must never be able to defraud anyone, and
merchants must at best be able to defraud their customers by not merchants must at best be able to defraud their customers by not
delivering on the agreed contract. Neither merchants nor customers delivering on the agreed contract. Neither merchants nor customers
should ever be able to commit fraud against the mint. Additionally, should ever be able to commit fraud against the exchange. Additionally,
both customers and merchants must receive cryptographic proofs of both customers and merchants must receive cryptographic proofs of
bad behavior in case of protocol violations by the mint. bad behavior in case of protocol violations by the exchange.
In this way, only the mint will need to be tightly audited and regulated. In this way, only the exchange will need to be tightly audited and regulated.
The design must make it easy to audit the finances of the mint. The design must make it easy to audit the finances of the exchange.
\item[Ease of Deployment] %The system should be easy to deploy for \item[Ease of Deployment] %The system should be easy to deploy for
% real-world applications. In order to lower the entry barrier and % real-world applications. In order to lower the entry barrier and
% acceptance of the system, a gateway to the existing financial % acceptance of the system, a gateway to the existing financial
@ -206,8 +206,8 @@ say a \EUR{0,01} coin and a \EUR{50,00} coin.
A merchant cannot simply give the customer their coins in another transaction; A merchant cannot simply give the customer their coins in another transaction;
however, as this reverses the role of merchant and customer, and however, as this reverses the role of merchant and customer, and
our taxability requirement would deanonymize the customer. The customer our taxability requirement would deanonymize the customer. The customer
also cannot withdraw exact change from his account from the mint, as this also cannot withdraw exact change from his account from the exchange, as this
would allow the mint to link the identity of the customer that is revealed would allow the exchange to link the identity of the customer that is revealed
during withdrawal to the subsequent deposit operation that follows shortly during withdrawal to the subsequent deposit operation that follows shortly
afterwards. afterwards.
Instead, the customer should obtain new freshly anonymized coins that cannot be Instead, the customer should obtain new freshly anonymized coins that cannot be
@ -226,9 +226,9 @@ A key contribution of Taler is the {\em refresh} protocol, which enables
a customer to exchange the residual value of the exchanged coin for a customer to exchange the residual value of the exchanged coin for
unlinkable freshly anonymized change. unlinkable freshly anonymized change.
Taler mints ensure that all transactions involving the same coin Taler exchanges ensure that all transactions involving the same coin
do not exceed the total value of the coin simply by do not exceed the total value of the coin simply by
requiring that merchants clear transactions immediately with the mint. requiring that merchants clear transactions immediately with the exchange.
This improves dramatically on systems that support offline merchants with This improves dramatically on systems that support offline merchants with
cryptographic threats to deanonymizing customers who double-spend, like cryptographic threats to deanonymizing customers who double-spend, like
restrictive blind signatures~\cite{brands1993efficient}. restrictive blind signatures~\cite{brands1993efficient}.
@ -308,17 +308,17 @@ Taler avoids include:
\item The use of patents to protect the technology; a payment system \item The use of patents to protect the technology; a payment system
should be free software (libre) to have a chance for widespread adoption. should be free software (libre) to have a chance for widespread adoption.
\item The use of off-line payments and thus deferred detection of \item The use of off-line payments and thus deferred detection of
double-spending, which could require the mint to attempt to recover double-spending, which could require the exchange to attempt to recover
funds from customers via the legal system. This creates a funds from customers via the legal system. This creates a
significant business risk for the mint, as the system is not significant business risk for the exchange, as the system is not
self-enforcing from the perspective of the mint. In 1983 off-line self-enforcing from the perspective of the exchange. In 1983 off-line
payments might have been a necessary feature. However, today payments might have been a necessary feature. However, today
requiring network connectivity is feasible and avoids the business requiring network connectivity is feasible and avoids the business
risks associated with deferred fraud detection. risks associated with deferred fraud detection.
\item % In addition to the risk of legal disputes with fraudulent \item % In addition to the risk of legal disputes with fraudulent
% merchants and customers, % merchants and customers,
Chaum's published design does not clearly Chaum's published design does not clearly
limit the financial damage a mint might suffer from the limit the financial damage a exchange might suffer from the
disclosure of its private online signing key. disclosure of its private online signing key.
\item Chaum did not support fractional payments or refunds without \item Chaum did not support fractional payments or refunds without
breaking customer anonymity. breaking customer anonymity.
@ -359,16 +359,16 @@ description of the Opencoin protocol is available to date.
Peppercoin~\cite{rivest2004peppercoin} is a microdonation protocol. Peppercoin~\cite{rivest2004peppercoin} is a microdonation protocol.
The main idea of the protocol is to reduce transaction costs by The main idea of the protocol is to reduce transaction costs by
minimizing the number of transactions that are processed directly by minimizing the number of transactions that are processed directly by
the mint. Instead of always paying, the customer ``gambles'' with the the exchange. Instead of always paying, the customer ``gambles'' with the
merchant for each microdonation. Only if the merchant wins, the merchant for each microdonation. Only if the merchant wins, the
microdonation is upgraded to a macropayment to be deposited at the microdonation is upgraded to a macropayment to be deposited at the
mint. Peppercoin does not provide customer-anonymity. The proposed exchange. Peppercoin does not provide customer-anonymity. The proposed
statistical method by which mints detect fraudulent cooperation between statistical method by which exchanges detect fraudulent cooperation between
customers and merchants at the expense of the mint not only creates customers and merchants at the expense of the exchange not only creates
legal risks for the mint, but would also require that the mint learns legal risks for the exchange, but would also require that the exchange learns
about microdonations where the merchant did not get upgraded to a about microdonations where the merchant did not get upgraded to a
macropayment. It is therefore unclear how Peppercoin would actually macropayment. It is therefore unclear how Peppercoin would actually
reduce the computational burden on the mint. reduce the computational burden on the exchange.
\section{Design} \section{Design}
@ -382,32 +382,32 @@ As with Chaum, the Taler system comprises three principal types of
actors (Figure~\ref{fig:cmm}): The \emph{customer} is interested in actors (Figure~\ref{fig:cmm}): The \emph{customer} is interested in
receiving goods or services from the \emph{merchant} in exchange for receiving goods or services from the \emph{merchant} in exchange for
payment. When making a transaction, both the customer and the payment. When making a transaction, both the customer and the
merchant must agree on the same \emph{mint}, which serves as an merchant must agree on the same \emph{exchange}, which serves as an
intermediary for the financial transaction between the two. The mint intermediary for the financial transaction between the two. The exchange
is responsible for allowing the customer to obtain the anonymous is responsible for allowing the customer to obtain the anonymous
digital currency and for enabling the merchant to convert the digital currency and for enabling the merchant to convert the
digital coins back to some traditional currency. The \emph{auditor} digital coins back to some traditional currency. The \emph{auditor}
assures customers and merchants that the mint operates correctly. assures customers and merchants that the exchange operates correctly.
\subsection{Security model} \subsection{Security model}
Taler's security model assumes that cryptographic primitives are Taler's security model assumes that cryptographic primitives are
secure and that each participant is under full control of his system. secure and that each participant is under full control of his system.
The contact information of the mint is known to both customer and The contact information of the exchange is known to both customer and
merchant from the start. Furthermore, the merchant communication's merchant from the start. Furthermore, the merchant communication's
authenticity is assured to the customer, such as by using X.509 authenticity is assured to the customer, such as by using X.509
certificates~\cite{rfc5280}, and we assume that an anonymous, reliable certificates~\cite{rfc5280}, and we assume that an anonymous, reliable
bi-directional communication channel can be established by the bi-directional communication channel can be established by the
customer to both the mint and the merchant, such as by using Tor. customer to both the exchange and the merchant, such as by using Tor.
The mint is trusted to hold funds of its customers and to forward them The exchange is trusted to hold funds of its customers and to forward them
when receiving the respective deposit instructions from the merchants. when receiving the respective deposit instructions from the merchants.
Customer and merchant can have some assurances about the mint's Customer and merchant can have some assurances about the exchange's
liquidity and operation, as the mint has proven reserves, is subject liquidity and operation, as the exchange has proven reserves, is subject
to the law, and can have its business regularly audited to the law, and can have its business regularly audited
by a government or third party. by a government or third party.
Regular audits of the mint's accounts should reveal any possible fraud Regular audits of the exchange's accounts should reveal any possible fraud
before the mint is allowed to destroy the corresponding accumulated before the exchange is allowed to destroy the corresponding accumulated
cryptographic proofs and book its fees as profits. cryptographic proofs and book its fees as profits.
% %
The merchant is trusted to deliver the service or goods to the The merchant is trusted to deliver the service or goods to the
@ -416,7 +416,7 @@ to achieve this, as he must get cryptographic proofs of the contract
and that he paid his obligations. and that he paid his obligations.
% %
Neither the merchant nor the customer may have any ability to {\em Neither the merchant nor the customer may have any ability to {\em
effectively} defraud the mint or the state collecting taxes. Here, effectively} defraud the exchange or the state collecting taxes. Here,
``effectively'' means that the expected return for fraud is negative. ``effectively'' means that the expected return for fraud is negative.
Note that customers do not need to be trusted in any way, and that in Note that customers do not need to be trusted in any way, and that in
particular it is never necessary for anyone to try to recover funds particular it is never necessary for anyone to try to recover funds
@ -455,10 +455,10 @@ thus {\bf not} recorded for taxation.
Taler ensures taxability only when some entity acquires exclusive Taler ensures taxability only when some entity acquires exclusive
control over the value of digital coins, which requires an interaction control over the value of digital coins, which requires an interaction
with the mint. For such transactions, the state can obtain information with the exchange. For such transactions, the state can obtain information
from the mint, or a bank, that identifies the entity that received the from the exchange, or a bank, that identifies the entity that received the
digital coins as well as the exact value of those coins. digital coins as well as the exact value of those coins.
Taler also allows the mint, and hence the state, to learn the value of Taler also allows the exchange, and hence the state, to learn the value of
digital coins withdrawn by a customer---but not how, where, or when digital coins withdrawn by a customer---but not how, where, or when
they were spent. they were spent.
@ -468,7 +468,7 @@ An anonymous communication channel such as Tor~\cite{tor-design} is
used for all communication between the customer and the merchant. used for all communication between the customer and the merchant.
Ideally, the customer's anonymity is limited only by this channel; Ideally, the customer's anonymity is limited only by this channel;
however, the payment system does additionally reveal that the customer however, the payment system does additionally reveal that the customer
is one of the patrons of the mint. is one of the patrons of the exchange.
There are naturally risks that the customer-merchant business operation There are naturally risks that the customer-merchant business operation
may leak identifying information about the customer. At least, customers may leak identifying information about the customer. At least, customers
have some options to defend their privacy against nosey merchants however, have some options to defend their privacy against nosey merchants however,
@ -477,7 +477,7 @@ We consider information leakage specific to the business logic to be
outside of the scope of the design of Taler. outside of the scope of the design of Taler.
Ideally, customer should use an anonymous communication channel with Ideally, customer should use an anonymous communication channel with
the mint to avoid leaking IP address information; however, the mint the exchange to avoid leaking IP address information; however, the exchange
would typically learn the customer's identity from the wire transfer would typically learn the customer's identity from the wire transfer
that funds the customer's withdraw anonymous digital coins. that funds the customer's withdraw anonymous digital coins.
In fact, this is desirable as there might be rules and regulations In fact, this is desirable as there might be rules and regulations
@ -485,33 +485,33 @@ designed to limit the amount of anonymous digital cash that an
individual customer can withdraw in a given time period, similar to individual customer can withdraw in a given time period, similar to
how states today sometimes impose limits on cash how states today sometimes impose limits on cash
withdrawals~\cite{france2015cash,greece2015cash}. withdrawals~\cite{france2015cash,greece2015cash}.
Taler is only anonymous with respect to {\em payments}, as the mint Taler is only anonymous with respect to {\em payments}, as the exchange
will be unable to link the known identity of the customer that withdrew will be unable to link the known identity of the customer that withdrew
anonymous digital currency to the {\em purchase} performed later at the anonymous digital currency to the {\em purchase} performed later at the
merchant. In this respect, Taler provides exactly the same scheme for merchant. In this respect, Taler provides exactly the same scheme for
unconditional anonymous payments as was proposed by unconditional anonymous payments as was proposed by
Chaum~\cite{chaum1983blind,chaum1990untraceable} over 30 years ago. Chaum~\cite{chaum1983blind,chaum1990untraceable} over 30 years ago.
While the customer thus has anonymity for purchases, the mint will While the customer thus has anonymity for purchases, the exchange will
always learn the merchant's identity in order to credit the merchant's always learn the merchant's identity in order to credit the merchant's
account. This is simply necessary for taxation, as Taler is supposed account. This is simply necessary for taxation, as Taler is supposed
to make information about funds received by any entity transparent to make information about funds received by any entity transparent
to the state. to the state.
% Technically, the merchant could still % Technically, the merchant could still
%use an anonymous communication channel to communicate with the mint. %use an anonymous communication channel to communicate with the exchange.
%However, in order to receive the traditional currency the mint will %However, in order to receive the traditional currency the exchange will
%require (SEPA) account details for the deposit. %require (SEPA) account details for the deposit.
%As both the initial transaction between the customer and the mint as %As both the initial transaction between the customer and the exchange as
%well as the transactions between the merchant and the mint do not have %well as the transactions between the merchant and the exchange do not have
%to be done anonymously, there might be a formal business contract %to be done anonymously, there might be a formal business contract
%between the customer and the mint and the merchant and the mint. Such %between the customer and the exchange and the merchant and the exchange. Such
%a contract may provide customers and merchants some assurance that %a contract may provide customers and merchants some assurance that
%they will actually receive the traditional currency from the mint %they will actually receive the traditional currency from the exchange
%given cryptographic proof about the validity of the transaction(s). %given cryptographic proof about the validity of the transaction(s).
%However, given the business overheads for establishing such contracts %However, given the business overheads for establishing such contracts
%and the natural goal for the mint to establish a reputation and to %and the natural goal for the exchange to establish a reputation and to
%minimize cost, it is more likely that the mint will advertise its %minimize cost, it is more likely that the exchange will advertise its
%external auditors and proven reserves and thereby try to convince %external auditors and proven reserves and thereby try to convince
%customers and merchants to trust it without a formal contract. %customers and merchants to trust it without a formal contract.
@ -519,57 +519,57 @@ to the state.
\subsection{Coins} \subsection{Coins}
A \emph{coin} in Taler is a public-private key pair which derives its A \emph{coin} in Taler is a public-private key pair which derives its
financial value from a signature over the coin's public key by a mint. financial value from a signature over the coin's public key by a exchange.
The mint is expected to have multiple {\em coin signing key} pairs The exchange is expected to have multiple {\em coin signing key} pairs
available for signing, each representing a different coin available for signing, each representing a different coin
denomination. denomination.
These coin signing keys have an expiration date, before which any coins These coin signing keys have an expiration date, before which any coins
signed with it must be spent or refreshed. This allows the mint to signed with it must be spent or refreshed. This allows the exchange to
eventually discard records of old transactions, thus limiting the eventually discard records of old transactions, thus limiting the
records that the mint must retain and search to detect double-spending records that the exchange must retain and search to detect double-spending
attempts. Furthermore, the mint is expected to use each coin signing attempts. Furthermore, the exchange is expected to use each coin signing
key only for a limited number of coins. key only for a limited number of coins.
% for example by limiting its use to sign coins to a week or a month. % for example by limiting its use to sign coins to a week or a month.
In this way, if a private coin signing key were to be compromised, In this way, if a private coin signing key were to be compromised,
the mint would detect this once more coins were redeemed than the total the exchange would detect this once more coins were redeemed than the total
that was signed into existence using that coin signing key. that was signed into existence using that coin signing key.
In this case, the mint could allow authentic customers to exchange their In this case, the exchange could allow authentic customers to exchange their
unspent coins that were signed with the compromised private key, unspent coins that were signed with the compromised private key,
while refusing further anonymous transactions involving those coins. while refusing further anonymous transactions involving those coins.
As a result, the financial damage of losing a private signing key can be As a result, the financial damage of losing a private signing key can be
limited to at most twice the amount originally signed with that key. limited to at most twice the amount originally signed with that key.
To ensure that the mint does not enable deanonymization of users by To ensure that the exchange does not enable deanonymization of users by
signing each coin with a fresh coin signing key, the mint must publicly signing each coin with a fresh coin signing key, the exchange must publicly
announce the coin signing keys in advance. Those announcements are announce the coin signing keys in advance. Those announcements are
expected to be signed with an off-line long-term private {\em master expected to be signed with an off-line long-term private {\em master
signing key} of the mint and the auditor. signing key} of the exchange and the auditor.
Before a customer can withdraw a coin from the mint, Before a customer can withdraw a coin from the exchange,
he has to pay the mint the value of the coin, as well as processing fees. he has to pay the exchange the value of the coin, as well as processing fees.
This is done using other means of payments, such as wire transfers or This is done using other means of payments, such as wire transfers or
by having a personal {\em reserve} at the mint, by having a personal {\em reserve} at the exchange,
which is equivalent to a bank account with a positive balance. which is equivalent to a bank account with a positive balance.
Taler assumes that the customer has a {\em withdrawal authorization key} Taler assumes that the customer has a {\em withdrawal authorization key}
to identify himself as authorized to withdraw funds from the reserve. to identify himself as authorized to withdraw funds from the reserve.
By signing the withdrawal request messages using this withdrawal By signing the withdrawal request messages using this withdrawal
authorization key, the customer can prove to the mint that he is the authorization key, the customer can prove to the exchange that he is the
individual authorized to withdraw anonymous digital coins from his reserve. individual authorized to withdraw anonymous digital coins from his reserve.
The mint will record the withdrawal messages with the reserve record as The exchange will record the withdrawal messages with the reserve record as
proof that the anonymous digital coin was created for the correct proof that the anonymous digital coin was created for the correct
customer. We note that the specifics of how the customer authenticates customer. We note that the specifics of how the customer authenticates
to the mint are orthogonal to the rest of the system, and to the exchange are orthogonal to the rest of the system, and
multiple methods can be supported. multiple methods can be supported.
%To put it differently, unlike %To put it differently, unlike
%modern cryptocurrencies like BitCoin, Taler's design simply %modern cryptocurrencies like BitCoin, Taler's design simply
%acknowledges that primitive accumulation~\cite{engels1844} predates %acknowledges that primitive accumulation~\cite{engels1844} predates
%the system and that a secure method to authenticate owners exists. %the system and that a secure method to authenticate owners exists.
After a coin is minted, the customer is the only entity that knows the After a coin is exchanged, the customer is the only entity that knows the
private key of the coin, making him the \emph{owner} of the coin. private key of the coin, making him the \emph{owner} of the coin.
The coin can be identified by the mint by its public key; however, due The coin can be identified by the exchange by its public key; however, due
to the use of blind signatures, the mint does not learn the public key to the use of blind signatures, the exchange does not learn the public key
during the minting process. Knowledge of the private key of the coin during the exchange process. Knowledge of the private key of the coin
enables the owner to spent the coin. If the private key is shared enables the owner to spent the coin. If the private key is shared
with others, they also become owners of the coin. with others, they also become owners of the coin.
@ -579,10 +579,10 @@ To spend a coin, the coin's owner needs to sign a {\em deposit
request} specifying the amount, the merchant's account information request} specifying the amount, the merchant's account information
and a {\em business transaction-specific hash} using the coin's and a {\em business transaction-specific hash} using the coin's
private key. A merchant can then transfer this permission of the private key. A merchant can then transfer this permission of the
coin's owner to the mint to obtain the amount in traditional currency. coin's owner to the exchange to obtain the amount in traditional currency.
If the customer is cheating and the coin was already spent, the mint If the customer is cheating and the coin was already spent, the exchange
provides cryptographic proof of the fraud to the merchant, who will provides cryptographic proof of the fraud to the merchant, who will
then refuse the transaction. The mint is typically expected to then refuse the transaction. The exchange is typically expected to
transfer the funds to the merchant using a wire transfer or by transfer the funds to the merchant using a wire transfer or by
crediting the merchant's individual account, depending on what is crediting the merchant's individual account, depending on what is
appropriate to the domain of the traditional currency. appropriate to the domain of the traditional currency.
@ -591,7 +591,7 @@ To allow exact payments without requiring the customer to keep a large
amount of ``change'' in stock and possibly perform thousands of amount of ``change'' in stock and possibly perform thousands of
signatures for larger transactions, the payment systems allows partial signatures for larger transactions, the payment systems allows partial
spending where just a fraction of a coin's total value is transferred. spending where just a fraction of a coin's total value is transferred.
Consequently, the mint the must not only store the identifiers of Consequently, the exchange the must not only store the identifiers of
spent coins, but also the fraction of the coin that has been spent. spent coins, but also the fraction of the coin that has been spent.
@ -601,7 +601,7 @@ In this and other scenarios it is thus possible that a customer has
revealed the public key of a coin to a merchant, but not ultimately revealed the public key of a coin to a merchant, but not ultimately
signed over the full value of the coin. If the customer then signed over the full value of the coin. If the customer then
continues to directly use the coin in other transactions, merchants continues to directly use the coin in other transactions, merchants
and the mint could link the various transactions as they all share the and the exchange could link the various transactions as they all share the
same public key for the coin. same public key for the coin.
The owner of such a {\em dirty} coin might therefore want to exchange it The owner of such a {\em dirty} coin might therefore want to exchange it
@ -620,21 +620,21 @@ must assure that owner stays the same.
% Meh, this paragraph sucks : % Meh, this paragraph sucks :
We therefore demand two main properties from the refresh protocol: We therefore demand two main properties from the refresh protocol:
First, the mint must not be able to link the fresh coin's public key to First, the exchange must not be able to link the fresh coin's public key to
the public key of the dirty coin. Second, the mint can ensure that the the public key of the dirty coin. Second, the exchange can ensure that the
owner of the dirty coin can determine the private key of the owner of the dirty coin can determine the private key of the
fresh coin, thereby preventing the refresh protocol from being used to fresh coin, thereby preventing the refresh protocol from being used to
construct a transaction. construct a transaction.
%As with other operations, the refreshing protocol must also protect %As with other operations, the refreshing protocol must also protect
%the mint from double-spending; similarly, the customer has to have %the exchange from double-spending; similarly, the customer has to have
%cryptographic evidence if there is any misbehavior by the mint. %cryptographic evidence if there is any misbehavior by the exchange.
%Finally, the mint may choose to charge a transaction fee for %Finally, the exchange may choose to charge a transaction fee for
%refreshing by reducing the value of the generated fresh coins %refreshing by reducing the value of the generated fresh coins
%in relation to the value of the melted coins. %in relation to the value of the melted coins.
% %
%Naturally, all such transaction fees should be clearly stated as part %Naturally, all such transaction fees should be clearly stated as part
%of the business contract offered by the mint to customers and %of the business contract offered by the exchange to customers and
%merchants. %merchants.
@ -650,10 +650,10 @@ context, and that the signature contains additional identification as
to the purpose of the signature, making it impossible to use a signature to the purpose of the signature, making it impossible to use a signature
in a different context. in a different context.
The mint has an {\em online message signing key} used for signing The exchange has an {\em online message signing key} used for signing
messages, as opposed to coins. The mint's long-term offline key is used messages, as opposed to coins. The exchange's long-term offline key is used
to certify both the coin signing keys and the online message signing key to certify both the coin signing keys and the online message signing key
of the mint. The mint's long-term offline key is assumed to be known to of the exchange. The exchange's long-term offline key is assumed to be known to
both customers and merchants and is certified by the auditors. both customers and merchants and is certified by the auditors.
As we are dealing with financial transactions, we explicitly describe As we are dealing with financial transactions, we explicitly describe
@ -665,19 +665,19 @@ information. Keys and thus coins always have a well-known expiration
date; information committed to disk can be discarded after the date; information committed to disk can be discarded after the
expiration date of the respective public key. Customers can also expiration date of the respective public key. Customers can also
discard information once the respective coins have been fully spent, discard information once the respective coins have been fully spent,
and merchants may discard information once payments from the mint have and merchants may discard information once payments from the exchange have
been received, assuming the records are also no longer needed for tax been received, assuming the records are also no longer needed for tax
purposes. The mint's bank transfers dealing in traditional currency purposes. The exchange's bank transfers dealing in traditional currency
are expected to be recorded for tax authorities to ensure taxability. are expected to be recorded for tax authorities to ensure taxability.
\subsection{Withdrawal} \subsection{Withdrawal}
Let $G$ be the generator of an elliptic curve. To withdraw anonymous Let $G$ be the generator of an elliptic curve. To withdraw anonymous
digital coins, the customer performs the following interaction with digital coins, the customer performs the following interaction with
the mint: the exchange:
\begin{enumerate} \begin{enumerate}
\item The customer identifies a mint with an auditor-approved \item The customer identifies a exchange with an auditor-approved
coin signing public-private key pair $K := (K_s, K_p)$ coin signing public-private key pair $K := (K_s, K_p)$
and randomly generates: and randomly generates:
\begin{itemize} \begin{itemize}
@ -685,19 +685,19 @@ the mint:
\item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$, \item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$,
\item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk. \item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk.
\end{itemize} \end{itemize}
\item The customer transfers an amount of money corresponding to at least $K_p$ to the mint, with $W_p$ in the subject line of the transaction. \item The customer transfers an amount of money corresponding to at least $K_p$ to the exchange, with $W_p$ in the subject line of the transaction.
\item The mint receives the transaction and credits the $W_p$ reserve with the respective amount in its database. \item The exchange receives the transaction and credits the $W_p$ reserve with the respective amount in its database.
\item The customer sends $S_W(B_b(C_p))$ to the mint to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with blinding factor $b$. \item The customer sends $S_W(B_b(C_p))$ to the exchange to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with blinding factor $b$.
\item The mint checks if the same withdrawal request was issued before; in this case, it sends $S_{K}(B_b(C_p))$ to the customer.\footnote{Here $S_K$ \item The exchange checks if the same withdrawal request was issued before; in this case, it sends $S_{K}(B_b(C_p))$ to the customer.\footnote{Here $S_K$
denotes a Chaum-style blind signature with private key $K_s$.} denotes a Chaum-style blind signature with private key $K_s$.}
If this is a fresh withdrawal request, the mint performs the following transaction: If this is a fresh withdrawal request, the exchange performs the following transaction:
\begin{enumerate} \begin{enumerate}
\item checks if the reserve $W_p$ has sufficient funds for a coin of value corresponding to $K_p$ \item checks if the reserve $W_p$ has sufficient funds for a coin of value corresponding to $K_p$
\item stores the withdrawal request and response $\langle S_W(B_b(C_p)), S_K(B_b(C_p)) \rangle$ in its database for future reference, \item stores the withdrawal request and response $\langle S_W(B_b(C_p)), S_K(B_b(C_p)) \rangle$ in its database for future reference,
\item deducts the amount corresponding to $K_p$ from the reserve, \item deducts the amount corresponding to $K_p$ from the reserve,
\end{enumerate} \end{enumerate}
and then sends $S_{K}(B_b(C_p))$ to the customer. and then sends $S_{K}(B_b(C_p))$ to the customer.
If the guards for the transaction fail, the mint sends a descriptive error back to the customer, If the guards for the transaction fail, the exchange sends a descriptive error back to the customer,
with proof that it operated correctly. with proof that it operated correctly.
Assuming the signature was valid, this would involve showing the transaction history for the reserve. Assuming the signature was valid, this would involve showing the transaction history for the reserve.
\item The customer computes and verifies the unblinded signature $S_K(C_p) = U_b(S_K(B_b(C_p)))$. \item The customer computes and verifies the unblinded signature $S_K(C_p) = U_b(S_K(B_b(C_p)))$.
@ -705,7 +705,7 @@ the mint:
\end{enumerate} \end{enumerate}
We note that the authorization to create and access a reserve using a We note that the authorization to create and access a reserve using a
withdrawal key $W$ is just one way to establish that the customer is withdrawal key $W$ is just one way to establish that the customer is
authorized to withdraw funds. If a mint has other ways to securely authorized to withdraw funds. If a exchange has other ways to securely
authenticate customers and establish that they are authorized to authenticate customers and establish that they are authorized to
withdraw funds, those can also be used with Taler. withdraw funds, those can also be used with Taler.
@ -713,19 +713,19 @@ withdraw funds, those can also be used with Taler.
\subsection{Exact and partial spending} \subsection{Exact and partial spending}
A customer can spend coins at a merchant, under the condition that the A customer can spend coins at a merchant, under the condition that the
merchant trusts the specific mint that minted the coin. Merchants are merchant trusts the specific exchange that exchanged the coin. Merchants are
identified by their key $M := (m_s, M_p)$ where the public key $M_p$ identified by their key $M := (m_s, M_p)$ where the public key $M_p$
must be known to the customer a priori. must be known to the customer a priori.
We now describe the protocol between the customer, merchant, and mint We now describe the protocol between the customer, merchant, and exchange
for a transaction in which the customer spends a coin $C := (c_s, C_p)$ for a transaction in which the customer spends a coin $C := (c_s, C_p)$
with signature $\widetilde{C} := S_K(C_p)$ with signature $\widetilde{C} := S_K(C_p)$
where $K$ is the mint's demonination key. where $K$ is the exchange's demonination key.
\begin{enumerate} \begin{enumerate}
\item\label{contract} \item\label{contract}
Let $\vec{D} := D_1, \ldots, D_n$ be the list of mints accepted by Let $\vec{D} := D_1, \ldots, D_n$ be the list of exchanges accepted by
the merchant where each $D_j$ is a mint's public key. the merchant where each $D_j$ is a exchange's public key.
The merchant creates a digitally signed contract The merchant creates a digitally signed contract
$\mathcal{A} := S_M(m, f, a, H(p, r), \vec{D})$ $\mathcal{A} := S_M(m, f, a, H(p, r), \vec{D})$
where $m$ is an identifier for this transaction, $a$ is data relevant where $m$ is an identifier for this transaction, $a$ is data relevant
@ -735,39 +735,39 @@ with signature $\widetilde{C} := S_K(C_p)$
$r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$ $r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$
to disk and sends $\mathcal{A}$ to the customer. to disk and sends $\mathcal{A}$ to the customer.
\item\label{deposit} \item\label{deposit}
The customer should already possess a coin minted by a mint that is The customer should already possess a coin exchanged by a exchange that is
accepted by the merchant, meaning $K$ should be publicly signed by accepted by the merchant, meaning $K$ should be publicly signed by
some $D_j \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$. some $D_j \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.
\item The customer generates a \emph{deposit-permission} $\mathcal{D} := \item The customer generates a \emph{deposit-permission} $\mathcal{D} :=
S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$ S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$
and sends $\langle \mathcal{D}, D_j\rangle$ to the merchant, and sends $\langle \mathcal{D}, D_j\rangle$ to the merchant,
where $D_j$ is the mint which signed $K$. where $D_j$ is the exchange which signed $K$.
\item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing $p$ \item The merchant gives $(\mathcal{D}, p, r)$ to the exchange, revealing $p$
only to the mint. only to the exchange.
\item The mint validates $\mathcal{D}$ and checks for double spending. \item The exchange validates $\mathcal{D}$ and checks for double spending.
If the coin has been involved in previous transactions and the new If the coin has been involved in previous transactions and the new
one would exceed its remaining value, it sends an error one would exceed its remaining value, it sends an error
with the records from the previous transactions back to the merchant. with the records from the previous transactions back to the merchant.
% %
If double spending is not found, the mint commits $\langle \mathcal{D} \rangle$ to disk If double spending is not found, the exchange commits $\langle \mathcal{D} \rangle$ to disk
and notifies the merchant that the deposit operation was successful. and notifies the merchant that the deposit operation was successful.
\item The merchant commits and forwards the notification from the mint to the \item The merchant commits and forwards the notification from the exchange to the
customer, confirming the success or failure of the operation. customer, confirming the success or failure of the operation.
\end{enumerate} \end{enumerate}
We have simplified the exposition by assuming that one coin suffices, but We have simplified the exposition by assuming that one coin suffices, but
in practice a customer can use multiple coins from the same mint where in practice a customer can use multiple coins from the same exchange where
the total value adds up to $f$ by running the following steps for the total value adds up to $f$ by running the following steps for
each of the coins. There is a risk of metadata leakage if a customer each of the coins. There is a risk of metadata leakage if a customer
acquires a coin in responce to the merchant, or if a customer uses acquires a coin in responce to the merchant, or if a customer uses
coings issued by multiple mints together. coings issued by multiple exchanges together.
If a transaction is aborted after Step~\ref{deposit}, If a transaction is aborted after Step~\ref{deposit},
subsequent transactions with the same coin could be linked to the coin, subsequent transactions with the same coin could be linked to the coin,
but not directly to the coin's owner. The same applies to partially but not directly to the coin's owner. The same applies to partially
spent coins where $f$ is smaller than the actual value of the coin. spent coins where $f$ is smaller than the actual value of the coin.
To unlink subsequent transactions from a coin, the customer has to To unlink subsequent transactions from a coin, the customer has to
execute the coin refreshing protocol with the mint. execute the coin refreshing protocol with the exchange.
%\begin{figure}[h] %\begin{figure}[h]
%\centering %\centering
@ -777,12 +777,12 @@ execute the coin refreshing protocol with the mint.
%\node (origin) at (0,0) {}; %\node (origin) at (0,0) {};
%\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)}; %\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)};
%\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)}; %\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)};
%\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ mint)}; %\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ exchange)};
%\node (C) [def,below=of B]{confirm (or refuse) lock (mint $\rightarrow$ merchant)}; %\node (C) [def,below=of B]{confirm (or refuse) lock (exchange $\rightarrow$ merchant)};
%\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)}; %\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)};
%\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)}; %\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)};
%\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ mint)}; %\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ exchange)};
%\node (G) [def,below=of F]{transfer confirmation (mint $\rightarrow$ merchant)}; %\node (G) [def,below=of F]{transfer confirmation (exchange $\rightarrow$ merchant)};
% %
%\tikzstyle{C} = [color=black, line width=1pt] %\tikzstyle{C} = [color=black, line width=1pt]
%\draw [->,C](offer) -- (A); %\draw [->,C](offer) -- (A);
@ -796,7 +796,7 @@ execute the coin refreshing protocol with the mint.
%\draw [->,C, bend right, shorten <=2mm] (E.east) %\draw [->,C, bend right, shorten <=2mm] (E.east)
% to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east); % to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east);
%\end{tikzpicture} %\end{tikzpicture}
%\caption{Interactions between a customer, merchant and mint in the coin spending %\caption{Interactions between a customer, merchant and exchange in the coin spending
% protocol} % protocol}
%\label{fig:spending_protocol_interactions} %\label{fig:spending_protocol_interactions}
%\end{figure} %\end{figure}
@ -830,18 +830,18 @@ generator of the elliptic curve.
between the private key $c'_s$ of the original coin with between the private key $c'_s$ of the original coin with
the public transfer key $T_p^{(i)}$. the public transfer key $T_p^{(i)}$.
\item The customer computes $B^{(i)} := B_{b^{(i)}}(C^{(i)}_p)$ for $i \in \{1,\ldots,\kappa\}$ and sends a commitment \item The customer computes $B^{(i)} := B_{b^{(i)}}(C^{(i)}_p)$ for $i \in \{1,\ldots,\kappa\}$ and sends a commitment
$S_{C'}(\vec{E}, \vec{B}, \vec{T_p})$ to the mint. $S_{C'}(\vec{E}, \vec{B}, \vec{T_p})$ to the exchange.
\item The mint generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and \item The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
marks $C'_p$ as spent by committing marks $C'_p$ as spent by committing
$\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T_p}) \rangle$ to disk. $\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T_p}) \rangle$ to disk.
Auditing processes should assure that $\gamma$ is unpredictable until Auditing processes should assure that $\gamma$ is unpredictable until
this time to prevent the mint from assisting tax evasion. this time to prevent the exchange from assisting tax evasion.
\item The mint sends $S_{K'}(C'_p, \gamma)$ to the customer where \item The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where
$K'$ is the mint's message signing key. $K'$ is the exchange's message signing key.
\item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk. \item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk.
\item The customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$ \item The customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
and sends $S_{C'}(\mathfrak{R})$ to the mint. and sends $S_{C'}(\mathfrak{R})$ to the exchange.
\item \label{step:refresh-ccheck} The mint checks whether $\mathfrak{R}$ is consistent with the commitments; \item \label{step:refresh-ccheck} The exchange checks whether $\mathfrak{R}$ is consistent with the commitments;
specifically, it computes for $i \not= \gamma$: specifically, it computes for $i \not= \gamma$:
\vspace{-2ex} \vspace{-2ex}
@ -864,8 +864,8 @@ generator of the elliptic curve.
\item \label{step:refresh-done} If the commitments were consistent, \item \label{step:refresh-done} If the commitments were consistent,
the mint sends the blind signature $\widetilde{C} := the exchange sends the blind signature $\widetilde{C} :=
S_{K}(B^{(\gamma)})$ to the customer. Otherwise, the mint responds S_{K}(B^{(\gamma)})$ to the customer. Otherwise, the exchange responds
with an error indicating the location of the failure. with an error indicating the location of the failure.
\end{enumerate} \end{enumerate}
@ -875,7 +875,7 @@ generator of the elliptic curve.
\subsection{Linking} \subsection{Linking}
For a coin that was successfully refreshed, the mint responds to a For a coin that was successfully refreshed, the exchange responds to a
request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E^{(\gamma)}, request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E^{(\gamma)},
\widetilde{C})$. \widetilde{C})$.
% %
@ -883,7 +883,7 @@ This allows the owner of the melted coin to also obtain the private
key of the new coin, even if the refreshing protocol was illicitly key of the new coin, even if the refreshing protocol was illicitly
executed with the help of another party who generated $\vec{c_s}$ and only executed with the help of another party who generated $\vec{c_s}$ and only
provided $\vec{C_p}$ and other required information to the old owner. provided $\vec{C_p}$ and other required information to the old owner.
As a result, linking ensures that access to the new coins minted by As a result, linking ensures that access to the new coins exchanged by
the refresh protocol is always {\em shared} with the owner of the the refresh protocol is always {\em shared} with the owner of the
melted coins. This makes it impossible to abuse the refresh protocol melted coins. This makes it impossible to abuse the refresh protocol
for {\em transactions}. for {\em transactions}.
@ -892,7 +892,7 @@ The linking request is not expected to be used at all during ordinary
operation of Taler. If the refresh protocol is used by Alice to operation of Taler. If the refresh protocol is used by Alice to
obtain change as designed, she already knows all of the information obtain change as designed, she already knows all of the information
and thus has little reason to request it via the linking protocol. and thus has little reason to request it via the linking protocol.
The fundamental reason why the mint must provide the link protocol is The fundamental reason why the exchange must provide the link protocol is
simply to provide a threat: if Bob were to use the refresh protocol simply to provide a threat: if Bob were to use the refresh protocol
for a transaction of funds from Alice to him, Alice may use a link for a transaction of funds from Alice to him, Alice may use a link
request to gain shared access to Bob's coins. Thus, this threat request to gain shared access to Bob's coins. Thus, this threat
@ -903,8 +903,8 @@ exchanging the original private coin keys. This is permitted in our
taxation model as with such trust they are assumed to be the same taxation model as with such trust they are assumed to be the same
entity. entity.
The auditor can anonymously check if the mint correctly implements the The auditor can anonymously check if the exchange correctly implements the
link request, thus preventing the mint operator from legally disabling link request, thus preventing the exchange operator from legally disabling
this protocol component. Without the link operation, Taler would this protocol component. Without the link operation, Taler would
devolve into a payment system where both sides can be anonymous, and devolve into a payment system where both sides can be anonymous, and
thus no longer provide taxability. thus no longer provide taxability.
@ -926,7 +926,7 @@ server indicates that the client is violating the protocol, the
client should record the interaction and enable the user to file a client should record the interaction and enable the user to file a
bug report. bug report.
The second case is a faulty mint service provider. Such faults will The second case is a faulty exchange service provider. Such faults will
be detected because of protocol violations, such as providing be detected because of protocol violations, such as providing
a faulty proof or no proof. In this case, the client is expected to a faulty proof or no proof. In this case, the client is expected to
notify the auditor, providing a transcript of the interaction. The notify the auditor, providing a transcript of the interaction. The
@ -935,7 +935,7 @@ provide the now correct response to the client or take appropriate
legal action against the faulty provider. legal action against the faulty provider.
The third case are transient failures, such as network failures or The third case are transient failures, such as network failures or
temporary hardware failures at the mint service provider. Here, the temporary hardware failures at the exchange service provider. Here, the
client may receive an explicit protocol indication, such as an HTTP client may receive an explicit protocol indication, such as an HTTP
response code 500 ``internal server error'' or simply no response. response code 500 ``internal server error'' or simply no response.
The appropriate behavior for the client is to automatically retry The appropriate behavior for the client is to automatically retry
@ -961,9 +961,9 @@ details, and having the customer keep the private key of the spent
coins on file. coins on file.
Given this, the merchant can simply sign a {\em refund confirmation} Given this, the merchant can simply sign a {\em refund confirmation}
and share it with the mint and the customer. Assuming the mint has and share it with the exchange and the customer. Assuming the exchange has
a way to recover the funds from the merchant, or has not yet performed a way to recover the funds from the merchant, or has not yet performed
the wire transfer, the mint can simply add the value of the refunded the wire transfer, the exchange can simply add the value of the refunded
transaction back to the original coin, re-enabling those funds to be transaction back to the original coin, re-enabling those funds to be
spent again by the original customer. spent again by the original customer.
@ -990,11 +990,11 @@ check and not also all previous owners of the physical check.
As with any unconditionally anonymous payment system, the ``Perfect As with any unconditionally anonymous payment system, the ``Perfect
Crime'' attack~\cite{solms1992perfect} where blackmail is used to Crime'' attack~\cite{solms1992perfect} where blackmail is used to
force the mint to issue anonymous coins also continues to apply in force the exchange to issue anonymous coins also continues to apply in
principle. However, as mentioned Taler does facilitate limits on principle. However, as mentioned Taler does facilitate limits on
withdrawals, which we believe is a better trade-off than the withdrawals, which we believe is a better trade-off than the
problematic escrow systems where the necessary intransparency problematic escrow systems where the necessary intransparency
actually facilitates voluntary cooperation between the mint and actually facilitates voluntary cooperation between the exchange and
criminals~\cite{sander1999escrow} and where state can selectively criminals~\cite{sander1999escrow} and where state can selectively
deanonymize activists to support the deep state's quest for absolute deanonymize activists to support the deep state's quest for absolute
security. security.
@ -1002,12 +1002,12 @@ security.
\subsection{Offline Payments} \subsection{Offline Payments}
Chaum's original proposals for anonymous digital cash avoided the need Chaum's original proposals for anonymous digital cash avoided the need
for online interactions with the mint to detect double spending by for online interactions with the exchange to detect double spending by
providing a means to deanonymize customers involved in providing a means to deanonymize customers involved in
double-spending. We believe that this is problematic as the mint or double-spending. We believe that this is problematic as the exchange or
the merchant will then still need out-of-band means to recover funds the merchant will then still need out-of-band means to recover funds
from the customer, which may be impossible in practice. In contrast, from the customer, which may be impossible in practice. In contrast,
in our design only the mint may try to defraud the other participants in our design only the exchange may try to defraud the other participants
and disappear. While this is still a risk, and regular financial and disappear. While this is still a risk, and regular financial
audits are required to protect against it, this is more manageable and audits are required to protect against it, this is more manageable and
significantly cheaper compared to recovering funds via the court significantly cheaper compared to recovering funds via the court
@ -1017,12 +1017,12 @@ Chaum's method for offline payments would also be incompatible with
the refreshing protocol (Section~\ref{sec:refreshing}) which enables the refreshing protocol (Section~\ref{sec:refreshing}) which enables
the crucial feature of giving unlinkable change. The reason is that the crucial feature of giving unlinkable change. The reason is that
if the owner's identity were embedded in coins, it would be leaked to if the owner's identity were embedded in coins, it would be leaked to
the mint as part of the reveal operation in the cut-and-choose the exchange as part of the reveal operation in the cut-and-choose
operation of the refreshing protocol. operation of the refreshing protocol.
%\subsection{Merchant Tax Audits} %\subsection{Merchant Tax Audits}
% %
%For a tax audit on the merchant, the mint includes the business %For a tax audit on the merchant, the exchange includes the business
%transaction-specific hash in the transfer of the traditional %transaction-specific hash in the transfer of the traditional
%currency. A tax auditor can then request the merchant to reveal %currency. A tax auditor can then request the merchant to reveal
%(meaningful) details about the business transaction ($\mathcal{D}$, %(meaningful) details about the business transaction ($\mathcal{D}$,
@ -1048,13 +1048,13 @@ computing base (TCB) is public and free software.
%\subsection{System Performance} %\subsection{System Performance}
% %
%We performed some initial performance measurements for the various %We performed some initial performance measurements for the various
%operations on our mint implementation. The main conclusion was that %operations on our exchange implementation. The main conclusion was that
%the computational and bandwidth cost for transactions described in %the computational and bandwidth cost for transactions described in
%this paper is smaller than $10^{-3}$ cent/transaction, and thus %this paper is smaller than $10^{-3}$ cent/transaction, and thus
%dwarfed by the other business costs for the mint. However, this %dwarfed by the other business costs for the exchange. However, this
%figure excludes the cost of currency transfers using traditional %figure excludes the cost of currency transfers using traditional
%banking, which a mint operator would ultimately have to interact with. %banking, which a exchange operator would ultimately have to interact with.
%Here, mint operators should be able to reduce their expenses by %Here, exchange operators should be able to reduce their expenses by
%aggregating multiple transfers to the same merchant. %aggregating multiple transfers to the same merchant.
@ -1065,8 +1065,8 @@ computing base (TCB) is public and free software.
%citizen's need for privacy and the state's need for taxation. The %citizen's need for privacy and the state's need for taxation. The
%coin refreshing protocol makes the design flexible and enables a %coin refreshing protocol makes the design flexible and enables a
%variety of payment methods. The current balance and profits of the %variety of payment methods. The current balance and profits of the
%mint are also easily determined, thus audits can be used to ensure %exchange are also easily determined, thus audits can be used to ensure
%that the mint operates correctly. The libre implementation and open %that the exchange operates correctly. The libre implementation and open
%protocol may finally enable modern society to upgrade to proper %protocol may finally enable modern society to upgrade to proper
%electronic wallets with efficient, secure and privacy-preserving %electronic wallets with efficient, secure and privacy-preserving
%transactions. %transactions.
@ -1097,17 +1097,17 @@ certain interactions.
However, we note that Taler's transaction costs are expected to be so However, we note that Taler's transaction costs are expected to be so
low that these features are likely not particularly useful in low that these features are likely not particularly useful in
practice: When we performed some initial performance measurements for practice: When we performed some initial performance measurements for
the various operations on our mint implementation, the main conclusion the various operations on our exchange implementation, the main conclusion
was that the computational and bandwidth cost for transactions was that the computational and bandwidth cost for transactions
described in this paper is smaller than $10^{-3}$ cent/transaction, described in this paper is smaller than $10^{-3}$ cent/transaction,
and thus dwarfed by the other business costs for the mint. We note and thus dwarfed by the other business costs for the exchange. We note
that the $10^{-3}$ cent/transaction estimate excludes the cost of wire that the $10^{-3}$ cent/transaction estimate excludes the cost of wire
transfers using traditional banking, which a mint operator would transfers using traditional banking, which a exchange operator would
ultimately have to interact with. Here, mint operators should be able ultimately have to interact with. Here, exchange operators should be able
to reduce their expenses by aggregating multiple transfers to the same to reduce their expenses by aggregating multiple transfers to the same
merchant. merchant.
As a result of the low cost of the interaction with the mint in Taler As a result of the low cost of the interaction with the exchange in Taler
today, we expect that transactions with amounts below Taler's internal today, we expect that transactions with amounts below Taler's internal
transaction costs to be economically meaningless. Nevertheless, we transaction costs to be economically meaningless. Nevertheless, we
document various ways how such transactions could be achieved within document various ways how such transactions could be achieved within
@ -1120,7 +1120,7 @@ Taler.
For services that include pay-as-you-go billing, customers can over For services that include pay-as-you-go billing, customers can over
time sign deposit permissions for an increasing fraction of the value time sign deposit permissions for an increasing fraction of the value
of a coin to be paid to a particular merchant. As checking with the of a coin to be paid to a particular merchant. As checking with the
mint for each increment might be expensive, the coin's owner can exchange for each increment might be expensive, the coin's owner can
instead sign a {\em lock permission}, which allows the merchant to get instead sign a {\em lock permission}, which allows the merchant to get
an exclusive right to redeem deposit permissions for the coin for a an exclusive right to redeem deposit permissions for the coin for a
limited duration. The merchant uses the lock permission to determine limited duration. The merchant uses the lock permission to determine
@ -1128,41 +1128,41 @@ if the coin has already been spent and to ensure that it cannot be
spent by another merchant for the {\em duration} of the lock as spent by another merchant for the {\em duration} of the lock as
specified in the lock permission. If the coin has insufficient funds specified in the lock permission. If the coin has insufficient funds
because too much has been spent or is because too much has been spent or is
already locked, the mint provides the owner's deposit or locking already locked, the exchange provides the owner's deposit or locking
request and signature to prove the attempted fraud by the customer. request and signature to prove the attempted fraud by the customer.
Otherwise, the mint locks the coin for the expected duration of the Otherwise, the exchange locks the coin for the expected duration of the
transaction (and remembers the lock permission). The merchant and the transaction (and remembers the lock permission). The merchant and the
customer can then finalize the business transaction, possibly customer can then finalize the business transaction, possibly
exchanging a series of incremental payment permissions for services. exchanging a series of incremental payment permissions for services.
Finally, the merchant then redeems the coin at the mint before the Finally, the merchant then redeems the coin at the exchange before the
lock permission expires to ensure that no other merchant redeems the lock permission expires to ensure that no other merchant redeems the
coin first. coin first.
\begin{enumerate} \begin{enumerate}
\item\label{offer2} The merchant sends an \emph{offer:} $\langle S_M(m, f), \item\label{offer2} The merchant sends an \emph{offer:} $\langle S_M(m, f),
\vec{D} \rangle$ containing the price of the offer $f$, a transaction \vec{D} \rangle$ containing the price of the offer $f$, a transaction
ID $m$ and the list of mints $D_1, \ldots, D_n$ accepted by the merchant ID $m$ and the list of exchanges $D_1, \ldots, D_n$ accepted by the merchant
where each $D_j$ is a mint's public key. where each $D_j$ is a exchange's public key.
\item\label{lock2} The customer must possess or acquire a coin $\widetilde{C}$ \item\label{lock2} The customer must possess or acquire a coin $\widetilde{C}$
signed by a mint that is signed by a exchange that is
accepted by the merchant, i.e. $K$ should be signed by some $D_j accepted by the merchant, i.e. $K$ should be signed by some $D_j
\in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$. \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.
Customer then generates a \emph{lock-permission} $\mathcal{L} := Customer then generates a \emph{lock-permission} $\mathcal{L} :=
S_c(\widetilde{C}, t, m, f, M_p)$ where $t$ specifies the time until which the S_c(\widetilde{C}, t, m, f, M_p)$ where $t$ specifies the time until which the
lock is valid and sends $\langle \mathcal{L}, D_j\rangle$ to the merchant, lock is valid and sends $\langle \mathcal{L}, D_j\rangle$ to the merchant,
where $D_j$ is the mint which signed $K$. where $D_j$ is the exchange which signed $K$.
\item The merchant asks the mint to apply the lock by sending $\langle \item The merchant asks the exchange to apply the lock by sending $\langle
\mathcal{L} \rangle$ to the mint. \mathcal{L} \rangle$ to the exchange.
\item The mint validates $\widetilde{C}$ and detects double spending \item The exchange validates $\widetilde{C}$ and detects double spending
in the form of existing \emph{deposit-permission} or in the form of existing \emph{deposit-permission} or
lock-permission records for $\widetilde{C}$. If such records exist lock-permission records for $\widetilde{C}$. If such records exist
and indicate that insufficient funds are left, the mint sends those and indicate that insufficient funds are left, the exchange sends those
records to the merchant, who can then use the records to prove the double records to the merchant, who can then use the records to prove the double
spending to the customer. spending to the customer.
If double spending is not found, If double spending is not found,
the mint commits $\langle \mathcal{L} \rangle$ to disk the exchange commits $\langle \mathcal{L} \rangle$ to disk
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 $\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract
@ -1173,23 +1173,23 @@ coin first.
\emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, \widetilde{L}, f, m, M_p, H(a), H(p, r))$, commits \emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, \widetilde{L}, f, m, M_p, H(a), H(p, r))$, commits
$\langle \mathcal{A}, \mathcal{D} \rangle$ to disk and sends $\mathcal{D}$ to the merchant. $\langle \mathcal{A}, \mathcal{D} \rangle$ to disk and sends $\mathcal{D}$ to the merchant.
\item\label{invoice_paid2} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk. \item\label{invoice_paid2} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk.
\item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing his \item The merchant gives $(\mathcal{D}, p, r)$ to the exchange, revealing his
payment information. payment information.
\item The mint verifies $(\mathcal{D}, p, r)$ for its validity and \item The exchange verifies $(\mathcal{D}, p, r)$ for its validity and
checks against double spending, while of checks against double spending, while of
course permitting the merchant to withdraw funds from the amount that course permitting the merchant to withdraw funds from the amount that
had been locked for this merchant. had been locked for this merchant.
\item If $\widetilde{C}$ is valid and no equivalent \emph{deposit-permission} for $\widetilde{C}$ and $\widetilde{L}$ exists on disk, the \item If $\widetilde{C}$ is valid and no equivalent \emph{deposit-permission} for $\widetilde{C}$ and $\widetilde{L}$ exists on disk, the
mint performs the following transaction: exchange performs the following transaction:
\begin{enumerate} \begin{enumerate}
\item $\langle \mathcal{D}, p, r \rangle$ is committed to disk. \item $\langle \mathcal{D}, p, r \rangle$ is committed to disk.
\item\label{transfer2} transfers an amount of $f$ to the merchant's bank account \item\label{transfer2} transfers an amount of $f$ to the merchant's bank account
given in $p$. The subject line of the transaction to $p$ must contain given in $p$. The subject line of the transaction to $p$ must contain
$H(\mathcal{D})$. $H(\mathcal{D})$.
\end{enumerate} \end{enumerate}
Finally, the mint sends a confirmation to the merchant. Finally, the exchange sends a confirmation to the merchant.
\item If the deposit record $\langle \mathcal{D}, p, r \rangle$ already exists, \item If the deposit record $\langle \mathcal{D}, p, r \rangle$ already exists,
the mint sends the confirmation to the merchant, the exchange sends the confirmation to the merchant,
but does not transfer money to $p$ again. but does not transfer money to $p$ again.
\end{enumerate} \end{enumerate}
@ -1223,7 +1223,7 @@ incremental amount up to $f_{max}$:
For transactions with multiple coins, the steps of the protocol are For transactions with multiple coins, the steps of the protocol are
executed in parallel for each coin. During the time a coin is locked, executed in parallel for each coin. During the time a coin is locked,
the locked fraction may not be spent at a different merchant or via a the locked fraction may not be spent at a different merchant or via a
deposit permission that does not contain $\mathcal{L}$. The mint will deposit permission that does not contain $\mathcal{L}$. The exchange will
release the locks when they expire or are used in a deposit operation. release the locks when they expire or are used in a deposit operation.
Thus the coins can be used with other merchants once their locks Thus the coins can be used with other merchants once their locks
expire, even if the original merchant never executed any deposit for expire, even if the original merchant never executed any deposit for
@ -1234,7 +1234,7 @@ Similarly, if a transaction is aborted after Step 2, subsequent
transactions with the same coin can be linked to the coin, but not transactions with the same coin can be linked to the coin, but not
directly to the coin's owner. The same applies to partially spent directly to the coin's owner. The same applies to partially spent
coins. Thus, to unlink subsequent transactions from a coin, the coins. Thus, to unlink subsequent transactions from a coin, the
customer has to execute the coin refreshing protocol with the mint. customer has to execute the coin refreshing protocol with the exchange.
%\begin{figure}[h] %\begin{figure}[h]
%\centering %\centering
@ -1244,12 +1244,12 @@ customer has to execute the coin refreshing protocol with the mint.
%\node (origin) at (0,0) {}; %\node (origin) at (0,0) {};
%\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)}; %\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)};
%\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)}; %\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)};
%\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ mint)}; %\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ exchange)};
%\node (C) [def,below=of B]{confirm (or refuse) lock (mint $\rightarrow$ merchant)}; %\node (C) [def,below=of B]{confirm (or refuse) lock (exchange $\rightarrow$ merchant)};
%\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)}; %\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)};
%\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)}; %\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)};
%\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ mint)}; %\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ exchange)};
%\node (G) [def,below=of F]{transfer confirmation (mint $\rightarrow$ merchant)}; %\node (G) [def,below=of F]{transfer confirmation (exchange $\rightarrow$ merchant)};
% %
%\tikzstyle{C} = [color=black, line width=1pt] %\tikzstyle{C} = [color=black, line width=1pt]
%\draw [->,C](offer) -- (A); %\draw [->,C](offer) -- (A);
@ -1263,7 +1263,7 @@ customer has to execute the coin refreshing protocol with the mint.
%\draw [->,C, bend right, shorten <=2mm] (E.east) %\draw [->,C, bend right, shorten <=2mm] (E.east)
% to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east); % to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east);
%\end{tikzpicture} %\end{tikzpicture}
%\caption{Interactions between a customer, merchant and mint in the coin spending %\caption{Interactions between a customer, merchant and exchange in the coin spending
% protocol} % protocol}
%\label{fig:spending_protocol_interactions} %\label{fig:spending_protocol_interactions}
%\end{figure} %\end{figure}
@ -1274,7 +1274,7 @@ customer has to execute the coin refreshing protocol with the mint.
Similar to Peppercoin, Taler supports probabilistic {\em micro}donations of coins to Similar to Peppercoin, Taler supports probabilistic {\em micro}donations of coins to
support cost-effective transactions for small amounts. We consider support cost-effective transactions for small amounts. We consider
amounts to be ``micro'' if the value of the transaction is close or amounts to be ``micro'' if the value of the transaction is close or
even below the business cost of an individual transaction to the mint. even below the business cost of an individual transaction to the exchange.
To support microdonations, an ordinary transaction is performed based To support microdonations, an ordinary transaction is performed based
on the result of a biased coin flip with a probability related to the on the result of a biased coin flip with a probability related to the
@ -1282,7 +1282,7 @@ desired transaction amount in relation to the value of the coin. More
specifically, a microdonation of value $\epsilon$ is upgraded to a specifically, a microdonation of value $\epsilon$ is upgraded to a
macropayment of value $m$ with a probability of $\frac{\epsilon}{m}$. macropayment of value $m$ with a probability of $\frac{\epsilon}{m}$.
Here, $m$ is chosen such that the business transaction cost at the Here, $m$ is chosen such that the business transaction cost at the
mint is small in relation to $m$. The mint is only involved in the exchange is small in relation to $m$. The exchange is only involved in the
tiny fraction of transactions that are upgraded. On average both tiny fraction of transactions that are upgraded. On average both
customers and merchants end up paying (or receiving) the expected customers and merchants end up paying (or receiving) the expected
amount $\epsilon$ per microdonation. amount $\epsilon$ per microdonation.
@ -1290,12 +1290,12 @@ amount $\epsilon$ per microdonation.
Unlike Peppercoin, in Taler either the merchant wins and the customer Unlike Peppercoin, in Taler either the merchant wins and the customer
looses the coin, or the merchant looses and the customer keeps the looses the coin, or the merchant looses and the customer keeps the
coin. Thus, there is no opportunity for the merchant and the customer coin. Thus, there is no opportunity for the merchant and the customer
to conspire against the mint. To determine if the coin is to be to conspire against the exchange. To determine if the coin is to be
transferred, merchant and customer execute a secure coin flipping transferred, merchant and customer execute a secure coin flipping
protocol~\cite{blum1981}. The commit values are included in the protocol~\cite{blum1981}. The commit values are included in the
business contract and are revealed after the contract has been signed business contract and are revealed after the contract has been signed
using the private key of the coin. If the coin flip is decided in using the private key of the coin. If the coin flip is decided in
favor of the merchant, the merchant can redeem the coin at the mint. favor of the merchant, the merchant can redeem the coin at the exchange.
One issue in this protocol is that the customer may use a worthless One issue in this protocol is that the customer may use a worthless
coin by offering a coin that has already been spent. This kind of coin by offering a coin that has already been spent. This kind of
@ -1306,9 +1306,9 @@ already spent coins until the coin flip is in his favor.
As with incremental spending, lock permissions could be used to ensure As with incremental spending, lock permissions could be used to ensure
that the customer cannot defraud the merchant by offering a coin that that the customer cannot defraud the merchant by offering a coin that
has already been spent. However, as this means involving the mint has already been spent. However, as this means involving the exchange
even if the merchant looses the coin flip, such a scheme is unsuitable even if the merchant looses the coin flip, such a scheme is unsuitable
for microdonations as the transaction costs from involving the mint for microdonations as the transaction costs from involving the exchange
might be disproportionate to the value of the transaction, and thus might be disproportionate to the value of the transaction, and thus
with locking the probabilistic scheme has no advantage over simply with locking the probabilistic scheme has no advantage over simply
using fractional payments. using fractional payments.
@ -1366,7 +1366,7 @@ indicate the application of a function $f$ to one or more arguments. Records of
data being committed to disk are represented in between $\langle\rangle$. data being committed to disk are represented in between $\langle\rangle$.
\begin{description} \begin{description}
\item[$K_s$]{Private (RSA) key of the mint used for coin signing} \item[$K_s$]{Private (RSA) key of the exchange used for coin signing}
\item[$K_p$]{Public (RSA) key corresponding to $K_s$} \item[$K_p$]{Public (RSA) key corresponding to $K_s$}
\item[$K$]{Public-priate (RSA) coin signing key pair $K := (K_s, K_p)$} \item[$K$]{Public-priate (RSA) coin signing key pair $K := (K_s, K_p)$}
\item[$b$]{RSA blinding factor for RSA-style blind signatures} \item[$b$]{RSA blinding factor for RSA-style blind signatures}
@ -1389,11 +1389,11 @@ data being committed to disk are represented in between $\langle\rangle$.
\item[$c_s'$]{Private key of a ``dirty'' coin (otherwise like $c_s$)} \item[$c_s'$]{Private key of a ``dirty'' coin (otherwise like $c_s$)}
\item[$C_p'$]{Public key of a ``dirty'' coin (otherwise like $C_p$)} \item[$C_p'$]{Public key of a ``dirty'' coin (otherwise like $C_p$)}
\item[$C'$]{Dirty coin (otherwise like $C$)} \item[$C'$]{Dirty coin (otherwise like $C$)}
\item[$\widetilde{C}$]{Mint signature $S_K(C_p)$ indicating validity of a fresh coin (with key $C$)} \item[$\widetilde{C}$]{Exchange signature $S_K(C_p)$ indicating validity of a fresh coin (with key $C$)}
\item[$n$]{Number of mints accepted by a merchant} \item[$n$]{Number of exchanges accepted by a merchant}
\item[$j$]{Index into a set of accepted mints, $i \in \{1,\ldots,n\}$} \item[$j$]{Index into a set of accepted exchanges, $i \in \{1,\ldots,n\}$}
\item[$D_j$]{Public key of a mint (not used to sign coins)} \item[$D_j$]{Public key of a exchange (not used to sign coins)}
\item[$\vec{D}$]{Vector of $D_j$ signifying mints accepted by a merchant} \item[$\vec{D}$]{Vector of $D_j$ signifying exchanges accepted by a merchant}
\item[$a$]{Complete text of a contract between customer and merchant} \item[$a$]{Complete text of a contract between customer and merchant}
\item[$f$]{Amount a customer agrees to pay to a merchant for a contract} \item[$f$]{Amount a customer agrees to pay to a merchant for a contract}
\item[$m$]{Unique transaction identifier chosen by the merchant} \item[$m$]{Unique transaction identifier chosen by the merchant}