\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename taler-exchange.info
@documentencoding UTF-8
@ifinfo
@*Generated by Sphinx 2.2.0.@*
@end ifinfo
@settitle Taler Exchange Manual
@defindex ge
@paragraphindent 0
@exampleindent 4
@finalout
@dircategory CATEGORY
@direntry
* MENU ENTRY: (taler-exchange.info). DESCRIPTION
@end direntry

@definfoenclose strong,`,'
@definfoenclose emph,`,'
@c %**end of header

@copying
@quotation
GNU Taler 0.6.0pre1, Dec 20, 2019

GNU Taler team

Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
@end quotation

@end copying

@titlepage
@title Taler Exchange Manual
@insertcopying
@end titlepage
@contents

@c %** start of user preamble

@c %** end of user preamble

@ifnottex
@node Top
@top Taler Exchange Manual
@insertcopying
@end ifnottex

@c %**start of body
@anchor{taler-exchange-manual doc}@anchor{0}
@menu
* Introduction:: 
* Installation:: 
* Configuration:: 
* Deployment:: 
* Diagnostics:: 

@detailmenu
 --- The Detailed Node Listing ---

Introduction

* About GNU Taler:: 
* About this manual:: 
* Organizational prerequisites:: 
* Architecture overview:: 

Configuration

* Configuration format:: 
* Using taler-config:: 
* Keying:: 
* Serving:: 
* Currency:: 
* Bank account:: 
* Database:: 
* Coins (denomination keys): Coins denomination keys. 
* Keys duration:: 
* Terms of Service:: 

Bank account

* Wire plugin “taler_bank”:: 
* Wire plugin “ebics”:: 
* Wire fee structure:: 

Terms of Service

* Example:: 

Deployment

* Keys generation:: 
* Database upgrades:: 

Diagnostics

* Reserve management:: 
* Database Scheme:: 
* Signing key storage:: 
* Denomination key storage:: 
* Auditor signature storage:: 

Denomination key storage

* Revocations:: 

@end detailmenu
@end menu

@node Introduction,Installation,Top,Top
@anchor{taler-exchange-manual gnu-taler-exchange-operator-manual}@anchor{1}@anchor{taler-exchange-manual introduction}@anchor{2}
@chapter Introduction


This manual is an early draft that still needs significant editing work
to become readable.

@menu
* About GNU Taler:: 
* About this manual:: 
* Organizational prerequisites:: 
* Architecture overview:: 

@end menu

@node About GNU Taler,About this manual,,Introduction
@anchor{taler-exchange-manual about-gnu-taler}@anchor{3}
@section About GNU Taler


GNU Taler is an open protocol for an electronic payment system with a
free software reference implementation. GNU Taler offers secure, fast
and easy payment processing using well understood cryptographic
techniques. GNU Taler allows customers to remain anonymous, while
ensuring that merchants can be held accountable by governments. Hence,
GNU Taler is compatible with anti-money-laundering (AML) and
know-your-customer (KYC) regulation, as well as data protection
regulation (such as GDPR).

GNU Taler is not yet production-ready, after following this manual you
will have a backend that can process payments in “KUDOS”, but not
regular currencies. This is not so much because of limitations in the
backend, but because we are not aware of a Taler exchange operator
offering regular currencies today.

@node About this manual,Organizational prerequisites,About GNU Taler,Introduction
@anchor{taler-exchange-manual about-this-manual}@anchor{4}
@section About this manual


This tutorial targets system administrators who want to install and
operate a GNU Taler exchange.

@node Organizational prerequisites,Architecture overview,About this manual,Introduction
@anchor{taler-exchange-manual organizational-prerequisites}@anchor{5}
@section Organizational prerequisites


Operating a GNU Taler exchange means that you are operating a payment
service provider, which means that you will most likely need a bank
license and/or follow applicable financial regulation.

GNU Taler payment service providers generally need to ensure high
availability and have @emph{really} good backups (synchronous replication,
asynchronous remote replication, off-site backup, 24/7 monitoring,
etc.). @footnote{@w{(1)} 
Naturally, you could operate a Taler exchange for a toy currency
without any real value on low-cost setups like a Raspberry Pi, but we
urge you to limit the use of such setups to research and education as
with GNU Taler data loss instantly results in financial losses.
} This manual will not cover these aspects of operating a
payment service provider.

We will assume that you can operate a (high-availability,
high-assurance) Postgres database. Furthermore, we expect some moderate
familiarity with the compilation and installation of free software
packages. You need to understand the cryptographic concepts of private
and public keys and must be able to protect private keys stored in files
on disk. An exchange uses an @emph{offline} master key as well as @emph{online}
keys. You are advised to secure your private master key and any copies
on encrypted, always-offline computers. Again, we assume that you are
familiar with good best practices in operational security, including
securing key material. @footnote{@w{(2)} 
The current implementation does not make provisions for secret
splitting. Still, the use of a hardware security module (HSM) for
protecting private keys is adviseable, so please contact the
developers for HSM integration support.
}

@node Architecture overview,,Organizational prerequisites,Introduction
@anchor{taler-exchange-manual architecture-overview}@anchor{6}
@section Architecture overview


Taler is a pure payment system, not a new crypto-currency. As such, it
operates in a traditional banking context. In particular, this means
that in order to receive funds via Taler, the merchant must have a
regular bank account, and payments can be executed in ordinary
currencies such as USD or EUR. Similarly, the Taler exchange must
interact with a bank. The bank of the exchange holds the exchange’s
funds in an escrow account.

When customers wire money to the escrow account, the bank notifies the
exchange about the incoming wire transfers. The exchange then creates a
@emph{reserve} based on the subject of the wire transfer. The wallet which
knows the secret key matching the wire transfer subject can then
withdraw coins from the reserve, thereby draining it. The liability of
the exchange against the reserve is thereby converted into a liability
against digital coins issued by the exchange. When the customer later
spends the coins at a merchant, and the merchant @emph{deposits} the coins at
the exchange, the exchange first @emph{aggregates} the amount from multiple
deposits from the same merchant and then instructs its bank to make a
wire transfer to the merchant, thereby fulfilling its obligation and
eliminating the liability. The exchange charges @emph{fees} for some or all
of its operations to cover costs and possibly make a profit.

@emph{Auditors} are third parties, for example financial regulators, that
verify that the exchange operates correctly. The same software is also
used to calculate the exchange’s profits, risk and liabilities by the
accountants of the exchange.

The Taler software stack for an exchange consists of the following
components:


@itemize -

@item 
HTTP frontend
The HTTP frontend interacts with Taler wallets and merchant backends.
It is used to withdraw coins, deposit coins, refresh coins, issue
refunds, map wire transfers to Taler transactions, inquire about the
exchange’s bank account details, signing keys and fee structure. The
binary is the @code{taler-exchange-httpd}.

@item 
Aggregator
The aggregator combines multiple deposits made by the same merchant
and (eventually) triggers wire transfers for the aggregate amount.
The merchant can control how quickly wire transfers are made. The
exchange may be charge a fee per wire transfer to discourage
excessively frequent transfers. The binary is the
@code{taler-exchange-aggregator}.

@item 
Auditor
The auditor verifies that the transactions performed by the exchange
were done properly. It checks the various signatures, totals up the
amounts and alerts the operator to any inconsistencies. It also
computes the expected bank balance, revenue and risk exposure of the
exchange operator. The main binary is the @code{taler-auditor}.

@item 
Wire plugin
A wire plugin enables the HTTP frontend to talk to the bank. Its role
is to allow the exchange to validate bank addresses (i.e. IBAN
numbers), for the aggregator to execute wire transfers and for the
auditor to query bank transaction histories. Wire plugins are
@emph{plugins} as there can be many different implementations to deal with
different banking standards. Wire plugins are automatically located
and used by the exchange, aggregator and auditor.

@item 
DBMS
Postgres
The exchange requires a DBMS to stores the transaction history for
the Taler exchange and aggregator, and a (typically separate) DBMS
for the Taler auditor. For now, the GNU Taler reference implemenation
only supports Postgres, but the code could be easily extended to
support another DBMS.
@end itemize

@node Installation,Configuration,Introduction,Top
@anchor{taler-exchange-manual installation}@anchor{7}
@chapter Installation


Please install the following packages before proceeding with the
exchange compilation.


@itemize -

@item 
GNU autoconf >= 2.69

@item 
GNU automake >= 1.14

@item 
GNU libtool >= 2.4

@item 
GNU autopoint >= 0.19

@item 
GNU libltdl >= 2.4

@item 
GNU libunistring >= 0.9.3

@item 
libcurl >= 7.26 (or libgnurl >= 7.26)

@item 
GNU libmicrohttpd >= 0.9.59

@item 
GNU libgcrypt >= 1.6

@item 
libjansson >= 2.7

@item 
Postgres >= 9.6, including libpq

@item 
libgnunetutil (from Git)

@item 
GNU Taler exchange (from Git)
@end itemize

Except for the last two, these are available in most GNU/Linux
distributions and should just be installed using the respective package
manager.

The following instructions will show how to install libgnunetutil and
the GNU Taler exchange.

Before you install libgnunetutil, you must download and install the
dependencies mentioned above, otherwise the build may succeed but fail
to export some of the tooling required by Taler.

To download and install libgnunetutil, proceed as follows:

@example
$ git clone https://git.gnunet.org/gnunet/
$ cd gnunet/
$ ./bootstrap
$ ./configure [--prefix=GNUNETPFX]
$ # Each dependency can be fetched from non standard locations via
$ # the '--with-<LIBNAME>' option. See './configure --help'.
$ make
# make install
@end example

If you did not specify a prefix, GNUnet will install to @code{/usr/local},
which requires you to run the last step as @code{root}.

To download and install the GNU Taler exchange, proceeds as follows:

@example
$ git clone git://git.taler.net/exchange
$ cd exchange
$ ./bootstrap
$ ./configure [--prefix=EXCHANGEPFX] \
              [--with-gnunet=GNUNETPFX]
$ # Each dependency can be fetched from non standard locations via
$ # the '--with-<LIBNAME>' option. See './configure --help'.
$ make
# make install
@end example

If you did not specify a prefix, the exchange will install to
@code{/usr/local}, which requires you to run the last step as @code{root}.
Note that you have to specify @code{--with-gnunet=/usr/local} if you
installed GNUnet to @code{/usr/local} in the previous step.

@node Configuration,Deployment,Installation,Top
@anchor{taler-exchange-manual configuration}@anchor{8}
@chapter Configuration


This chapter provides an overview of the exchange configuration. Or at
least eventually will do so, for now it is a somewhat wild description
of some of the options.

@menu
* Configuration format:: 
* Using taler-config:: 
* Keying:: 
* Serving:: 
* Currency:: 
* Bank account:: 
* Database:: 
* Coins (denomination keys): Coins denomination keys. 
* Keys duration:: 
* Terms of Service:: 

@end menu

@node Configuration format,Using taler-config,,Configuration
@anchor{taler-exchange-manual configuration-format}@anchor{9}
@section Configuration format


In Taler realm, any component obeys to the same pattern to get
configuration values. According to this pattern, once the component has
been installed, the installation deploys default values in
$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
these defaults, the user can write a custom .conf file and either pass
it to the component at execution time, or name it taler.conf and place
it under $HOME/.config/.

A config file is a text file containing sections, and each section
contains its values. The right format follows:

@example
[section1]
value1 = string
value2 = 23

[section2]
value21 = string
value22 = /path22
@end example

Throughout any configuration file, it is possible to use @code{$}-prefixed
variables, like @code{$VAR}, especially when they represent filesystem
paths. It is also possible to provide defaults values for those
variables that are unset, by using the following syntax:
@code{$@{VAR:-default@}}. However, there are two ways a user can set
@code{$}-prefixable variables:

by defining them under a @code{[paths]} section, see example below,

@example
[paths]
TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
..
[section-x]
path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
@end example

or by setting them in the environment:

@example
$ export VAR=/x
@end example

The configuration loader will give precedence to variables set under
@code{[path]}, though.

The utility @code{taler-config}, which gets installed along with the
exchange, serves to get and set configuration values without directly
editing the .conf. The option @code{-f} is particularly useful to resolve
pathnames, when they use several levels of @code{$}-expanded variables. See
@code{taler-config --help}.

Note that, in this stage of development, the file
@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
component. For example, both an exchange and a bank can read values from
it.

The repository @code{git://taler.net/deployment} contains examples of
configuration file used in our demos. See under @code{deployment/config}.

@quotation

@strong{Note}

Expectably, some components will not work just by using default
values, as their work is often interdependent. For example, a
merchant needs to know an exchange URL, or a database name.
@end quotation

@node Using taler-config,Keying,Configuration format,Configuration
@anchor{taler-exchange-manual using-taler-002dconfig-exchange}@anchor{a}@anchor{taler-exchange-manual using-taler-config}@anchor{b}
@section Using taler-config


The tool @code{taler-config} can be used to extract or manipulate
configuration values; however, the configuration use the well-known INI
file format and can also be edited by hand.

Run

@example
$ taler-config -s $SECTION
@end example

to list all of the configuration values in section @code{$SECTION}.

Run

@example
$ taler-config -s $section -o $option
@end example

to extract the respective configuration value for option @code{$option} in
section @code{$section}.

Finally, to change a setting, run

@example
$ taler-config -s $section -o $option -V $value
@end example

to set the respective configuration value to @code{$value}. Note that you
have to manually restart the Taler backend after you change the
configuration to make the new configuration go into effect.

Some default options will use $-variables, such as @code{$DATADIR} within
their value. To expand the @code{$DATADIR} or other $-variables in the
configuration, pass the @code{-f} option to @code{taler-config}. For example,
compare:

@example
$ taler-config -s ACCOUNT-bank \
               -o WIRE_RESPONSE
$ taler-config -f -s ACCOUNT-bank \
               -o WIRE_RESPONSE
@end example

While the configuration file is typically located at
@code{$HOME/.config/taler.conf}, an alternative location can be specified
to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
option.

@node Keying,Serving,Using taler-config,Configuration
@anchor{taler-exchange-manual id3}@anchor{c}@anchor{taler-exchange-manual keying}@anchor{d}
@section Keying


The exchange works with three types of keys:


@itemize -

@item 
master key

@item 
sign keys

@item 
denomination keys (see section Coins)

@item 
MASTER_PRIV_FILE: Path to the exchange’s master private file.

@item 
MASTER_PUBLIC_KEY: Must specify the exchange’s master public key.
@end itemize

@node Serving,Currency,Keying,Configuration
@anchor{taler-exchange-manual id4}@anchor{e}@anchor{taler-exchange-manual serving}@anchor{f}
@section Serving


The exchange can serve HTTP over both TCP and UNIX domain socket.

The following values are to be configured in the section [exchange]:


@itemize -

@item 
serve: must be set to tcp to serve HTTP over TCP, or unix to serve
HTTP over a UNIX domain socket

@item 
port: Set to the TCP port to listen on if serve Is tcp.

@item 
unixpath: set to the UNIX domain socket path to listen on if serve Is
unix

@item 
unixpath_mode: number giving the mode with the access permission MASK
for the unixpath (i.e. 660 = rw-rw—-).
@end itemize

@node Currency,Bank account,Serving,Configuration
@anchor{taler-exchange-manual currency}@anchor{10}@anchor{taler-exchange-manual id5}@anchor{11}
@section Currency


The exchange supports only one currency. This data is set under the
respective option currency in section [taler].

@node Bank account,Database,Currency,Configuration
@anchor{taler-exchange-manual bank-account}@anchor{12}@anchor{taler-exchange-manual id6}@anchor{13}
@section Bank account


To configure a bank account in Taler, we need to furnish four pieces of
information:


@itemize -

@item 
The @code{payto://} URL of the bank account, which uniquely idenfies the
account. Examples for such URLs include
@code{payto://sepa/CH9300762011623852957} for a bank account in the
single European payment area (SEPA) or
@code{payto://x-taler-bank/localhost:8080/2} for the 2nd bank account a
the Taler bank demonstrator running at @code{localhost} on port 8080.
The first part of the URL following @code{payto://} (“sepa” or
“x-taler-bank”) is called the wire method.

@item 
A matching wire plugin that implements a protocol to interact with
the banking system. For example, the EBICS plugin can be used for
SEPA transfers, or the “taler-bank” plugin can interact with the
Taler bank demonstrator. A wire plugin only supports one particular
wire method. Thus, you must make sure to pick a plugin that supports
the wire method used in the URL.

@item 
A file containing the signed JSON-encoded bank account details for
the /wire API. This is necessary as Taler supports offline signing
for bank accounts for additional security.

@item 
Finally, the plugin needs to be provided resources for authentication
to the respective banking service. The format in which the
authentication information must be provided depends on the wire
plugin.
@end itemize

You can configure multiple accounts for an exchange by creating sections
starting with “account-” for the section name. You can ENABLE for each
account whether it should be used, and for what (incoming or outgoing
wire transfers):

@example
[account-1]
URL = "payto://sepa/CH9300762011623852957"
WIRE_RESPONSE = $@{TALER_CONFIG_HOME@}/account-1.json

# Currently, only the 'taler_bank' plugin is implemented.
PLUGIN = <plugin_name_here>

# Use for exchange-aggregator (outgoing transfers)
ENABLE_DEBIT = YES
# Use for exchange-wirewatch (and listed in /wire)
ENABLE_CREDIT = YES

# Authentication options for the chosen plugin go here.
# (Next sections have examples of authentication mechanisms)
@end example

The command line tool taler-exchange-wire is used to create the
@code{account-1.json} file. For example, the utility may be invoked as
follows to create all of the WIRE_RESPONSE files (in the locations
specified by the configuration):

@example
$ taler-exchange-wire
@end example

The generated file will be echoed by the exchange when serving
/wire @footnote{@w{(3)} 
@indicateurl{https://api.taler.net/api-exchange.html#wire-req}
} requests.

@menu
* Wire plugin “taler_bank”:: 
* Wire plugin “ebics”:: 
* Wire fee structure:: 

@end menu

@node Wire plugin “taler_bank”,Wire plugin “ebics”,,Bank account
@anchor{taler-exchange-manual wire-plugin-0060-0060taler-005fbank-0027-0027}@anchor{14}@anchor{taler-exchange-manual wire-plugin-taler-bank}@anchor{15}
@subsection Wire plugin “taler_bank”


x-taler-bank
taler_bank plugin
The @code{taler_bank} plugin implements the wire method “x-taler-bank”.

The format of the @code{payto://} URL is
@code{payto://x-taler-bank/HOSTNAME[:PORT]}.

For basic authentication, the @code{taler_bank} plugin only supports simple
password-based authentication. For this, the configuration must contain
the “USERNAME” and “PASSWORD” of the respective account at the bank.

@example
[account-1]

# Bank account details here..
# ..

# Authentication options for the taler_bank plugin below:

TALER_BANK_AUTH_METHOD = basic
USERNAME = exchange
PASSWORD = super-secure
@end example

@node Wire plugin “ebics”,Wire fee structure,Wire plugin “taler_bank”,Bank account
@anchor{taler-exchange-manual wire-plugin-0060-0060ebics-0027-0027}@anchor{16}@anchor{taler-exchange-manual wire-plugin-ebics}@anchor{17}
@subsection Wire plugin “ebics”


The “ebics” wire plugin is not fully implemented and today does not
support actual wire transfers.

@quotation

@strong{Note}

The rationale behind having multiple bank accounts is that the
exchange operator, as a security measure, may want to instruct the
bank that the incoming bank account is only supposed to @emph{receive}
money.
@end quotation

@node Wire fee structure,,Wire plugin “ebics”,Bank account
@anchor{taler-exchange-manual id8}@anchor{18}@anchor{taler-exchange-manual wire-fee-structure}@anchor{19}
@subsection Wire fee structure


wire fee
fee
For each wire method (“sepa” or “x-taler-wire”, but not per plugin!) the
exchange configuration must specify applicable wire fees. This is done
in configuration sections of the format @code{fees-METHOD}. There are two
types of fees, simple wire fees and closing fees. Wire fees apply
whenever the aggregator transfers funds to a merchant. Closing fees
apply whenever the exchange closes a reserve (sending back funds to the
customer). The fees must be constant for a full year, which is specified
as part of the name of the option.

@example
[fees-iban]
WIRE-FEE-2018 = EUR:0.01
WIRE-FEE-2019 = EUR:0.01
CLOSING-FEE-2018 = EUR:0.01
CLOSING-FEE-2019 = EUR:0.01

[fees-x-taler-bank]
WIRE-FEE-2018 = KUDOS:0.01
WIRE-FEE-2019 = KUDOS:0.01
CLOSING-FEE-2018 = KUDOS:0.01
CLOSING-FEE-2019 = KUDOS:0.01
@end example

@node Database,Coins denomination keys,Bank account,Configuration
@anchor{taler-exchange-manual database}@anchor{1a}@anchor{taler-exchange-manual id9}@anchor{1b}
@section Database


The option db under section [exchange] gets the DB backend’s name the
exchange is going to use. So far, only db = postgres is supported. After
choosing the backend, it is mandatory to supply the connection string
(namely, the database name). This is possible in two ways:


@itemize -

@item 
via an environment variable: TALER_EXCHANGEDB_POSTGRES_CONFIG.

@item 
via configuration option CONFIG, under section [exchangedb-BACKEND].
For example, the demo exchange is configured as follows:
@end itemize

@example
[exchange]
...
DB = postgres
...

[exchangedb-postgres]
CONFIG = postgres:///talerdemo
@end example

@node Coins denomination keys,Keys duration,Database,Configuration
@anchor{taler-exchange-manual coins-denomination-keys}@anchor{1c}@anchor{taler-exchange-manual id10}@anchor{1d}
@section Coins (denomination keys)


Sections specifying denomination (coin) information start with @code{coin_}.
By convention, the name continues with “$CURRENCY_[$SUBUNIT]_$VALUE”,
i.e. @code{[coin_eur_ct_10]} for a 10 cent piece. However, only the @code{coin_}
prefix is mandatory. Each @code{coin_}-section must then have the following
options:


@itemize -

@item 
value: How much is the coin worth, the format is
CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is “EUR:0.10”.

@item 
duration_withdraw: How long can a coin of this type be withdrawn?
This limits the losses incurred by the exchange when a denomination
key is compromised.

@item 
duration_overlap: What is the overlap of the withdrawal timespan for
this coin type?

@item 
duration_spend: How long is a coin of the given type valid? Smaller
values result in lower storage costs for the exchange.

@item 
fee_withdraw: What does it cost to withdraw this coin? Specified
using the same format as value.

@item 
fee_deposit: What does it cost to deposit this coin? Specified using
the same format as value.

@item 
fee_refresh: What does it cost to refresh this coin? Specified using
the same format as value.

@item 
rsa_keysize: How many bits should the RSA modulus (product of the two
primes) have for this type of coin.
@end itemize

@node Keys duration,Terms of Service,Coins denomination keys,Configuration
@anchor{taler-exchange-manual id11}@anchor{1e}@anchor{taler-exchange-manual keys-duration}@anchor{1f}
@section Keys duration


Both signkeys and denom keys have a starting date. The option
lookahead_provide, under section [exchange], is such that only keys
whose starting date is younger than lookahead_provide will be issued by
the exchange.

signkeys. The option lookahead_sign is such that, being t the time when
taler-exchange-keyup is run, taler-exchange-keyup will generate n
signkeys, where t + (n * signkey_duration) = t + lookahead_sign. In
other words, we generate a number of keys which is sufficient to cover a
period of lookahead_sign. As for the starting date, the first generated
key will get a starting time of t, and the j-th key will get a starting
time of x + signkey_duration, where x is the starting time of the
(j-1)-th key.

denom keys. The option lookahead_sign is such that, being t the time
when taler-exchange-keyup is run, taler-exchange-keyup will generate n
denom keys for each denomination, where t + (n * duration_withdraw) = t
+ lookahead_sign. In other words, for each denomination, we generate a
number of keys which is sufficient to cover a period of lookahead_sign.
As for the starting date, the first generated key will get a starting
time of t, and the j-th key will get a starting time of x +
duration_withdraw, where x is the starting time of the (j-1)-th key.

To change these settings, edit the following values in section
[exchange]:


@itemize -

@item 
SIGNKEY_DURATION: How long should one signing key be used?

@item 
LOOKAHEAD_SIGN: How much time we want to cover with our signing keys?
Note that if SIGNKEY_DURATION is bigger than LOOKAHEAD_SIGN,
@code{taler-exchange-keyup} will generate a quantity of signing keys
which is sufficient to cover all the gap.
@end itemize

@node Terms of Service,,Keys duration,Configuration
@anchor{taler-exchange-manual terms-of-service}@anchor{20}
@section Terms of Service


The exchange has an endpoint “/terms” to return the terms of service
(in legal language) of the exchange operator.  The wallet will show
those terms of service to the user when the user is first withdrawing
coins.  Terms of service are optional for experimental deployments,
if none are configured, the exchange will return a simple statement
saying that there are no terms of service available.

To configure the terms of service response, there are two options
in the [exchange] section:


@itemize -

@item 
TERMS_ETAG: The current “Etag” to return for the terms of service.
This value must be changed whenever the terms of service are
updated. A common value to use would be a version number.
Note that if you change the TERMS_ETAG, you MUST also provide
the respective files in TERMS_DIR (see below).

@item 
TERMS_DIR: The directory that contains the terms of service.
The files in the directory must be readable to the exchange
process.
@end itemize

The TERMS_DIR directory structure must follow a particular layout.
First, inside of TERMS_DIR, there should be sub-directories using
two-letter language codes like “en”, “de”, or “jp”.  Each of these
directories would then hold translations of the current terms of
service into the respective language.  Empty directories are
permitted in case translations are not available.

Then, inside each language directory, files with the name of the
value set as the TERMS_ETAG must be provided. The extension of
each of the files should be typical for the respective mime type.
The set of supported mime types is currently hard-coded in the
exchange, and includes HTML, PDF and TXT files. If other files are
present, the exchange may show a warning on startup.

@menu
* Example:: 

@end menu

@node Example,,,Terms of Service
@anchor{taler-exchange-manual example}@anchor{21}
@subsection Example


A sample file structure for a TERMS_ETAG of “v1” would be:


@itemize -

@item 
TERMS_DIR/en/v1.txt

@item 
TERMS_DIR/en/v1.html

@item 
TERMS_DIR/en/v1.pdf

@item 
TERMS_DIR/de/v1.txt

@item 
TERMS_DIR/de/v1.html

@item 
TERMS_DIR/de/v1.pdf

@item 
TERMS_DIR/fr/v1.pdf
@end itemize

If the user requests an HTML with language preferences “fr” followed by “en”,
the exchange would return “TERMS_DIR/en/v1.html” lacking an HTML version in
French.

@node Deployment,Diagnostics,Configuration,Top
@anchor{taler-exchange-manual deployment}@anchor{22}@anchor{taler-exchange-manual id12}@anchor{23}
@chapter Deployment


This chapter describes how to deploy the exchange once it has been
properly configured.

@menu
* Keys generation:: 
* Database upgrades:: 

@end menu

@node Keys generation,Database upgrades,,Deployment
@anchor{taler-exchange-manual id13}@anchor{24}@anchor{taler-exchange-manual keys-generation}@anchor{25}
@section Keys generation


Once the configuration is properly set up, all the keys can be generated
by the tool @code{taler-exchange-keyup}. The following command generates
denomkeys and signkeys, plus the “blob” that is to be signed by the
auditor.

@example
taler-exchange-keyup -o blob
@end example

@emph{blob} contains data about denomkeys that the exchange operator needs to
get signed by every auditor he wishes (or is forced to) work with.

In a normal scenario, an auditor must have some way of receiving the
blob to sign (Website, manual delivery, ..). Nonetheless, the exchange
admin can fake an auditor signature — for testing purposes — by running
the following command

@example
taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o OUTPUT_FILE
@end example

Those arguments are all mandatory.


@itemize -

@item 
@code{EXCHANGE_MASTER_PUB} the base32 Crockford-encoded exchange’s
master public key. Tipically, this value lies in the configuration
option @code{[exchange]/master_public_key}.

@item 
@code{BLOB} the blob generated in the previous step.

@item 
@code{AUDITOR_URL} the URL that identifies the auditor.

@item 
@code{OUTPUT_FILE} where on the disk the signed blob is to be saved.
@end itemize

@code{OUTPUT_FILE} must then be copied into the directory specified by the
option @code{AUDITOR_BASE_DIR} under the section @code{[exchangedb]}. Assuming
@code{AUDITOR_BASE_DIR = $@{HOME@}/.local/share/taler/auditors}, the
following command will “add” the auditor identified by @code{AUDITOR_URL}
to the exchange.

@example
cp OUTPUT_FILE $@{HOME@}/.local/share/taler/auditors
@end example

If the auditor has been correctly added, the exchange’s @code{/keys}
response must contain an entry in the @code{auditors} array mentioning the
auditor’s URL.

@node Database upgrades,,Keys generation,Deployment
@anchor{taler-exchange-manual database-upgrades}@anchor{26}@anchor{taler-exchange-manual id14}@anchor{27}
@section Database upgrades


Currently, there is no way to upgrade the database between Taler
versions.

The exchange database can be re-initialized using:

@example
$ taler-exchange-dbinit -r
@end example

However, running this command will result in all data in the database
being lost, which may result in significant financial liabilities as the
exchange can then not detect double-spending. Hence this operation must
not be performed in a production system.

@node Diagnostics,,Deployment,Top
@anchor{taler-exchange-manual diagnostics}@anchor{28}@anchor{taler-exchange-manual id15}@anchor{29}
@chapter Diagnostics


This chapter includes various (very unpolished) sections on specific
topics that might be helpful to understand how the exchange operates,
which files should be backed up. The information may also be helpful for
diagnostics.

@menu
* Reserve management:: 
* Database Scheme:: 
* Signing key storage:: 
* Denomination key storage:: 
* Auditor signature storage:: 

@end menu

@node Reserve management,Database Scheme,,Diagnostics
@anchor{taler-exchange-manual id16}@anchor{2a}@anchor{taler-exchange-manual reserve-management}@anchor{2b}
@section Reserve management


Incoming transactions to the exchange’s provider result in the creation
or update of reserves, identified by their reserve key. The command line
tool taler-exchange-reservemod allows create and add money to reserves
in the exchange’s database.

@node Database Scheme,Signing key storage,Reserve management,Diagnostics
@anchor{taler-exchange-manual database-scheme}@anchor{2c}@anchor{taler-exchange-manual id17}@anchor{2d}
@section Database Scheme


The exchange database must be initialized using taler-exchange-dbinit.
This tool creates the tables required by the Taler exchange to operate.
The tool also allows you to reset the Taler exchange database, which is
useful for test cases but should never be used in production. Finally,
taler-exchange-dbinit has a function to garbage collect a database,
allowing administrators to purge records that are no longer required.

The database scheme used by the exchange look as follows:

@image{taler-exchange-figures/exchange-db,,,,png}

@node Signing key storage,Denomination key storage,Database Scheme,Diagnostics
@anchor{taler-exchange-manual id18}@anchor{2e}@anchor{taler-exchange-manual signing-key-storage}@anchor{2f}
@section Signing key storage


The private online signing keys of the exchange are stored in a
subdirectory “signkeys/” of the “KEYDIR” which is an option in the
“[exchange]” section of the configuration file. The filename is the
starting time at which the signing key can be used in microseconds since
the Epoch. The file format is defined by the struct
TALER_EXCHANGEDB_PrivateSigningKeyInformationP:

@example
struct TALER_EXCHANGEDB_PrivateSigningKeyInformationP @{
   struct TALER_ExchangePrivateKeyP signkey_priv;
   struct TALER_ExchangeSigningKeyValidityPS issue;
@};
@end example

@node Denomination key storage,Auditor signature storage,Signing key storage,Diagnostics
@anchor{taler-exchange-manual denomination-key-storage}@anchor{30}@anchor{taler-exchange-manual id19}@anchor{31}
@section Denomination key storage


The private denomination keys of the exchange are store in a
subdirectory “denomkeys/” of the “KEYDIR” which is an option in the
“[exchange]” section of the configuration file. “denomkeys/” contains
further subdirectories, one per denomination. The specific name of the
subdirectory under “denomkeys/” is ignored by the exchange. However, the
name is important for the “taler-exchange-keyup” tool that generates the
keys. The tool combines a human-readable encoding of the denomination
(i.e. for EUR:1.50 the prefix would be “EUR_1_5-“, or for EUR:0.01 the
name would be “EUR_0_01-“) with a postfix that is a truncated
Crockford32 encoded hash of the various attributes of the denomination
key (relative validity periods, fee structure and key size). Thus, if
any attributes of a coin change, the name of the subdirectory will also
change, even if the denomination remains the same.

Within this subdirectory, each file represents a particular denomination
key. The filename is the starting time at which the signing key can be
used in microseconds since the Epoch. The format on disk begins with a
struct TALER_EXCHANGEDB_DenominationKeyInformationP giving the
attributes of the denomination key and the associated signature with the
exchange’s long-term offline key:

@example
struct TALER_EXCHANGEDB_DenominationKeyInformationP @{
  struct TALER_MasterSignatureP signature;
  struct TALER_DenominationKeyValidityPS properties;
@};
@end example

This is then followed by the variable-size RSA private key in
libgcrypt’s S-expression format, which can be decoded using
GNUNET_CRYPTO_rsa_private_key_decode().

@menu
* Revocations:: 

@end menu

@node Revocations,,,Denomination key storage
@anchor{taler-exchange-manual id20}@anchor{32}@anchor{taler-exchange-manual revocations}@anchor{33}
@subsection Revocations


When an exchange goes out of business or detects that the private key of
a denomination key pair has been compromised, it may revoke some or all
of its denomination keys. At this point, the hashes of the revoked keys
must be returned as part of the @code{/keys} response under “payback”.
Wallets detect this, and then return unspent coins of the respective
denomination key using the @code{/payback} API.

When a denomination key is revoked, a revocation file is placed into the
respective subdirectory of “denomkeys/”. The file has the same prefix as
the file that stores the struct
TALER_EXCHANGEDB_DenominationKeyInformationP information, but is
followed by the “.rev” suffix. It contains a 64-byte EdDSA signature
made with the master key of the exchange with purpose
@code{TALER_SIGNATURE_MASTER_DENOMINATION_KEY_REVOKED}. If such a file is
present, the exchange must check the signature and if it is valid treat
the respective denomination key as revoked.

Revocation files can be generated using the @code{taler-exchange-keyup}
command-line tool using the @code{-r} option. The Taler auditor will
instruct operators to generate revocations if it detects a key
compromise (which is possible more coins of a particular denomination
were deposited than issued).

It should be noted that denomination key revocations should only happen
under highly unusual (“emergency”) conditions and not under normal
conditions.

@node Auditor signature storage,,Denomination key storage,Diagnostics
@anchor{taler-exchange-manual auditor-signature-storage}@anchor{34}@anchor{taler-exchange-manual id21}@anchor{35}
@section Auditor signature storage


Signatures from auditors are stored in the directory specified in the
exchange configuration section “exchangedb” under the option
“AUDITOR_BASE_DIR”. The exchange does not care about the specific names
of the files in this directory.

Each file must contain a header with the public key information of the
auditor, the master public key of the exchange, and the number of signed
denomination keys:

@example
struct AuditorFileHeaderP @{
  struct TALER_AuditorPublicKeyP apub;
  struct TALER_MasterPublicKeyP mpub;
  uint32_t dki_len;
@};
@end example

This is then followed by dki_len signatures of the auditor of type
struct TALER_AuditorSignatureP, which are then followed by another
dki_len blocks of type struct TALER_DenominationKeyValidityPS. The
auditor’s signatures must be signatures over the information of the
corresponding denomination key validity structures embedded in a struct
TALER_ExchangeKeyValidityPS structure using the
TALER_SIGNATURE_AUDITOR_EXCHANGE_KEYS purpose.

@c %**end of body
@bye