\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename taler-exchange.info
@documentencoding UTF-8
@ifinfo
@*Generated by Sphinx 8.1.3.@*
@end ifinfo
@settitle Taler Exchange Manual
@defindex ge
@paragraphindent 0
@exampleindent 4
@finalout
@dircategory Network applications
@direntry
* GNU Taler Exchange: (taler-exchange.info). Taler payment service provider
@end direntry

@c %**end of header

@copying
@quotation
GNU Taler 1.0.0, May 09, 2025

GNU Taler team

Copyright @copyright{} 2014-2025 Taler Systems SA (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}
@c This file is part of GNU TALER.
@c 
@c Copyright (C) 2014-2024 Taler Systems SA
@c 
@c TALER is free software; you can redistribute it and/or modify it under the
@c terms of the GNU Affero General Public License as published by the Free Software
@c Foundation; either version 2.1, or (at your option) any later version.
@c 
@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
@c 
@c You should have received a copy of the GNU Affero General Public License along with
@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
@c 
@c @author Christian Grothoff
@c @author Florian Dold

@menu
* Introduction:: 
* Installation:: 
* Configuration Fundamentals:: 
* Exchange Database Setup:: 
* Basic Setup; Currency@comma{} Denominations and Keys: Basic Setup Currency Denominations and Keys. 
* Wire Gateway Setup:: 
* Deployment:: 
* Offline Signing Setup@comma{} Key Maintenance and Tear-Down: Offline Signing Setup Key Maintenance and Tear-Down. 
* Setup Linting:: 
* Testing and Troubleshooting:: 
* Benchmarking:: 
* FIXMEs:: 
* Index:: 

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

Introduction

* About GNU Taler:: 
* About this manual:: 
* Organizational prerequisites:: 
* Architecture overview:: 
* Key Types:: 
* Offline keys:: 
* Online signing key security:: 

Online signing key security

* Functionality:: 
* Security goals:: 
* Setup:: 
* Configuration:: 

Installation

* Before you start:: 
* Installing from source:: 
* Installing the GNU Taler binary packages on Debian:: 
* Installing the GNU Taler binary packages on Trisquel:: 
* Installing the GNU Taler binary packages on Ubuntu:: 
* Services@comma{} users@comma{} groups and file system hierarchy: Services users groups and file system hierarchy. 

Configuration Fundamentals

* Configuration format:: 

Basic Setup: Currency, Denominations and Keys

* Coins (denomination keys): Coins denomination keys. 
* Sign keys:: 
* Setting up the offline signing key:: 

Wire Gateway Setup

* Exchange Bank Account Configuration:: 

Deployment

* Serving:: 
* Reverse Proxy Setup:: 
* Launching an exchange:: 

Offline Signing Setup, Key Maintenance and Tear-Down

* Signing the online signing keys:: 
* Account signing:: 
* Wire fee structure:: 
* Auditor configuration:: 
* Revocations:: 

Testing and Troubleshooting

* taler-exchange-config:: 
* Using taler-*-config:: 
* Private key storage:: 
* Internal audits:: 
* Database Scheme:: 
* Database upgrades:: 

Benchmarking

* Choosing a bank:: 
* taler-bank-benchmark:: 
* taler-exchange-benchmark:: 
* taler-aggregator-benchmark:: 

@end detailmenu
@end menu

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


@menu
* About GNU Taler:: 
* About this manual:: 
* Organizational prerequisites:: 
* Architecture overview:: 
* Key Types:: 
* Offline keys:: 
* Online signing key security:: 

@end menu

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


@c This file is part of GNU TALER.
@c 
@c Copyright (C) 2014-2023 Taler Systems SA
@c 
@c TALER is free software; you can redistribute it and/or modify it under the
@c terms of the GNU Affero General Public License as published by the Free Software
@c Foundation; either version 2.1, or (at your option) any later version.
@c 
@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
@c 
@c You should have received a copy of the GNU Affero General Public License along with
@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>

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).

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


This manual 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. The Exchange KYC/AML Operator
Manual goes into depth for how an exchange can be
configured for compliance.  Exceptions to compliance rules may apply,
especially if you are operating a regional currency or a payment system for an
event with a closed user group.  If in doubt, please contact a competent
lawyer in your country about the legality of operating a GNU Taler exchange.

GNU Taler payment service providers generally need to ensure high availability
and should have `really' good backups (synchronous replication, asynchronous
remote replication, off-site backup, 24/7 monitoring, etc.).  This manual will
not cover these aspects of operating a payment service provider.

We will assume that you can operate a (sufficiently high-availability,
high-assurance) PostgreSQL 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.

@cartouche
@quotation Note 
Taler may store sensitive business and customer data in the database.  Any
operator SHOULD thus ensure that backup operations are encrypted and
secured from unauthorized access.
@end quotation
@end cartouche

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


GNU Taler is a pure payment system, not a crypto-currency. As such, it
operates in a traditional banking context. In particular, this means that
payments can be executed in ordinary currencies such as USD or EUR.
Furthermore, a typical merchant in Taler has a regular bank account, and would
use it to receive funds via Taler.

Consequently, a typical Taler exchange must interact with a bank. The bank of
the exchange holds funds in an account where the balance is basically
equivalent to the value of all coins in circulation. (Small mismatches arise
whenever customers are about to withdraw coins and have already send the funds
into the bank account, or if merchants just deposited coins and are about to
receive wire transfers for deposited coins, or due to fees charged by the
exchange and the operator not yet having drained the fees from the account.)

The exchange uses an intermediary system to talk to its bank.  This shifts the
technical burden (XML-based communications, additional cryptography, and a
vast variety of standards) for this interaction into another bank-specific
subsystem.  Such intermediary system abstracts the native banking protocol by
exposing the `Taler Wire Gateway API'; this way, the exchange can conduct its
banking operations in a simplified and JSON-based style.

When customers wire money to the exchange's bank account, the Taler Wire
Gateway API must notify the exchange about the incoming wire transfers. The
exchange then creates a `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 `deposits' the coins at
the exchange, the exchange first `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 `fees' for some or all of its operations
to cover costs and possibly make a profit.

`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 
`Crypto-Helpers':
The @code{taler-exchange-secmod-rsa}, @code{taler-exchange-secmod-cs} and
@code{taler-exchange-secmod-eddsa}
are three programs that are responsible for managing the exchange's
online signing keys. They must run on the same machine as the
@code{taler-exchange-httpd} as the HTTP frontend communicates with the
crypto helpers using UNIX Domain Sockets.

@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 charge a fee per wire transfer to discourage
excessively frequent transfers. The binary is the
@code{taler-exchange-aggregator}.

@item 
`Closer':
The @code{taler-exchange-closer} tool check that reserves are properly
closed. If a customer wires funds to an exchange and then fails
to withdraw them, the closer will (eventually) trigger a wire
transfer that sends the customer's funds back to the originating
wire account.

@item 
`Transfer':
The @code{taler-exchange-transfer} tool is responsible for actually
executing the aggregated wire transfers. It is the only process
that needs to have the credentials to execute outgoing wire
transfers.  The tool uses the Taler Wire Gateway API to execute
wire transfers.  This API is provided by the Taler Python Bank
for stand-alone deployments (like those with @code{KUDOS}) and
by LibEuFin.  LibEuFin is an adapter which maps the Taler Wire
REST API to traditional banking protocols like EBICS and FinTS.

@item 
`Wirewatch':
The @code{taler-exchange-wirewatch} tool is responsible for observing
incoming wire transfers to the exchange. It needs to have the
credentials to obtain a list of incoming wire transfers.
The tool also uses the Taler Wire Gateway API to observe such
incoming transfers.  It is possible that observing incoming and
making outgoing wire transfers is done via different bank accounts
and/or credentials.

@item 
`Wire adapter':
A wire adapter is a component that enables exchange to talk to a bank.
Each wire adapter must implement the Taler Wire Gateway API.  Three
wire adapters are currently provided:


@enumerate 

@item 
The `libtalerfakebank' implements a bank with a wire adapter API
inside of a testcase.  @code{taler-fakebank-run} is a stand-alone
process using libtalerfakebank.  Note that this adapter is only
useful for tests, as all transaction data is kept in memory.

@item 
For production, `libeufin''s @code{libeufin-nexus} component
implements a wire adapter towards the traditional SEPA banking
system with IBAN accounts using the EBICS protocol.

@item 
To use GNU Taler with blockchains, the `Depolymerization'
component provides a wire gateway API that runs on top of
blockchains like Bitcoin and Ethereum.
@end enumerate

The client-side wire adapter API is implemented in `libtalerbank' and
is used by @code{taler-exchange-transfer} to execute wire transfers and by
@code{taler-exchange-wirewatch} and the Taler auditor auditor to query bank
transaction histories.

@item 
`DBMS':
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 implementation
only supports PostgreSQL, but the code could be easily extended to
support another DBMS.
.. index:: PostgreSQL

@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}.
Aside from the key setup procedures, the most critical setup for
deploying an auditor is providing the auditor with an up-to-date
copy of the exchange's database.
@end itemize

@node Key Types,Offline keys,Architecture overview,Introduction
@anchor{taler-exchange-manual key-types}@anchor{7}@anchor{taler-exchange-manual keytypes}@anchor{8}
@section Key Types


The exchange works with four types of keys:


@itemize -

@item 
master key (kept offline, configured manually at merchants and wallets)

@item 
online message signing keys (signs normal messages from the exchange)

@item 
denomination keys (signs digital coins)

@item 
security module keys (signs online message signing keys and denomination keys)
@end itemize

Additionally, the exchange is sometimes concerned with the auditor's public
key (to verify messages signed by auditors approved by the exchange operator)
and the merchant's public key (to verify refunds are authorized by the
merchant).

Most of the keys are managed fully automatically or configured as part of the
denomination configuration.  Some configuration settings must be manually
set with regards to the exchange's master key.

@node Offline keys,Online signing key security,Key Types,Introduction
@anchor{taler-exchange-manual offline-keys}@anchor{9}
@section Offline keys


The exchange (and ideally also its auditor(s)) uses a long-term offline master
siging key that identifies the operator and is used to authenticate critical
information, such as the exchange's bank account and the actual keys the
exchange uses online.

Interactions with the offline system are performed using the
@code{taler-exchange-offline} tool.  To use the offline system will require
exchange operators to copy JSON files from or to the offline system (say using
an USB stick).  The offline system does not need any significant amount of
computing power, a Raspberry-Pi is perfectly sufficient and the form-factor
might be good for safe-keeping! (You should keep a copy of the (encrypted)
private offline key on more than one physical medium though.)

Exchange operators are strongly advised to secure their private master key and
any copies on encrypted, always-offline computers. Again, this manual assumes
that you are familiar with good best practices in operational security,
including securing key material.

@node Online signing key security,,Offline keys,Introduction
@anchor{taler-exchange-manual online-signing-key-security}@anchor{a}
@section Online signing key security


To provide an additional level of protection for the private `online' signing
keys used by the exchange, the actual cryptographic signing operations are
performed by three helper processes, @code{taler-exchange-secmod-rsa},
@code{taler-exchange-secmod-cs} and @code{taler-exchange-secmod-eddsa}.

The current implementation does not yet support the use of a hardware security
module (HSM).  If you have such a device with adequate functionality and are
interested in Taler supporting it, please contact the developers for HSM
integration support.

@menu
* Functionality:: 
* Security goals:: 
* Setup:: 
* Configuration:: 

@end menu

@node Functionality,Security goals,,Online signing key security
@anchor{taler-exchange-manual functionality}@anchor{b}
@subsection Functionality


The UNIX domain sockets of the `secmod' helpers have mode 0620 (u+rw, g+w).
The exchange process MUST thus be in the same group as the crypto helper
processes to enable access to the keys. No other users should be in that
group!

The two helper processes will create the required private keys, and allow
anyone with access to the UNIX domain socket to sign arbitrary messages with
the keys or to inform them about a key being revoked.  The helper processes
are also responsible for deleting the private keys if their validity period
expires or if they are informed about a key having been revoked.

@node Security goals,Setup,Functionality,Online signing key security
@anchor{taler-exchange-manual security-goals}@anchor{c}
@subsection Security goals


From a security point of view, the helpers are designed to `only' make it
harder for an attacker who took control of the HTTP daemon's account to
extract the private keys, limiting the attackers ability to creating
signatures to the duration of their control of that account.

@cartouche
@quotation Note 
In the future, the helper processes should additionally provide a mechanism
to track the total number of signatures they have made for the various keys.
@end quotation
@end cartouche

@node Setup,Configuration,Security goals,Online signing key security
@anchor{taler-exchange-manual setup}@anchor{d}
@subsection Setup


The helper processes should be run under a user ID that is separate from that
of the user running the main @code{taler-exchange-httpd} service.  To get any
security benefit from this, it is important that helpers run under a different
user ID than the main HTTP frontend. In fact, ideally, each helper should run
under its own user ID.  The @code{taler-exchange-httpd} service's will securely
communicate with the helpers using UNIX domain sockets.

@node Configuration,,Setup,Online signing key security
@anchor{taler-exchange-manual configuration}@anchor{e}
@subsection Configuration


The helpers and the exchange HTTP service need both access to the same
configuration information.  Having divergent configurations may result in
run-time failures.  It is recommended that the configuration file (@code{-c}
option) is simply shared between all of the different processes, even though
they run as different system users. The configuration does not contain any
sensitive information.

@node Installation,Configuration Fundamentals,Introduction,Top
@anchor{taler-exchange-manual exchangeinstallation}@anchor{f}@anchor{taler-exchange-manual installation}@anchor{10}
@chapter Installation


Before installing a Taler exchange, please make sure that your system does not
have swap space enabled.  Swap space is a security risk that Taler does not
try to mitigate against.

We recommend the setup of offline signing keys to be done on a second machine that
does not have Internet access.

In this guide's shell-session fragments, the command prompt shows two pieces
of information:


@itemize *

@item 
Who is performing the command
(@code{$user} vs @code{root}, and ending character @code{$} vs @code{#}).

@item 
Host where the command is supposed to be executed
(@code{exchange-offline} vs @code{exchange-online}).
It is possible to do the entire setup on one machine,
but we do not recommend this for security reasons.
@end itemize

@menu
* Before you start:: 
* Installing from source:: 
* Installing the GNU Taler binary packages on Debian:: 
* Installing the GNU Taler binary packages on Trisquel:: 
* Installing the GNU Taler binary packages on Ubuntu:: 
* Services@comma{} users@comma{} groups and file system hierarchy: Services users groups and file system hierarchy. 

@end menu

@node Before you start,Installing from source,,Installation
@anchor{taler-exchange-manual before-you-start}@anchor{11}
@section Before you start


To deploy this with a real bank, you need:

@quotation


@itemize *

@item 
IBAN of the bank account to use

@item 
BIC of the bank

@item 
EBICS host, user and partner IDs
@end itemize
@end quotation

Information to write down during the installation:

@quotation


@itemize *

@item 
LibEuFin Nexus superuser password

@item 
Taler facade base URL

@item 
exchange Nexus username and password
@end itemize
@end quotation

@node Installing from source,Installing the GNU Taler binary packages on Debian,Before you start,Installation
@anchor{taler-exchange-manual installing-from-source}@anchor{12}
@section Installing from source


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

The package sources can be find in our
download directory@footnote{http://ftpmirror.gnu.org/taler/}.

@c This file is part of GNU TALER.
@c 
@c Copyright (C) 2014-2023 Taler Systems SA
@c 
@c TALER is free software; you can redistribute it and/or modify it under the
@c terms of the GNU Affero General Public License as published by the Free Software
@c Foundation; either version 2.1, or (at your option) any later version.
@c 
@c TALER is distributed in the hope that it will be useful, but WITHOUT ANY
@c WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
@c A PARTICULAR PURPOSE.  See the GNU Affero General Public License for more details.
@c 
@c You should have received a copy of the GNU Affero General Public License along with
@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
@c 
@c @author Christian Grothoff

GNU Taler components version numbers follow the @code{MAJOR.MINOR.MICRO} format.
The general rule for compatibility is that @code{MAJOR} and @code{MINOR} must match.
Exceptions to this general rule are documented in the release notes.
For example, Taler merchant 1.3.0 should be compatible with Taler exchange 1.4.x
as the MAJOR version matches.  A MAJOR version of 0 indicates experimental
development, and you are expected to always run all of the `latest' releases
together (no compatibility guarantees).

First, the following packages need to be installed before we can compile the
backend:


@itemize -

@item 
"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
on Debian-based systems (for GNUnet documentation support, can be
omitted if GNUnet is configured with @code{--disable-documentation})

@item 
libsqlite3 >= 3.16.2

@item 
GNU libunistring >= 0.9.3

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

@item 
libqrencode >= 4.0.0 (Taler merchant only)

@item 
GNU libgcrypt >= 1.6 (1.10 or later highly recommended)

@item 
libsodium >= 1.0

@item 
libargon2 >= 20171227

@item 
libjansson >= 2.7

@item 
PostgreSQL >= 15, including libpq

@item 
GNU libmicrohttpd >= 0.9.71

@item 
GNUnet >= 0.20 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})

@item 
Python3 with @code{jinja2}
@end itemize

If you are on Debian stable or later, the following command may help you
install these dependencies:

@example
# apt-get install \
  libqrencode-dev \
  libsqlite3-dev \
  libltdl-dev \
  libunistring-dev \
  libsodium-dev \
  libargon2-dev \
  libcurl4-gnutls-dev \
  libgcrypt20-dev \
  libjansson-dev \
  libpq-dev \
  libmicrohttpd-dev \
  python3-jinja2 \
  postgresql-15
@end example

Before you install GNUnet, you must download and install the dependencies
mentioned in the previous section, otherwise the build may succeed, but could
fail to export some of the tooling required by GNU Taler.

On Ubuntu, you also need to install pkg-config, for example:

@example
$ apt-get install pkg-config
@end example

To install GNUnet, unpack the tarball and change
into the resulting directory, then proceed as follows:

@example
$ ./configure [--prefix=GNUNETPFX]
$ # Each dependency can be fetched from non standard locations via
$ # the '--with-<LIBNAME>' option. See './configure --help'.
$ make
# make install
# ldconfig
@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}.
The @code{ldconfig} command (also run as @code{root}) makes the
shared object libraries (@code{.so} files)
visible to the various installed programs.

Please note that unlike most packages, if you want to run the @code{make check}
command, you should run it only `after' having done @code{make install}.  The
latter ensures that necessary binaries are copied to the right place.

In any case, if @code{make check} fails, please consider filing a
bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.

There is no need to actually run a GNUnet peer to use the Taler merchant
backend -- all the merchant needs from GNUnet is a number of headers and
libraries!

After installing GNUnet, unpack the GNU Taler exchange tarball,
change into the resulting directory, and proceed as follows:

@example
$ ./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}.  You have to specify
@code{--with-gnunet=/usr/local} if you installed GNUnet to @code{/usr/local} in the
previous step.

Please note that unlike most packages, if you want to run the @code{make check}
command, you should run it only `after' having done @code{make install}.  The
latter ensures that necessary binaries are copied to the right place.

In any case, if @code{make check} fails, please consider filing a
bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.

@node Installing the GNU Taler binary packages on Debian,Installing the GNU Taler binary packages on Trisquel,Installing from source,Installation
@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{13}
@section Installing the GNU Taler binary packages on Debian


To install the GNU Taler Debian packages, first ensure that you have
the right Debian distribution. At this time, the packages are built for
Debian bookworm.

You need to add a file to import the GNU Taler packages. Typically,
this is done by adding a file @code{/etc/apt/sources.list.d/taler.list} that
looks like this:

@example
deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/debian bookworm main
@end example

Next, you must import the Taler Systems SA public package signing key
into your keyring and update the package lists:

@example
# wget -O /etc/apt/keyrings/taler-systems.gpg \
    https://taler.net/taler-systems.gpg
# apt update
@end example

@cartouche
@quotation Note 
You may want to verify the correctness of the Taler Systems SA key out-of-band.
@end quotation
@end cartouche

Now your system is ready to install the official GNU Taler binary packages
using apt.

To install the Taler exchange, you can now simply run:

@example
[root@@exchange-online]# apt install taler-exchange
@end example

Note that the package does not perform any configuration work except for
setting up the various users and the systemd service scripts. You still must
configure at least the database, HTTP reverse proxy (typically with TLS
certificates), denomination and fee structure, bank account, auditor(s),
offline signing and the terms of service.

On the offline system, you should run at least:

@example
[root@@exchange-offline]# apt install taler-exchange-offline
@end example

@node Installing the GNU Taler binary packages on Trisquel,Installing the GNU Taler binary packages on Ubuntu,Installing the GNU Taler binary packages on Debian,Installation
@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-trisquel}@anchor{14}
@section Installing the GNU Taler binary packages on Trisquel


To install the GNU Taler Trisquel packages, first ensure that you have
the right Trisquel distribution. Packages are currently available for
Trisquel GNU/Linux 10.0.  Simply follow the same instructions provided
for Ubuntu.

@node Installing the GNU Taler binary packages on Ubuntu,Services users groups and file system hierarchy,Installing the GNU Taler binary packages on Trisquel,Installation
@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-ubuntu}@anchor{15}
@section Installing the GNU Taler binary packages on Ubuntu


To install the GNU Taler Ubuntu packages, first ensure that you have
the right Ubuntu distribution. At this time, the packages are built for
Ubuntu Lunar and Ubuntu Jammy. Make sure to have @code{universe} in your
@code{/etc/apt/sources.list.d/ubuntu.sources} (after @code{main})
as we depend on some packages from Ubuntu @code{universe}.

A typical @code{/etc/apt/sources.list.d/taler.list} file for this setup
would look like this for Ubuntu Noble:

@example
deb [signed-by=/etc/apt/keyrings/taler-systems.gpg] https://deb.taler.net/apt/ubuntu/ noble main
@end example

Next, you must import the Taler Systems SA public package signing key
into your keyring and update the package lists:

@example
# wget -O /etc/apt/keyrings/taler-systems.gpg \
    https://taler.net/taler-systems.gpg
# apt update
@end example

@cartouche
@quotation Note 
You may want to verify the correctness of the Taler Systems key out-of-band.
@end quotation
@end cartouche

Now your system is ready to install the official GNU Taler binary packages
using apt.

To install the Taler exchange, you can now simply run:

@example
[root@@exchange-online]# apt install taler-exchange
@end example

Note that the package does not perform any configuration work except for
setting up the various users and the systemd service scripts. You still must
configure at least the database, HTTP reverse proxy (typically with TLS
certificates), denomination and fee structure, bank account, auditor(s),
offline signing and the terms of service.

On the offline system, you should run at least:

@example
[root@@exchange-offline]# apt install taler-exchange-offline
@end example

@node Services users groups and file system hierarchy,,Installing the GNU Taler binary packages on Ubuntu,Installation
@anchor{taler-exchange-manual services-users-groups-and-file-system-hierarchy}@anchor{16}
@section Services, users, groups and file system hierarchy


The `taler-exchange' package will create several system users
to compartmentalize different parts of the system:


@itemize *

@item 
@code{taler-exchange-httpd}: runs the HTTP daemon with the core business logic.

@item 
@code{taler-exchange-secmod-rsa}: manages the RSA private online signing keys.

@item 
@code{taler-exchange-secmod-cs}: manages the CS private online signing keys.

@item 
@code{taler-exchange-secmod-eddsa}: manages the EdDSA private online signing keys.

@item 
@code{taler-exchange-closer}: closes idle reserves by triggering wire transfers that refund the originator.

@item 
@code{taler-exchange-aggregator}: aggregates deposits into larger wire transfer requests.

@item 
@code{taler-exchange-transfer}: performs wire transfers with the bank (via LibEuFin/Nexus).

@item 
@code{taler-exchange-wirewatch}: checks for incoming wire transfers with the bank (via LibEuFin/Nexus).

@item 
@code{postgres}: runs the PostgreSQL database (from `postgresql' package).

@item 
@code{www-data}: runs the frontend HTTPS service with the TLS keys (from `nginx' package).
@end itemize

@cartouche
@quotation Note 
The `taler-merchant' package additionally creates a @code{taler-merchant-httpd} user
to run the HTTP daemon with the merchant business logic.
@end quotation
@end cartouche

The exchange setup uses the following system groups:


@itemize *

@item 
@code{taler-exchange-db}: group for all Taler users with direct database access, specifically taler-exchange-httpd, taler-exchange-wirewatch, taler-exchange-closer and taler-exchange-aggregator.

@item 
@code{taler-exchange-secmod}: group for processes with access to online signing keys; this group must have four users: taler-exchange-secmod-rsa, taler-exchange-secmod-cs, taler-exchange-secmod-eddsa and taler-exchange-httpd.

@item 
@code{taler-exchange-offline}: group for the access to the offline private key (only used on the offline host and not used on the online system).
@end itemize

The package will deploy systemd service files in
@code{/usr/lib/systemd/system/} for the various components:


@itemize *

@item 
@code{taler-exchange-aggregator.service}: service that schedules wire transfers
which combine multiple deposits to the same merchant.

@item 
@code{taler-exchange-closer.service}: service that watches for reserves that have been abandoned and schedules wire transfers to send the money back to the originator.

@item 
@code{taler-exchange-httpd.service}: main Taler exchange logic with the public REST API.

@item 
@code{taler-exchange-httpd.socket}: systemd socket activation for the Taler exchange HTTP daemon.

@item 
@code{taler-exchange-secmod-eddsa.service}: software security module for making EdDSA signatures.

@item 
@code{taler-exchange-secmod-rsa.service}: software security module for making RSA signatures.

@item 
@code{taler-exchange-secmod-cs.service}: software security module for making CS signatures.

@item 
@code{taler-exchange-transfer.service}: service that triggers outgoing wire transfers (pays merchants).

@item 
@code{taler-exchange-wirewatch.service}: service that watches for incoming wire transfers (first step of withdraw).

@item 
@code{taler-exchange.target}: Main target for the Taler exchange to be operational.
@end itemize

The deployment creates the following key locations in the system:


@itemize *

@item 
@code{/etc/taler-exchange/}: configuration files.

@item 
@code{/run/taler-exchange/}: contains the UNIX domain sockets for inter-process communication (IPC).

@item 
@code{/var/lib/taler-exchange/}: serves as the $HOME for all Taler exchange users and contains sub-directories
with the private keys; which keys are stored here depends on the host:


@itemize *

@item 
online system: exchange-secmod-eddsa, exchange-secmod-cs and exchange-secmod-rsa keys.

@item 
offline system: exchange-offline keys.
@end itemize
@end itemize

@node Configuration Fundamentals,Exchange Database Setup,Installation,Top
@anchor{taler-exchange-manual configuration-fundamentals}@anchor{17}
@chapter Configuration Fundamentals


This chapter provides fundamental details about the exchange configuration.

The configuration for all Taler components uses a single configuration file
as entry point: @code{/etc/taler-exchange/taler-exchange.conf}.

System defaults are automatically loaded from files in
@code{/usr/share/taler-exchange/config.d}.
These default files should never be modified.

The default configuration @code{taler-exchange.conf} configuration file
also includes all configuration files in @code{/etc/taler-exchange/conf.d}.
The settings from files in
@code{conf.d} are only relevant to particular components of an exchange, while
@code{taler-exchange.conf} contains settings that affect all exchange components.

The directory @code{/etc/taler-exchange/secrets} contains configuration file snippets with
values that should only be readable to certain users.  They are included with the @code{@@inline-secret@@}
directive and should end with @code{.secret.conf}.

To view the entire configuration annotated with the source of each configuration option, you
can use the @code{taler-exchange-config} helper:

@example
[root@@exchange-online]# taler-exchange-config --diagnostics
< ... annotated, full configuration ... >
@end example

@cartouche
@quotation Warning 
While @code{taler-exchange=config} also supports rewriting configuration files, we strongly
recommend to edit configuration files manually, as @code{taler-exchange-config} does not
preserve comments and, by default, rewrites @code{/etc/taler-exchange/taler-exchange.conf}.
@end quotation
@end cartouche

@menu
* Configuration format:: 

@end menu

@node Configuration format,,,Configuration Fundamentals
@anchor{taler-exchange-manual configuration-format}@anchor{18}
@section Configuration format


All GNU Taler components are designed to possibly share the same
configuration files.  When installing a GNU Taler component, the
installation deploys default values in configuration files located
at $@{prefix@}/share/taler/config.d/ where $@{prefix@} is the installation
prefix. Different components must be installed to the same prefix.

In order to override these defaults, the user can write a custom configuration
file and either pass it to the component at execution time using the `-c'
option, or name it taler.conf and place it under $HOME/.config/ which is where
components will look by default. Note that the systemd service files pass @code{-c
/etc/taler/taler.conf}, thus making @code{/etc/taler/taler.conf}
the primary location for the configuration.

A config file is a text file containing sections, and each section
contains maps options to their values.  Configuration files follow
basically the INI syntax:

@example
[section1]
value1 = string
value2 = 23

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

Comments start with a hash (@code{#}).  Throughout the configuration, it is
possible to use @code{$}-substitution for options relating to names of files or
directories. It is also possible to provide defaults values for those
variables that are unset, by using the following syntax:
@code{$@{VAR:-default@}}. There are two ways a user can set the value
of @code{$}-prefixable variables:


@enumerate 

@item 
by defining them under a @code{[paths]} section:

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

@item 
or by setting them in the environment:

@example
$ export VAR=/x
@end example
@end enumerate

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

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

The repository @code{git://git.taler.net/deployment} contains example code
for generating configuration files under @code{deployment/netzbon/}.

@node Exchange Database Setup,Basic Setup Currency Denominations and Keys,Configuration Fundamentals,Top
@anchor{taler-exchange-manual exchange-database-setup}@anchor{19}
@chapter Exchange Database Setup


The access credentials for the exchange's database are configured in
@code{/etc/taler-exchange/secrets/exchange-db.secret.conf}.
Currently, only PostgreSQL is supported as a database backend.

The following users must have access to the exchange database:


@itemize *

@item 
taler-exchange-httpd

@item 
taler-exchange-wire

@item 
taler-exchange-aggregator

@item 
taler-exchange-closer
@end itemize

These users are all in the taler-exchange-db group, and the
@code{exchange-db.secret.conf} should be only readable by users in
this group.

@cartouche
@quotation Note 
The `taler-exchange-dbconfig' tool can be used to automate the database
setup. When using the Debian/Ubuntu packages, the users should already have
been created, so you can just run the tool without any arguments and should
have a working database configuration. The rest of this section only
explains what the `taler-exchange-dbconfig' shell script fully automates.
@end quotation
@end cartouche

To create a database for the Taler exchange on the local system, run:

@example
[root@@exchange-online]# su - postgres
[postgres@@exchange-online]# createuser taler-exchange-httpd
[postgres@@exchange-online]# createuser taler-exchange-wire
[postgres@@exchange-online]# createuser taler-exchange-aggregator
[postgres@@exchange-online]# createuser taler-exchange-closer
[postgres@@exchange-online]# createdb -O taler-exchange-httpd taler-exchange
[postgres@@exchange-online]# exit
@end example

This will create a @code{taler-exchange} database owned by the
@code{taler-exchange-httpd} user.  We will use that user later to perform
database maintenance operations.

Assuming the above database setup, the database credentials to configure
in the configuration file would simply be:


@float LiteralBlock

@caption{/etc/taler-exchange/secrets/exchange-db.secret.conf}

@example
[exchange]
DB = postgres

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

@end float


If the database is run on a different host, please follow the instructions
from the PostgreSQL manual for configuring remote access.

After configuring the database credentials, the exchange database needs
to be initialized with the following command:

@example
[root@@exchange-online]# sudo -u taler-exchange-httpd taler-exchange-dbinit

..note::

  To run this command, the user must have `@w{`}CREATE TABLE`@w{`}, `@w{`}CREATE
  INDEX`@w{`}, `@w{`}ALTER TABLE`@w{`} and (in the future possibly even) `@w{`}DROP TABLE`@w{`}
  permissions.  Those permissions are only required for this step (which may
  have to be repeated when upgrading a deployment).  Afterwards, during
  normal operation, permissions to `@w{`}CREATE`@w{`} or `@w{`}ALTER`@w{`} tables are not
  required by any of the Taler exchange processes and thus should not be
  granted.  For more information, see
  :doc:`manpages/taler-exchange-dbinit.1`.
@end example

Finally we need to grant the other accounts limited access:

@example
[root@@exchange-online]# sudo -u taler-exchange-httpd bash
[taler-exchange-httpd@@exchange-online]# echo 'GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA exchange TO "taler-exchange-aggregator";' \
  | psql taler-exchange
[taler-exchange-httpd@@exchange-online]# echo 'GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA exchange TO "taler-exchange-closer";' \
  | psql taler-exchange
[taler-exchange-httpd@@exchange-online]# echo 'GRANT SELECT,INSERT,UPDATE ON ALL TABLES IN SCHEMA exchange TO "taler-exchange-wire";' \
  | psql taler-exchange
[taler-exchange-httpd@@exchange-online]# echo 'GRANT USAGE ON ALL SEQUENCES IN SCHEMA exchange TO "taler-exchange-aggregator";' \
  | psql taler-exchange
[taler-exchange-httpd@@exchange-online]# echo 'GRANT USAGE ON ALL SEQUENCES IN SCHEMA exchange TO "taler-exchange-closer";' \
  | psql taler-exchange
[taler-exchange-httpd@@exchange-online]# echo 'GRANT USAGE ON ALL SEQUENCES IN SCHEMA exchange TO "taler-exchange-wire";' \
  | psql taler-exchange
[taler-exchange-httpd@@exchange-online]# exit
@end example

@cartouche
@quotation Note 
The above instructions for changing database permissions only work `after'
having initialized the database with @code{taler-exchange-dbinit}, as
the tables need to exist before permissions can be granted on them. The
@code{taler-exchange-dbinit} tool cannot setup these permissions, as it
does not know which users will be used for which processes.
@end quotation
@end cartouche

@node Basic Setup Currency Denominations and Keys,Wire Gateway Setup,Exchange Database Setup,Top
@anchor{taler-exchange-manual basic-setup-currency-denominations-and-keys}@anchor{1a}
@chapter Basic Setup: Currency, Denominations and Keys


A Taler exchange only supports a single currency.  The currency
and the smallest currency unit supported by the bank system
must be specified in @code{/etc/taler-exchange/taler-exchange.conf}.


@float LiteralBlock

@caption{/etc/taler-exchange/taler-exchange.conf}

@example
 [exchange]
 CURRENCY = EUR
 CURRENCY_ROUND_UNIT = EUR:0.01

 # ... rest of file ...
@end example

@end float


@cartouche
@quotation Warning 
@quotation

When editing @code{/etc/taler-exchange/taler-exchange.conf}, take care to not accidentally remove
the @code{@@inline-matching@@} directive to include the configuration files in @code{conf.d}.
@end quotation
@anchor{taler-exchange-manual coins-denomination-keys}@anchor{1b}
@end quotation
@end cartouche

@menu
* Coins (denomination keys): Coins denomination keys. 
* Sign keys:: 
* Setting up the offline signing key:: 

@end menu

@node Coins denomination keys,Sign keys,,Basic Setup Currency Denominations and Keys
@anchor{taler-exchange-manual id1}@anchor{1c}
@section Coins (denomination keys)


Next, the electronic cash denominations that the exchange offers must be
specified.

Sections specifying denomination (coin) information start with @code{coin_}.  By
convention, the name continues with @code{$CURRENCY_[$SUBUNIT]_$VALUE_$REVISION},
i.e. @code{[coin_eur_ct_10_0]} for a 10 cent piece. However, only the @code{coin_}
prefix is mandatory.  Once configured, these configuration values must not
change.  The @code{$REVISION} part of the section name should be incremented if
any of the coin attributes in the section changes.  Each @code{coin_}-section
must then have the following options:


@itemize -

@item 
@code{VALUE}: How much is the coin worth, the format is
CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is "EUR:0.10".

@item 
@code{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 
@code{DURATION_SPEND}: How long is a coin of the given type valid? Smaller
values result in lower storage costs for the exchange.

@item 
@code{DURATION_LEGAL}: How long is the coin of the given type legal?

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

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

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

@item 
@code{FEE_REFUND}: What does it cost to refund this coin?
Specified using the same format as value.

@item 
@code{CIPHER}: Which cipher to use for this coin? Must be either @code{RSA} or
@code{CS}.

@item 
@code{RSA_KEYSIZE}: How many bits should the RSA modulus (product of the two
primes) have for this type of coin.

@item 

@table @asis

@item @code{AGE_RESTRICTED}: Set to @code{YES} to make this a denomination with support

for age restrictions. See age restriction extension below for details.
This option is optional and defaults to @code{NO}.
@end table
@end itemize

See manpages/taler-exchange.conf.5 for information on `duration' values
(i.e. @code{DURATION_WITHDRAW} and @code{DURATION_SPEND} above,
and @code{OVERLAP_DURATION} and @code{DURATION} below).
Additionally, there are two global configuration options of note:


@itemize -

@item 
@code{[taler-exchange-secmod-rsa/OVERLAP_DURATION]}: What is the overlap of the
withdrawal timespan for denomination keys?  The value given here must
be smaller than any of the @code{DURATION_WITHDRAW} values for any of the coins.

@item 
@code{[taler-exchange-secmod-rsa/LOOKAHEAD_SIGN]}: For how far into the future
should denomination keys be pre-generated?  This allows the exchange and
auditor operators to download, offline-sign, and upload denomination key
signatures for denomination keys that will be used in the future by the
exchange.
@end itemize

@geindex maintenance

@cartouche
@quotation Note 
We recommend setting the @code{LOOKAHEAD_SIGN} value to at least one year and
then to perform the offline-signing procedure at least once every 6 months
to ensure that there is sufficient time for wallets to learn the new keys
and to avoid unavailability in case this critical maintenance procedure is
delayed.
@end quotation
@end cartouche

@cartouche
@quotation Note 
It is crucial that the configuration provided in these sections is identical (!)
for the exchange and the crypto helpers.  We recommend pointing both users
to the same configuration file!
@end quotation
@end cartouche

The @code{taler-wallet-cli} has a helper command that generates a
reasonable denomination structure.

@example
[root@@exchange-online]# taler-wallet-cli deployment gen-coin-config \
                          --min-amount EUR:0.01 \
                          --max-amount EUR:100 \
                          > /etc/taler-exchange/conf.d/exchange-coins.conf
@end example

You can manually review and edit the generated configuration file. The main
change that is possibly required is updating the various fees.  Note that you
MUST NOT edit a coin configuration section after the initial setup. If you
must @code{change} the values, you must instead create a new section with a
different unique name (still with the @code{coin-} prefix) and comment out or
remove the existing section.  Do take care to not introduce the name of the
disabled section again in the future.

@node Sign keys,Setting up the offline signing key,Coins denomination keys,Basic Setup Currency Denominations and Keys
@anchor{taler-exchange-manual id2}@anchor{1d}@anchor{taler-exchange-manual sign-keys}@anchor{1e}
@section Sign keys


There are three global configuration options of note for sign keys:


@itemize -

@item 
@code{[taler-exchange-secmod-eddsa/DURATION]}: How long are sign keys
used to sign messages? After this time interval expires, a fresh
sign key will be used (key rotation).  We recommend using
a @code{DURATION} of a few weeks to a few months for sign keys.

@item 
@code{[taler-exchange-secmod-eddsa/OVERLAP_DURATION]}: What is the overlap of the
timespan for sign keys?  We recommend a few minutes or hours.  Must
be smaller than @code{DURATION}.

@item 
@code{[taler-exchange-secmod-eddsa/LOOKAHEAD_SIGN]}: For how far into the future
should sign keys be pre-generated?  This allows the exchange and
auditor operators to download, offline-sign, and upload sign key
signatures for sign keys that will be used in the future by the exchange.
@end itemize

@cartouche
@quotation Note 
We recommend setting the @code{LOOKAHEAD_SIGN} value to at least one year and
then to perform the offline-signing procedure at least once every 6 months
to ensure that there is sufficient time for wallets to learn the new keys
and to avoid unavailability in case this critical maintenance procedure is
delayed.
@end quotation
@end cartouche

@node Setting up the offline signing key,,Sign keys,Basic Setup Currency Denominations and Keys
@anchor{taler-exchange-manual offlineconfiguration}@anchor{1f}@anchor{taler-exchange-manual setting-up-the-offline-signing-key}@anchor{20}
@section Setting up the offline signing key


Before launching an exchange, the offline signing (master) key must be
generated and set in the configuration.  The offline signing keys of the
exchange should be stored on a different machine.  The responsibilities of
this offline signing machine are:


@itemize *

@item 
Generation of the exchange's offline master signing key.

@item 
Secure storage of the exchange's offline master signing key.

@item 
Generation of certificates (signed with the offline master signing key) that will be imported by the exchange.

@item 
Revocation of keys when the online system was compromised or is being terminated
@end itemize

Configuration file options related to the master key are:


@itemize -

@item 

@table @asis

@item @code{[exchange-offline/MASTER_PRIV_FILE]}: Path to the exchange’s master

private file.  Only needs to be provided on the offline system where the
@code{taler-exchange-offline} command is used.  The default value is usually
fine and does not require adjustment.
@end table

@item 

@table @asis

@item @code{[exchange/MASTER_PUBLIC_KEY]}: Must specify the exchange’s master public

key.  Needed for the exchange to verify information signed by the offline
system.  This value must almost always be set explicitly by hand.
@end table
@end itemize

@example
[root@@exchange-offline]# taler-exchange-offline setup
< ... prints the exchange master public key >
@end example

The public key printed as the output of this command must be put into the
configuration of the online machine:


@float LiteralBlock

@caption{/etc/taler-exchange/conf.d/exchange-business.conf}

@example
 [exchange]
 MASTER_PUBLIC_KEY = YE6Q6TR1ED...

 # ... rest of file ...
@end example

@end float


@node Wire Gateway Setup,Deployment,Basic Setup Currency Denominations and Keys,Top
@anchor{taler-exchange-manual wire-gateway-setup}@anchor{21}
@chapter Wire Gateway Setup


The Taler Wire Gateway is an API that
connects the Taler exchange to the underlying core banking system.  There are
several implementations of wire gateways:

@quotation


@itemize *

@item 
Project deploymerization@footnote{https://git.taler.net/depolymerization.git} implements a wire gateway on top of Bitcoin or Ethereum

@item 
The libeufin-bank provides a wire gateway interface on top of a regional currency bank

@item 
The `taler-fakebank-run' command is an in-memory bank simulator with a wire gateway interface for testing
@end itemize
@end quotation

@c FIXME :ref:`libeufin-nexus <libeufin-nexus>` is an implementation of the Wire Gateway API for the EBICS protocol. Add to list above once nexus implements the TWG directly!

Before continuing, you need to decide which wire gateway you want to use,
and install and configure it on your system.  Afterwards, you need to
have two key pieces of information from that setup:

@quotation


@itemize *

@item 
The username and password to access the exchange's account in the system.

@item 
The @code{payto://} URI of that account (see RFC 8905@footnote{https://www.rfc-editor.org/rfc/rfc8905}).
@end itemize
@end quotation

If you use the libeufin-bank, you need to set a special configuration option
because the taler-exchange-wire-gateway-client does not yet support token
authentication:


@float LiteralBlock

@caption{/etc/libeufin/libeufin-bank.conf}

@example
 [libeufin-bank]
 PWD_AUTH_COMPAT = YES
@end example

@end float


@c FIXME: Remove the text above once #9703 is fixed.

@menu
* Exchange Bank Account Configuration:: 

@end menu

@node Exchange Bank Account Configuration,,,Wire Gateway Setup
@anchor{taler-exchange-manual exchange-bank-account-configuration}@anchor{22}@anchor{taler-exchange-manual id3}@anchor{23}
@section Exchange Bank Account Configuration


An exchange must be configured with the right settings to access its bank
account via a Taler wire gateway.  An
exchange can be configured to use multiple bank accounts by using multiple
wire gateways.  Typically only one wire gateway is used.

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


@itemize -

@item 
The @code{payto://} URI of the bank account, which uniquely idenfies the
account. Examples for such URIs include
@code{payto://iban/CH9300762011623852957} for a bank account with
an IBAN 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 URI following @code{payto://} (@code{iban} or
@code{x-taler-bank}) is called the wire method.

@item 
The @code{taler-exchange-wirewatch} and @code{taler-exchange-transfer}
tools needs to be provided resources for authentication
to the respective banking service. The format in which the
authentication information is currently a username and password
for HTTP basic authentication.
@end itemize

Each Taler wire gateway is configured in a configuration section that follows
the pattern @code{exchange-account-$id}, where @code{$id} is an internal identifier
for the bank account accessed by the exchange.  The basic information for an
account should be put in @code{/etc/taler-exchange/conf.d/exchange-business.conf}.  The
secret credentials to access the Taler Wire Gateway API should be put into a
corresponding @code{exchange-accountcredentials-$id} section in
@code{/etc/taler-exchange/secrets/exchange-accountcredentials.conf}.  The latter file
should be only readable for the @code{taler-exchange-wire} user.  Only the
@code{taler-exchange-wirewatch} and @code{taler-exchange-transfer} services should
run as the @code{taler-exchange-wire} user.  Other exchange processes do not need
to have access to the account credentials.

You can configure multiple accounts for an exchange by creating sections
starting with @code{exchange-account-} for the section name. You must specify
@code{ENABLE_}-settings for each account whether it should be used, and for what
(incoming or outgoing wire transfers):


@float LiteralBlock

@caption{/etc/taler-exchange/conf.d/exchange-business.conf}

@example
[exchange-account-1]
# Account identifier in the form of an RFC-8905 payto:// URI.
# For SEPA, looks like payto://iban/$IBAN?receiver-name=$NAME
# Make sure to URL-encode spaces in $NAME!
#
# With x-taler-bank (for Fakebank)
# PAYTO_URI = "payto://x-taler-bank/bank.demo.taler.net/Exchange?receiver-name=exop"
#
# Example using IBAN (for use with LibEuFin)
PAYTO_URI = "payto://iban/CH9300762011623852957?receiver=name=exop"

# URL for talking to the bank wire the wire API.
WIRE_GATEWAY_URL = https://bank.demo.taler.net/accounts/exchange/taler-wire-gateway/

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

@@inline-secret@@ exchange-accountcredentials-1 ../secrets/exchange-accountcredentials.secret.conf
@end example

@end float



@float LiteralBlock

@caption{/etc/taler-exchange/secrets/exchange-accountcredentials.secret.conf}

@example
[exchange-accountcredentials-1]

# LibEuFin expects basic auth.
WIRE_GATEWAY_AUTH_METHOD = basic

# Username and password to access the Taler wire gateway.
USERNAME = ...
PASSWORD = ...

# Base URL of the Taler wire gateway.
WIRE_GATEWAY_URL = ...
@end example

@end float


Such a wire gateway configuration can be tested with the following commands:

@example
[root@@exchange-online]# taler-exchange-wire-gateway-client \
  --section exchange-accountcredentials-1 --debit-history
[root@@exchange-online]# taler-exchange-wire-gateway-client \
  --section exchange-accountcredentials-1 --credit-history
@end example

On success, you will see some of your account's transaction history (or an
empty history), while on failure you should see an error message.

@node Deployment,Offline Signing Setup Key Maintenance and Tear-Down,Wire Gateway Setup,Top
@anchor{taler-exchange-manual deployment}@anchor{24}@anchor{taler-exchange-manual id4}@anchor{25}
@chapter Deployment


This chapter describes how to deploy the exchange once the basic installation
and configuration are completed.

@menu
* Serving:: 
* Reverse Proxy Setup:: 
* Launching an exchange:: 

@end menu

@node Serving,Reverse Proxy Setup,,Deployment
@anchor{taler-exchange-manual id5}@anchor{26}@anchor{taler-exchange-manual serving}@anchor{27}
@section Serving


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

The following options are to be configured in the section @code{[exchange]}:


@itemize -

@item 
@code{SERVE}: Must be set to @code{tcp} to serve HTTP over TCP, or @code{unix} to serve
HTTP over a UNIX domain socket.

@item 
@code{PORT}: Set to the TCP port to listen on if @code{SERVE} is @code{tcp}.

@item 
@code{UNIXPATH}: Set to the UNIX domain socket path to listen on if @code{SERVE} is
@code{unix}.

@item 

@table @asis

@item @code{UNIXPATH_MODE}: Number giving the mode with the access permission mask

for the @code{UNIXPATH} (i.e. 660 = @code{rw-rw---}). Make sure to set it in such
a way that your reverse proxy has permissions to access the UNIX domain
socket.  The default (660) assumes that the reverse proxy is a member of
the group under which the exchange HTTP server is running.
@end table
@end itemize

@node Reverse Proxy Setup,Launching an exchange,Serving,Deployment
@anchor{taler-exchange-manual reverse-proxy-setup}@anchor{28}@anchor{taler-exchange-manual reverseproxy}@anchor{29}
@section Reverse Proxy Setup


By default, the @code{taler-exchange-httpd} service listens for HTTP connections
on a UNIX domain socket.  To make the service publicly available, a reverse
proxy such as nginx should be used.  We strongly recommend to configure nginx
to use TLS.

The public URL that the exchange will be served under should
be put in @code{/etc/taler-exchange/conf.d/exchange-business.conf} configuration file.


@float LiteralBlock

@caption{/etc/taler-exchange/conf.d/exchange-business.conf}

@example
 [exchange]
 BASE_URL = https://example.com/

 # ... rest of file ...
@end example

@end float


The @code{taler-exchange} package ships with a sample configuration that can be
enabled in nginx:

@example
[root@@exchange-online]# vim /etc/nginx/sites-available/taler-exchange
< ... customize configuration ... >
[root@@exchange-online]# ln -s /etc/nginx/sites-available/taler-exchange \
                              /etc/nginx/sites-enabled/taler-exchange
[root@@exchange-online]# systemctl reload nginx
@end example

Note that the reverse proxy must set a HTTP @code{X-Forwarded-Host} header to
refer to the hostname used by nginx and a HTTP @code{X-Forwarded-Proto} header to
inform the exchange whether the external protocol was @code{http} or @code{https}.
Thus, depending on your setup, you will likely have to edit those parts of the
provided @code{taler-exchange} configuration file.

With this last step, we are finally ready to launch the
main exchange process.

@node Launching an exchange,,Reverse Proxy Setup,Deployment
@anchor{taler-exchange-manual launch}@anchor{2a}@anchor{taler-exchange-manual launching-an-exchange}@anchor{2b}
@section Launching an exchange


A running exchange requires starting the following processes:


@itemize -

@item 
@code{taler-exchange-secmod-rsa} (as special user, sharing group with the HTTPD)

@item 
@code{taler-exchange-secmod-cs} (as special user, sharing group with the HTTPD)

@item 
@code{taler-exchange-secmod-eddsa} (as special user, sharing group with the HTTPD)

@item 
@code{taler-exchange-httpd} (needs database access)

@item 
@code{taler-exchange-aggregator} (only needs database access)

@item 
@code{taler-exchange-closer} (only needs database access)

@item 
@code{taler-exchange-wirewatch} (needs bank account read credentials and database access)

@item 
@code{taler-exchange-transfer} (needs credentials to initiate outgoing wire transfers and database access)
@end itemize

The crypto helpers (@code{secmod}) must be started before the @code{taler-exchange-httpd} and
they should use the same configuration file.

For the most secure deployment, we recommend using separate users for each of
these processes to minimize information disclosures should any of them be
compromised.  The helpers do not need access to the PostgreSQL database (and
thus also should not have it).

The processes that require access to the bank account need to have a
configuration file with the respective credentials in it. We recommend using a
separate configuration at least for @code{taler-exchange-transfer} which is the
`only' process that needs to know the credentials to execute outgoing wire
transfers.

All of these processes should also be started via a hypervisor like
@code{systemd} or @code{gnunet-arm} that automatically re-starts them should they
have terminated unexpectedly.  If the bank is down (say for maintenance), it is
`possible' to halt the @code{taler-exchange-wirewatch} and/or
@code{taler-exchange-transfer} processes (to avoid them making requests to the
bank API that can only fail) without impacting other operations of the
exchange. Naturally, incoming wire transfers will only be observed once
@code{taler-exchange-wirewatch} is resumed, and merchants may complain if the
disabled @code{taler-exchange-transfer} process causes payment deadlines to be
missed.

@cartouche
@quotation Note 
The @code{taler-exchange-httpd} does not ship with HTTPS enabled by default.
In production, it should be run behind an HTTPS reverse proxy that performs
TLS termination on the same system.  Thus, it would typically be configured
to listen on a UNIX domain socket.  The @code{/management} and @code{/auditors}
APIs do technically not have to be exposed on the Internet (only to the
administrators running @code{taler-exchange-offline}) and should be blocked
by the reverse proxy for requests originating from outside of the bank.
(However, this is not a strong security assumption: in principle having
these endpoints available should do no harm. However, it increases the
attack surface.)
@end quotation
@end cartouche

Given proper packaging, all of the above are realized via a simple systemd
target. This enables the various processes of an exchange service to be
started using a simple command:

@example
[root@@exchange-online]# systemctl start taler-exchange.target
@end example

@cartouche
@quotation Note 
At this point, the exchange service is not yet fully operational.
@end quotation
@end cartouche

To check whether the exchange is running correctly under the advertised
base URL, run:

@example
[root@@exchange-online]# export BASE_URL=$(taler-exchange-config -s exchange -o base_url)
[root@@exchange-online]# wget $@{BASE_URL@}management/keys
@end example

The request might take some time to complete on slow machines, because
a lot of key material will be generated.

@node Offline Signing Setup Key Maintenance and Tear-Down,Setup Linting,Deployment,Top
@anchor{taler-exchange-manual offline-signing-setup-key-maintenance-and-tear-down}@anchor{2c}
@chapter Offline Signing Setup, Key Maintenance and Tear-Down


The exchange HTTP service must be running before you can complete the
following offline signing procedure. Note that when an exchange is running
without offline keys its not fully operational.  To make the exchange HTTP
service fully operational, the following steps involving the offline signing
machine must be completed:

@quotation


@enumerate 

@item 
The public keys of various online keys used by the exchange service are exported
via a management HTTP API.

@item 
The offline signing system validates this request and signs it.
Additionally, the offline signing system signs policy messages
to configure the exchange's bank accounts and associated fees.

@item 
The messages generated by the offline signing system are uploaded
via the management API of the exchange HTTP service.
@end enumerate
@end quotation

A typical minimal setup would look something like this:

@example
[anybody@@exchange-online]# taler-exchange-offline \
  download > sig-request.json

[root@@exchange-offline]# taler-exchange-offline \
  sign < sig-request.json > sig-response.json
[root@@exchange-offline]# taler-exchange-offline \
  enable-account payto://iban/$IBAN?receiver-name=$NAME > acct-response.json
[root@@exchange-offline]# taler-exchange-offline \
  wire-fee now iban EUR:0 EUR:0 > fee-response.json
[root@@exchange-offline]# taler-exchange-offline \
  global-fee now EUR:0 EUR:0 EUR:0 4w 6a 4 > global-response.json

[anybody@@exchange-online]# taler-exchange-offline upload < sig-response.json
[anybody@@exchange-online]# taler-exchange-offline upload < acct-response.json
[anybody@@exchange-online]# taler-exchange-offline upload < fee-response.json
[anybody@@exchange-online]# taler-exchange-offline upload < global-response.json
@end example

The following sections will discuss these steps in more depth.

@menu
* Signing the online signing keys:: 
* Account signing:: 
* Wire fee structure:: 
* Auditor configuration:: 
* Revocations:: 

@end menu

@node Signing the online signing keys,Account signing,,Offline Signing Setup Key Maintenance and Tear-Down
@anchor{taler-exchange-manual keys-generation}@anchor{2d}@anchor{taler-exchange-manual signing-the-online-signing-keys}@anchor{2e}
@section Signing the online signing keys


To sign the online signing keys, first the `future' key material should be downloaded using:

@example
$ taler-exchange-offline download > future-keys.json
@end example

Afterwards, `future-keys.json' contains data about denomination and
online signing keys that the exchange operator needs to sign with
the offline tool.  The file should be copied to the offline system.
There, the operator should run:

@example
$ taler-exchange-offline show < future-keys.json
@end example

and verify that the output contains the fee structure and key lifetimes
they expect to see. They should also note the public keys being shown
and communicate those to the `auditors' over a secure channel.  Once
they are convinced the file is acceptable, they should run:

@example
$ taler-exchange-offline sign < future-keys.json > offline-sigs.json
@end example

The `offline-sigs.json' file must then be copied to an online system
that is able to again communicate with the exchange. On that system, run:

@example
$ taler-exchange-offline upload < offline-sigs.json
@end example

to provision the signatures to the exchange.

The @code{download sign upload} sequence in the commands above has to be done
periodically, as it signs the various online signing keys of the exchange
which periodically expire.

@node Account signing,Wire fee structure,Signing the online signing keys,Offline Signing Setup Key Maintenance and Tear-Down
@anchor{taler-exchange-manual account-signing}@anchor{2f}@anchor{taler-exchange-manual exchange-account-signing}@anchor{30}
@section Account signing


The @code{enable-account} step is important to must be used to sign the
@code{payto://} URI in a way suitable to convince wallets that this is the
correct address to wire funds to.  Note that for each bank account, additional
options `must' be set in the configuration file to tell the exchange how to
access the bank account. The offline tool `only' configures the externally
visible portions of the setup.  The chapter on bank account configuration@footnote{_exchange-bank-account-configuration} has further details.

taler-exchange-offline accepts additional options to configure the use of the
account. For example, additional options can be used to add currency
conversion or to restrict interactions to bank accounts from certain
countries:

@example
$ taler-exchange-offline \
    enable-account payto://iban/CH9300762011623852957
      conversion-url https://conversion.example.com/
@end example

For details on optional @code{enable-account} arguments,
see manpages/taler-exchange-offline.1.

@node Wire fee structure,Auditor configuration,Account signing,Offline Signing Setup Key Maintenance and Tear-Down
@anchor{taler-exchange-manual id6}@anchor{31}@anchor{taler-exchange-manual wire-fee-structure}@anchor{32}
@section Wire fee structure


@geindex wire fee

@geindex fee

For each wire method (“iban” or “x-taler-bank”) the
exchange must know about applicable wire fees. This is also done
using the @code{taler-exchange-offline} tool:

@example
$ taler-exchange-offline wire-fee 2040 iban EUR:0.05 EUR:0.10
@end example

The above sets the wire fees for wire transfers involving @code{iban} accounts
(in Euros) in the year 2040 to 5 cents (wire fee) and 10 cents (closing fee).
The tool only supports setting fees that applies for the entire calendar year.

We recommend provisioning an exchange with wire fees at least for the next two
years.  Note that once the fees have been set for a year, they cannot be
changed (basically, by signing the fees the exchange makes a legally binding
offer to the customers).

@geindex maintenance

@cartouche
@quotation Note 
Provisioning future wire fees, like provisioning future denomination
and signing keys, are key regular maintenance procedures for every
exchange operator.  We recommend setting automated reminders for
this maintenance activity!
@end quotation
@end cartouche

@node Auditor configuration,Revocations,Wire fee structure,Offline Signing Setup Key Maintenance and Tear-Down
@anchor{taler-exchange-manual auditor-configuration}@anchor{33}@anchor{taler-exchange-manual id7}@anchor{34}
@section Auditor configuration


At this point, the exchange will be able to use those keys, but wallets and
merchants may not yet trust them!  Thus, the next step is for an auditor to
affirm that they are auditing this exchange.  Before an auditor can do this,
the exchange service must be informed about any auditor that is expected to
provision it with auditor signatures.

This is also done using the @code{taler-exchange-offline} tool on the offline
system.  First, the auditor must be configured and provide the exchange
operator with its public key (using @code{taler-auditor-offline setup}) and the
URL of it's REST API.  The exchange operator also needs a human-readable name
that may be shown to users to identify the auditor.  For more information on
how to setup and operate an auditor, see
manpages/taler-auditor-offline.1 and taler-auditor-manual.

Given this information, the exchange operator can enable the auditor:

@example
$ taler-exchange-offline enable-auditor $PUB_KEY $REST_URL "$AUDITOR_NAME" > auditor.json
@end example

As before, the `auditor.json' file must then be copied from the offline system
to a system connected to the exchange and there @code{uploaded} to the exchange using @code{taler-exchange-offline upload}.

@node Revocations,,Auditor configuration,Offline Signing Setup Key Maintenance and Tear-Down
@anchor{taler-exchange-manual id8}@anchor{35}@anchor{taler-exchange-manual revocations}@anchor{36}
@section 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 “recoup”.
Wallets detect this, and then return unspent coins of the respective
denomination key using the @code{/recoup} API.

To revoke a denomination key, you need to know the hash of the denomination
public key, @code{$HDP}.  The @code{$HDP} value is usually included in the security
report that is generated when a compromise is detected).  Given this
value, the key revocation can be approved on the offline system:

@example
$ taler-exchange-offline revoke-denominatin $HDP > revocation.json
@end example

The resulting `revocation.json' must be copied to a system connected to the
exchange and uploaded to the exchange using the @code{upload} subcommand
of @code{taler-exchange-offline}.

@cartouche
@quotation Note 
Denomination key revocations should only happen
under highly unusual (“emergency”) conditions and not in normal
operation.
@end quotation
@end cartouche

@node Setup Linting,Testing and Troubleshooting,Offline Signing Setup Key Maintenance and Tear-Down,Top
@anchor{taler-exchange-manual setup-linting}@anchor{37}
@chapter Setup Linting


The @code{taler-wallet-cli} package comes with an experimental tool that runs various
checks on the current GNU Taler exchange deployment:

@example
[root@@exchange-online]# apt install taler-wallet-cli
[root@@exchange-online]# taler-wallet-cli deployment lint-exchange
@end example

You can optionally pass the @code{--debug} option to get more verbose output, and
@code{--continue} to continue with further checks even though a previous one has
failed.

@node Testing and Troubleshooting,Benchmarking,Setup Linting,Top
@anchor{taler-exchange-manual testing-and-troubleshooting}@anchor{38}
@chapter Testing and Troubleshooting


We recommend testing whether an exchange deployment is functional by using the
Taler wallet command line interface.  The tool can be used to withdraw and
deposit electronic cash via the exchange without having to deploy and operate a
separate merchant backend and storefront.

The following shell session illustrates how the wallet can be used to withdraw
electronic cash from the exchange and subsequently spend it.  For these steps,
a merchant backend is not required, as the wallet acts as a merchant.

@example
# This will now output a payto URI that money needs to be sent to in order to allow withdrawal
# of taler coins.
$ taler-wallet-cli advanced withdraw-manually --exchange $EXCHANGE_URL --amount EUR:10.50
@end example

Show the status of the manual withdrawal operation.

@example
$ taler-wallet-cli transactions
@end example

At this point, a bank transfer to the exchange's bank account
needs to be made with the correct subject / remittance information
as instructed by the wallet after the first step.  With the
above configuration, it should take about 5 minutes after the
wire transfer for the incoming transfer to be observed by the
Nexus.

Run the following command to check whether the exchange received
an incoming bank transfer:

@example
[root@@exchange-online]# taler-exchange-wire-gateway-client \
   --section exchange-accountcredentials-1 --credit-history
@end example

Once the transfer has been made, try completing the withdrawal
using:

@example
$ taler-wallet-cli run-pending
@end example

Afterwards, check the status of transactions and show the
current wallet balance:

@example
$ taler-wallet-cli transactions
$ taler-wallet-cli balance
@end example

Now, we can directly deposit coins via the exchange into a target
account.  (Usually, a payment is made via a merchant.  The wallet
provides this functionality for testing.)

@example
$ taler-wallet-cli deposit create EUR:5 \
  payto://iban/$IBAN?receiver-name=Name
$ taler-wallet-cli run-pending
@end example

Check if this transaction was successful (from the perspective
of the wallet):

@example
$ taler-wallet-cli transactions
@end example

If the transaction failed, fix any open issue(s) with the exchange and
run the "run-pending" command.

The wallet can also track if the exchange wired the money to the merchant
account.  The "deposit group id" can be found in the output of the
transactions list.

@example
$ taler-wallet-cli deposit track $DEPOSIT_GROUP_ID
@end example

You can also check using the exchange-tools whether the exchange sent
the an outgoing transfer:

@example
[root@@exchange-online]# taler-exchange-wire-gateway-client \
  --section exchange-accountcredentials-1 --debit-history
@end example

After enough time has passed, the money should arrive at the specified IBAN.

For more information on the taler-wallet-cli tool, see
taler-wallet.

@menu
* taler-exchange-config:: 
* Using taler-*-config:: 
* Private key storage:: 
* Internal audits:: 
* Database Scheme:: 
* Database upgrades:: 

@end menu

@node taler-exchange-config,Using taler-*-config,,Testing and Troubleshooting
@anchor{taler-exchange-manual taler-exchange-config}@anchor{39}
@section taler-exchange-config


@geindex taler-exchange-config
@anchor{taler-exchange-manual using-taler-exchange-config}@anchor{3a}
@node Using taler-*-config,Private key storage,taler-exchange-config,Testing and Troubleshooting
@anchor{taler-exchange-manual using-taler-config}@anchor{3b}
@section Using taler-*-config


GNU Taler comes with various tools all called @code{taler-$COMPONENT-config},
such as @code{taler-exchange-config} and @code{taler-merchant-config}.  They
all behave the same way, but are accessing the default configurations
of the respective @code{$COMPONENT}. In this man page we will thus simply
refer to these tools as the @code{$TALER_CONFIG} tool.

The @code{$TALER_CONFIG} tool can be used to extract or manipulate configuration
values; however, the configuration use the well-known INI file format and is
generally better edited by hand to preserve comments and structure.  Thus, @code{$TALER_CONFIG} should primarily be used
to inspect or understand a configuration that is in place,
and not to update it!

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 and clobber your entire
configuration file structure, inlining all values and
removing all comments, 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 affected Taler components 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 --section exchange-offline --option MASTER_PRIV_FILE
$ $TALER_CONFIG -f --section exchange-offline --option MASTER_PRIV_FILE
@end example

While the configuration file is typically located at
@code{$HOME/.config/taler-$COMPONENT.conf},
an alternative location can be specified to any
GNU Taler component using the @code{-c} option.

@node Private key storage,Internal audits,Using taler-*-config,Testing and Troubleshooting
@anchor{taler-exchange-manual private-key-storage}@anchor{3c}
@section Private key storage


Keeping the private keys the helpers create secret is paramount. If the
private keys are lost, it is easy to provision fresh keys (with the help of
the auditor).  Thus, we recommend that the private keys of the crypto helpers
are `not' backed up: in the rare event of a disk failure, they can be
regenerated.  However, we do recommend using RAID (1+1 or 1+1+1) for all
disks of the system.

@node Internal audits,Database Scheme,Private key storage,Testing and Troubleshooting
@anchor{taler-exchange-manual internal-audit}@anchor{3d}@anchor{taler-exchange-manual internal-audits}@anchor{3e}
@section Internal audits


While an exchange should use an external auditor to attest to regulators that
it is operating correctly, an exchange operator can also use the auditor's
logic to perform internal checks.  For this, an exchange operator can generally
follow the auditor guide.  However, instead of using @code{taler-auditor-sync},
an internal audit can and likely should be performed either directly against
the production exchange database or against a synchronous copy created using
standard database replication techniques. After all, the exchange operator
runs this for diagnostics and can generally trust its own database to maintain
the database invariants.

Running the auditor against a the original the production database (without
using @code{taler-auditor-sync}) enables the auditing logic to perform a few
additional checks that can detect inconsistencies.  These checks are enabled
by passing the `-i' option to the @code{taler-auditor} command.  As always,
the resulting report should be read carefully to see if there are any problems
with the setup.

Reports are generally created incrementally, with @code{taler-auditor} reporting
only incidents and balance changes that were not covered in previous reports.
While it is possible to reset the auditor database and to restart the audit
from the very beginning, this is generally not recommended as this may be too
expensive.

@node Database Scheme,Database upgrades,Internal audits,Testing and Troubleshooting
@anchor{taler-exchange-manual database-scheme}@anchor{3f}@anchor{taler-exchange-manual id9}@anchor{40}
@section Database Scheme


The exchange database must be initialized using @code{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,
@code{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 looks as follows:

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

The @code{jmeasures} JSON in the @code{legitimization_measures}
table is of type @ref{41,,LegitimizationMeasures}:

@example
interface LegitimizationMeasures @{

  // Array of legitimization measures that
  // are to be applied.
  measures: MeasureInformation[];

  // True if the client is expected to eventually satisfy all requirements.
  // Default (if missing) is false.
  is_and_combinator?: boolean;

  // True if the requested operation is categorically forbidden.
  // The measures array will be empty in this case.
  verboten: boolean;
@}
@end example

@node Database upgrades,,Database Scheme,Testing and Troubleshooting
@anchor{taler-exchange-manual database-upgrades}@anchor{42}@anchor{taler-exchange-manual id10}@anchor{43}
@section Database upgrades


Before installing a new exchange version, you should probably make a backup of
the existing database and study the release notes on migration.  In general,
the way to migrate is to stop all existing Taler exchange processes and run:

@example
$ taler-exchange-dbinit
@end example

This will migrate the existing schema to the new schema. You also may need
to grant Taler exchange processes the rights to the new tables (see last
step of database setup).

@cartouche
@quotation Note 
The `taler-exchange-dbconfig' tool can be used to automate the database
migration. In general, simply invoking it again should trigger the
migration including `taler-exchange-dbinit' and setting the permissions.
@end quotation
@end cartouche

If you do not want to keep any data from the previous installation, the
exchange database can be fully re-initialized using:

@example
$ taler-exchange-dbinit --reset
@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. You still also need to then
grant the permissions to the other exchange processes again.

@node Benchmarking,FIXMEs,Testing and Troubleshooting,Top
@anchor{taler-exchange-manual benchmarking}@anchor{44}@anchor{taler-exchange-manual exchangebenchmarking}@anchor{45}
@chapter Benchmarking


This chapter describes how to run various benchmarks against a Taler exchange.
These benchmark can be used to measure the performance of the exchange by
running a (possibly large) number of simulated clients against one Taler
deployment with a bank, exchange and (optionally) auditor.

Real benchmarks that are intended to demonstrate the scalability of GNU Taler
should not use the tools presented in this section: they may be suitable for
microbenchmarking and tuning, but the setup is inherently not optimzied for
performance or realism, both for the load generation and the server side.
Thus, we do not recommend using these performance numbers to assess the
scalability of GNU Taler.  That said, the tools can be useful to help identify
performance issues.

The @code{taler-unified-setup.sh} script can be used to launch all required
services and clients. However, the resulting deployment is simplistic
(everything on the local machine, one single-threaded process per service
type) and not optimized for performance at all. However, this can still be
useful to assess the performance impact of changes
to the code or configuration.

The various configuration files used in the code snippets in this section can
be found in the @code{src/benchmark/} directory of the exchange. These are
generally intended as starting points.  Note that the configuration files
ending in @code{.edited} are created by @code{taler-unified-setup.sh} and contain
some options that are determined at runtime by the setup logic provided by
@code{taler-unified-setup.sh}.

@menu
* Choosing a bank:: 
* taler-bank-benchmark:: 
* taler-exchange-benchmark:: 
* taler-aggregator-benchmark:: 

@end menu

@node Choosing a bank,taler-bank-benchmark,,Benchmarking
@anchor{taler-exchange-manual benchmark-choose-bank}@anchor{46}@anchor{taler-exchange-manual choosing-a-bank}@anchor{47}
@section Choosing a bank


For the bank, both a fakebank (@code{-f}) and libeufin-based (@code{-ns})
bank deployment are currently supported by all benchmark tools and
configuration templates.

Fakebank is an ultra-fast in-memory implementation of the Taler bank API. It
is suitable when the goal is to benchmark the core GNU Taler payment system
and to ignore the real-time gross settlement (RTGS) system typically provided
by an existing bank.  When using the fakebank, @code{taler-unified-setup.sh} must
be started with the @code{-f} option and be told to use the right exchange bank
account from the configuration files via @code{-u exchange-account-1}.

@example
$ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -emwt -c $CONF -f -u exchange-account-1
@end example

libeufin is GNU Taler's adapter to the core banking system using the EBICS
banking protocol standard.  It uses a Postgres database to persist data and is
thus much slower than fakebank.  If your GNU Taler deployment uses libeufin in
production, it likely makes sense to benchmark with libeufin.  When using the
fakebank, @code{taler-unified-setup.sh} must be started with the @code{-ns} options
(starting libeufin-nexus and libeufin-bank) and be told to use the right
exchange bank account from the configuration files via @code{-u
exchange-account-2}.  Note that @code{taler-unified-setup.sh} currently cannot
reset a libeufin database, and also will not run if the database is already
initialized. Thus, you must re-create the database every time before
running the command:

@example
$ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -emwt -c $CONF -ns -u exchange-account-2
@end example

@node taler-bank-benchmark,taler-exchange-benchmark,Choosing a bank,Benchmarking
@anchor{taler-exchange-manual taler-bank-benchmark}@anchor{48}
@section taler-bank-benchmark


This is the simplest benchmarking tool, simulating only the bank
interaction.

@example
$ CONF="benchmark-cs.conf"
$ # or with libeufin
$ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -emwt -c "$CONF" -f -u exchange-account-1
$ # Once <<READY>>, in another shell (remember to set $CONF):
$ time taler-bank-benchmark -c "$CONF" -r 40 -p 4 -P4 -u exchange-account-1 -f
$ # or with libeufin
$ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -emwt -c "$CONF" -ns -u exchange-account-2
$ # Once <<READY>>, in another shell (remember to set $CONF):
$ time taler-bank-benchmark -c "$CONF" -r 40 -p 1 -P1 -u exchange-account-2
@end example

For each `parallel' (@code{-p}) client, a number of `reserves' (@code{-r}) is first
established by `transferring' money from a "user" account (42) to the
Exchange's account with the respective reserve public key as wire subject.
Processing is then handled by `parallel' (@code{-P}) service workers.

@node taler-exchange-benchmark,taler-aggregator-benchmark,taler-bank-benchmark,Benchmarking
@anchor{taler-exchange-manual taler-exchange-benchmark}@anchor{49}
@section taler-exchange-benchmark


This is the benchmarking tool simulates a number of clients withdrawing,
depositing and refreshing coins.  Operations that are not covered by the
@code{taler-exchange-benchmark} tool today include closing reserves, refunds,
recoups and P2P payments.

@example
$ CONF="benchmark-cs.conf" # -rsa also makes sense
$ # With fakebank
$ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -aemwt -c "$CONF" -f -u exchange-account-1
$ # Once <<READY>>, in another shell (remember to set $CONF):
$ taler-exchange-benchmark -c "$CONF".edited -u exchange-account-1 -n 1 -p1 -r 5 -f
$ #
$ # With libeufin
$ dropdb talercheck; createdb talercheck
$ taler-unified-setup.sh -aemwt -c "$CONF" -ns -u exchange-account-2
$ # Once <<READY>>, in another shell (remember to set $CONF):
$ taler-exchange-benchmark -c "$CONF".edited -u exchange-account-2 -L WARNING -n 1 -p1 -r 5
@end example

For each `parallel' (@code{-p}) client, a number of `reserves' (@code{-r}) is first
established by `transferring' money from a "user" account (42) to the
Exchange's account with the respective reserve public key as wire subject.
Next, the client will `withdraw' a `number of coins' (@code{-n}) from the
reserve and `deposit' them. Additionally, a `fraction' (@code{-R}) of the dirty
coins will then be subject to `refreshing'.  For some deposits, the auditor
will receive `deposit confirmations'.

The output of @code{taler-exchange-benchmark} will include for each parallel
client the total time spent in each of the major operations, possible
repetitions (i.e. if the operation failed the first time), total execution
time (operating system and user space) and other details.

@node taler-aggregator-benchmark,,taler-exchange-benchmark,Benchmarking
@anchor{taler-exchange-manual taler-aggregator-benchmark}@anchor{4a}
@section taler-aggregator-benchmark


This is another simple benchmark tool that merely prepares an exchange
database to run a stand-alone benchmark of the @code{taler-exchange-aggregator}
tool.  After preparing a database and running the tool, you can then
run one or more @code{taler-exchange-aggregator} processes and measure how
quickly they perform the aggregation work.

@example
$ CONF=benchmark-rsa.conf
$ taler-exchange-dbinit -c "$CONF" --reset
$ ./taler-aggregator-benchmark -c "$CONF" -m 500 -r 10 -d 100
$ time taler-exchange-aggregator -c "$CONF" --test
@end example

This above commands will first create 100 deposits with 10 refunds into each
of 500 merchant accounts using randomized time stamps.  Afterwards, it will
time a single aggregator process in @code{--test} mode (asking it to terminate
as soon as there is no more pending work).

@node FIXMEs,Index,Benchmarking,Top
@anchor{taler-exchange-manual fixmes}@anchor{4b}
@chapter FIXMEs



@itemize *

@item 
We should have some summary with the inventory of services that should be
running.  Systemd by default doesn't show this nicely.  Maybe suggest running
"systemd list-dependencies taler-exchange.target"?

@item 
What happens when the TWG doesn't like one particular outgoing transaction?
How to recover from that as a sysadmin when it happens in practice?
@end itemize

@node Index,,FIXMEs,Top
@unnumbered Index


@printindex ge

@anchor{41}@w{                              }
@anchor{taler-exchange-manual tsref-type-LegitimizationMeasures}@w{                              }

@c %**end of body
@bye
