update prebuilt docs

54 files changed, 7179 insertions, 3025 deletions

diff --git a/man/taler-auditor-dbinit.1 b/man/taler-auditor-dbinit.1
index 169a9626..e094c0a1 100644
--- a/man/taler-auditor-dbinit.1
+++ b/man/taler-auditor-dbinit.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-AUDITOR-DBINIT" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-AUDITOR-DBINIT" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-auditor-dbinit \- setup auditor database
 .
@@ -33,36 +33,49 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-auditor\-dbinit\fP
-[\fB\-h\fP\ |\ \fB–help\fP] [\fB\-g\fP\ |\ \fB–gc\fP] [\fB\-R\fP\ |\ \fB–reset\fP] [\fB\-r\fP\ |\ \fB–restart\fP]
-[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-g\fP\ |\ \fB––gc\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-R\fP\ |\ \fB––reset\fP]
+[\fB\-r\fP\ |\ \fB––restart\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-dbinit\fP is a command line tool to initialize the Taler
+\fBtaler\-exchange\-dbinit\fP is a command\-line tool to initialize the Taler
 exchange database. It creates the necessary tables and indices for the
 Taler exchange to operate.
 .sp
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB–help\fP
-Print short help on options.
-.TP
-\fB\-g\fP | \fB–gc\fP
+\fB\-g\fP | \fB––gc\fP
 Garbage collect database. Deletes all unnecessary data in the
 database.
 .TP
-\fB\-R\fP | \fB–reset\fP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-R\fP | \fB––reset\fP
 Drop tables. Dangerous, will delete all existing data in the database.
 .TP
-\fB\-r\fP | \fB\-\-restart\fP
+\fB\-r\fP | \fB––restart\fP
 Restart all auditors from the beginning. Useful for
 testing.
 .TP
-\fB\-v\fP | \fB–version\fP
+\fB\-v\fP | \fB––version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
@@ -70,11 +83,11 @@ Print version information.
 taler\-auditor\-httpd(1), taler\-auditor(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://bugs.gnunet.org\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-auditor-exchange.1 b/man/taler-auditor-exchange.1
index 2e9706e8..13bee83e 100644
--- a/man/taler-auditor-exchange.1
+++ b/man/taler-auditor-exchange.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-AUDITOR-EXCHANGE" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-AUDITOR-EXCHANGE" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-auditor-exchange \- add or remove exchange from auditor’s list
 .
@@ -32,55 +32,66 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 ..
 .SH SYNOPSIS
 .sp
-\fBtaler\-auditor\-exchange\fP [\fB\-h\fP\ |\ \fB–help\fP] [\fB\-r\fP\ |\ \fB–remove\fP]
-[\fB\-m\fP\ \fIMASTERKEY\fP\ |\ \fB–exchange\-key=\fP‌\fIMASTERKEY\fP]
-[\fB\-u\fP\ \fIEXCHANGE_URL\fP\ |\ \fB–auditor\-url=\fP‌\fIEXCHANGE_URL\fP]
+\fBtaler\-auditor\-exchange\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-m\fP\ \fIMASTERKEY\fP\ |\ \fB––exchange\-key=\fP‌\fIMASTERKEY\fP]
+[\fB\-r\fP\ |\ \fB––remove\fP]
+[\fB\-u\fP\ \fIEXCHANGE_URL\fP\ |\ \fB––auditor\-url=\fP‌\fIEXCHANGE_URL\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-auditor\-exchange\fP is a command line tool to be used by an
-auditor to add or remove an exchange from the list of exchange’s audited
+\fBtaler\-auditor\-exchange\fP is a command\-line tool to be used by an
+auditor to add or remove an exchange from the list of exchanges audited
 by the auditor. You must add an exchange to that list before signing
-denomination keys with taler\-auditor\-sign or trying to audit it with
+denomination keys with taler\-auditor\-offline or trying to audit it with
 taler\-auditor or taler\-wire\-auditor. Afterwards the exchange will be
 visible via the /exchanges API of the taler\-auditor\-httpd.
 .INDENT 0.0
 .TP
-\fB\-m\fP \fIMASTERKEY\fP | \fB–exchange\-key=\fP‌\fIMASTERKEY\fP
-Public key of the exchange in Crockford base32 encoding, for example
-as generated by gnunet\-ecc \-p.
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the exchange to operate
+from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB–help\fP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-\fB\-u\fP \fIEXCHANGE_URL\fP | \fB–auditor\-url=\fP‌\fIEXCHANGE_URL\fP
-URL of the exchange. The exchange’s HTTP API must be available at
-this address.
+\fB\-m\fP \fIMASTERKEY\fP | \fB––exchange\-key=\fP‌\fIMASTERKEY\fP
+Public key of the exchange in Crockford base32 encoding, for example
+as generated by gnunet\-ecc \-p.
 .TP
-\fB\-r\fP | \fB–remove\fP
+\fB\-r\fP | \fB––remove\fP
 Instead of adding the exchange, remove it. Note that this will drop
 ALL data associated with that exchange, including existing auditing
 information. So use with extreme care!
+.TP
+\fB\-u\fP \fIEXCHANGE_URL\fP | \fB––auditor\-url=\fP‌\fIEXCHANGE_URL\fP
+URL of the exchange. The exchange’s HTTP API must be available at
+this address.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
 .UNINDENT
 .SH DIAGNOSTICS
 .sp
 \fBtaler\-auditor\-exchange\fP will return 0 on success, 1 on usage errors, 3 on problems interacting with the database backend, 4 if exchange entry to be added is already in the database (or already missing when used with \fB\-r\fP).
 .SH SEE ALSO
 .sp
-gnunet\-ecc(1), taler\-auditor\-sign(1), taler.conf(5)
+gnunet\-ecc(1), taler\-auditor\-offline(1), taler.conf(5)
 .SH BUGS
 .sp
 We should optionally verify the correctness of this exchange’s base URL
 and that it matches the master public key (note that the exchange may
-still be offline, so it should be possible to bypass such a verfication
+still be offline, so it should be possible to bypass such a verification
 step). Furthermore, if we do verification, as a (less secure)
 convenience option, we should make \fB\-\fP m optional and obtain it from
 the base URL.
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-auditor-httpd.1 b/man/taler-auditor-httpd.1
new file mode 100644
index 00000000..d8ec66fc
--- /dev/null
+++ b/man/taler-auditor-httpd.1
@@ -0,0 +1,96 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-AUDITOR-HTTPD" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-auditor-httpd \- HTTP server providing a RESTful API to access a Taler auditor
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-auditor\-httpd\fP
+[\fB\-C\fP\ |\ \fB––connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB––timeout\fP\fISECONDS\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-auditor\-httpd\fP is a command\-line tool to run the Taler auditor
+(HTTP backend).  The required configuration and database must exist
+before running this command.
+.SH OPTIONS
+.INDENT 0.0
+.TP
+\fB\-C\fP | \fB––connection\-close\fP
+Force each HTTP connection to be closed after each request
+(useful in combination with \-f to avoid having to wait for nc to
+time out).
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP\fIFILENAME\fP
+Use the configuration and other resources for the auditor to
+operate from FILENAME.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-t\fP \fISECONDS\fP | \fB––timeout=\fP\fISECONDS\fP
+Specifies the number of \fISECONDS\fP after which the HTTPD should close
+(idle) HTTP connections.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SIGNALS
+.INDENT 0.0
+.TP
+.B SIGTERM
+Sending a SIGTERM to the process will cause it to shutdown
+cleanly.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-auditor\-dbinit(1), taler\-auditor(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using Mantis \fI\%https://bugs.taler.net/\fP or by sending
+electronic mail to <\fI\%taler@gnu.org\fP>
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-auditor-offline.1 b/man/taler-auditor-offline.1
new file mode 100644
index 00000000..9164a812
--- /dev/null
+++ b/man/taler-auditor-offline.1
@@ -0,0 +1,354 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-AUDITOR-OFFLINE" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-auditor-offline \- Taler auditor certifies that it audits a Taler exchange
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-auditor\-offline\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+[subcommand …]
+.SH DESCRIPTION
+.sp
+\fBtaler\-auditor\-offline\fP is a command\-line tool to be used by an auditor to
+sign that he is aware of certain keys being used by a exchange. Using this
+signature, the auditor affirms that he will verify that the exchange is
+properly accounting for coins of those denominations.  The tool takes a list
+of subcommands as arguments which are then processed sequentially.
+.sp
+The tool includes two subcommands to interact \fIonline\fP with the exchange’s
+REST APIs.  The \fBdownload\fP subcommand downloads current public keys from the
+running exchange.  Note that this only includes keys that the exchange
+operator has previously validated using the \fBtaler\-exchange\-offline\fP tool.
+The resulting data serves as input to the \fBsign\fP and \fBshow\fP subcommands.
+.sp
+The \fBupload\fP subcommand uploads the signatures created with the private key to
+the exchange.  It handles the output of all subcommands (except \fBdownload\fP).
+The \fBdownload\fP and \fBupload\fP subcommands must naturally be run “online” and do not
+require access to the auditor’s private key, which should be kept offline.
+.sp
+All other subcommands are intended to be run “offline”. However, especially
+when testing, it is of course possible to run the subcommands online as well.
+Generally, subcommands read inputs (beyond command\-line arguments)
+from \fBstdin\fP\&. However, they may also consume outputs of previous
+subcommands.  The outputs of multiple subcommands are automatically combined,
+and if not consumed the final output is printed to \fBstdout\fP\&.
+.sp
+The general options for \fBtaler\-auditor\-offline\fP are:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the merchant to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH CONFIGURATION
+.sp
+The exchange and the \fBtaler\-auditor\-httpd\fP must both be provided with
+the auditor’s public key, such that they can validate messages signed
+by the auditor. To obtain the auditor’s public key, use:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ AUDITOR_PRIV_FILE=\(gataler\-config \-f \-c $CONF \-s AUDITOR \-o AUDITOR_PRIV_FILE\(ga
+$ gnunet\-ecc \-p $AUDITOR_PRIV_FILE
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Note that if the private key file does not yet exist, the above will fail.
+In this case, create the private key using:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ AUDITOR_PRIV_FILE=\(gataler\-config \-f \-c $CONF \-s AUDITOR \-o AUDITOR_PRIV_FILE\(ga
+$ AUDITOR_PRIV_DIR=\(gadirname $AUDITOR_PRIV_FILE\(ga
+$ mkdir \-p $AUDITOR_PRIV_DIR
+$ gnunet\-ecc \-g1 $AUDITOR_PRIV_FILE
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Relevant configuration options for \fBtaler\-auditor\-offline\fP are:
+.INDENT 0.0
+.IP \(bu 2
+\fB[auditor/AUDITOR_PRIV_FILE]\fP — where to store the private key
+.UNINDENT
+.SH SUBCOMMANDS
+.SS download
+.sp
+This subcommand must be run online. It downloads future signing and denomination
+keys with the associated meta data from the exchange and outputs the resulting
+JSON (for consumption by subsequent subcommands, or to \fBstdout\fP).
+.SS show
+.sp
+This subcommand outputs information about future signing and denomination keys for
+manual checking against the business\-approved fee structure, lifetimes and
+other parameters.
+.sp
+It consumes the output of the \fBdownload\fP subcommand, either from \fBstdin\fP or
+directly.
+.sp
+Its output always goes to \fBstdout\fP for human consumption (not in JSON).  It
+is usually a bad idea (but possible) to combine \fBshow\fP with other subcommands,
+except maybe for testing.
+.SS sign
+.sp
+This subcommand signs information about future signing and denomination keys.
+.sp
+It consumes the output of the \fBdownload\fP subcommand, either from \fBstdin\fP or
+directly.
+.sp
+It outputs the signatures over \fIall\fP denomination and signing keys
+present in the input, in a format suitable for the \fBupload\fP subcommand.
+.SS revoke\-denomination
+.sp
+This subcommand signs a revocation message for a denomination key.
+.sp
+The hash of the denomination public key must be given in the usual
+base32\-encoding as the first and only argument to the subcommand.
+.sp
+It outputs the signature affirming the revocation of the denomination key,
+in a format suitable for the \fBupload\fP subcommand.
+.SS revoke\-signkey
+.sp
+This subcommand signs a revocation message for an exchange online signing key.
+.sp
+The online signing public key must be given in the usual
+base32\-encoding as the first and only argument to the subcommand.
+.sp
+It outputs the signature affirming the revocation of the online signing key,
+in a format suitable for the \fBupload\fP subcommand.
+.SS enable\-auditor
+.sp
+This subcommand
+informs an exchange that an auditor is to be activated. Afterwards, the
+exchange will accept inputs from that auditor’s \fBtaler\-auditor\-offline\fP
+tool.  Note that the auditor also must add the exchange to the list of
+exchanges that it audits via \fBtaler\-auditor\-exchange\fP\&. Furthermore, the
+exchange’s database will need to be provided to the auditor.  This subcommand
+only informs the exchange about the auditor, but does not perform those
+additional mandatory steps for a working auditor.
+.sp
+The auditor’s public key must be given in the usual base32\-encoding as the
+first argument.
+.sp
+The auditor’s REST API base URL must be given as the second argument. The tool
+performs a minimal sanity check, namely that the URL begins with “http”
+(this also allows “https”), but as it runs offline does not perform any further
+validation!
+.sp
+The third argument must be a human\-readable name for the auditor. This may
+be shown to users and should identify the auditor’s business entity.  If
+the name includes spaces, the argument should be quoted.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the addition of the auditor,
+in a format suitable for the \fBupload\fP subcommand.
+.SS disable\-auditor
+.sp
+This subcommand
+informs an exchange that an auditor is to be deactivated. Afterwards, the
+exchange will refuse inputs from that auditor’s \fBtaler\-auditor\-offline\fP
+tool.
+.sp
+The auditor’s public key must be given in the usual base32\-encoding as the
+first argument.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the removal of the auditor,
+in a format suitable for the \fBupload\fP subcommand.
+.SS enable\-account
+.sp
+This subcommand
+informs an exchange that it should advertise a bank account as belonging to
+the exchange on its \fB/wire\fP endpoint.  Note that this does \fInot\fP ensure that
+the exchange will use this bank account for incoming or outgoing wire
+transfers! For this, the \fBtaler\-exchange\-transfer\fP and
+\fBtaler\-exchange\-wirewatch\fP tools must be configured.  Furthermore, the bank
+account information advertised could theoretically differ from that which
+these tool actually use, for example if the public bank account is only a
+front for the actual internal business acounts.
+.sp
+The \fBpayto://\fP URI (RFC 8905) of the exchange’s bank account must be given
+as the first argument to the subcommand.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the addition of the wire account,
+in a format suitable for the \fBupload\fP subcommand.
+.SS disable\-account
+.sp
+This subcommand
+informs an exchange that it should stop advertising a bank account as
+belonging to the exchange on its \fB/wire\fP endpoint.
+.sp
+The \fBpayto://\fP URI (RFC 8905) of the exchange’s (former) bank account must be
+given as the first argument to the subcommand.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the deletion of the wire account, in a
+format suitable for the \fBupload\fP subcommand.
+.SS wire\-fee
+.sp
+This subcommand informs an exchange about the desired wire fee (and closing fee)
+structure for particular wire method and a calendar year (!).  The tool does not
+permit changing wire fees during a calendar year. Also, once the wire fee has been
+set for a calendar year, it cannot be changed.
+.sp
+The subcommand takes the year, wire\-method (see RFC 8905, examples include
+\fBx\-taler\-bank\fP or \fBiban\fP), wire fee and closing fee as arguments.
+Instead of a year, the string \fBnow\fP can be given for the current year
+(this is mostly useful for test cases).  The wire\-method should follow the
+GANA registry as given in RFC 8905.  The fees must be given in the usual
+Taler format of \fBCURRENCY:NUMBER.FRACTION\fP\&.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the wire fees, in a format suitable for the
+\fBupload\fP subcommand.
+.SS upload
+.sp
+This subcommand uploads outputs from other subcommands (except \fBdownload\fP and \fBshow\fP)
+to the exchange.  Note that it is possible that some uploads succeed, while others
+fail, as the operation is not atomic.
+.sp
+The subcommand takes no arguments and has no output.
+.SS help
+.sp
+This subcommand shows a summary of all available subcommands with the
+required arguments.
+.SH EXAMPLES
+.SS Download public keys from an exchange (online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-auditor\-offline download > keys.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Show information about public keys (offline or online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-auditor\-offline show < keys.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Sign public keys (offline)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-auditor\-offline sign < keys.json > sigs.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Upload auditor signatures (online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-auditor\-offline upload < sigs.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Download, sign and upload, all in one (online)
+.sp
+Note that doing this is only recommended in non\-production deployments.
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-auditor\-offline download sign upload
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SH SECURITY CONSIDERATIONS
+.sp
+The \fBtaler\-auditor\-offline\fP tool assumes that it is run on a high\-security
+system, especially for the \fBsign\fP subcommand.
+.sp
+The auditor should first use the \fBshow\fP subcommand on the offline system to
+check that the keys being signed are acceptable. This process requires
+manual work: the auditor should check with the exchange operator that
+the keys (and meta data) matches that previously seen by the
+exchange operator when they used the \fBtaler\-exchange\-offline\fP tool.
+.SH SEE ALSO
+.sp
+gnunet\-ecc(1), taler\-auditor\-exchange(1), taler\-exchange\-offline(1),
+taler.conf(5)
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-auditor.1 b/man/taler-auditor.1
index 1e492b34..55cf0840 100644
--- a/man/taler-auditor.1
+++ b/man/taler-auditor.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-AUDITOR" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-AUDITOR" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-auditor \- audit exchange
 .
@@ -30,15 +30,20 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.sp
-\fBtaler\-auditor\fP \- audit exchange
 .SH SYNOPSIS
 .sp
-\fBtaler\-auditor\fP [\fB\-h\fP\ |\ \fB\-\-help\fP]
-[\fB\-m\fP\ \fIMASTER_KEY\fP\ |\ \fB\-\-exchange\-key=\fP‌\fIMASTER_KEY\fP]
+\fBtaler\-auditor\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-i**_|_\fP––internal**]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIMASTER_KEY\fP\ |\ \fB––exchange\-key=\fP‌\fIMASTER_KEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-auditor\fP is a command line tool to be used by an auditor to
+\fBtaler\-auditor\fP is a command\-line tool to be used by an auditor to
 audit an exchange’s database and calculate the current financial state
 of the exchange (including revenue, amount expected in escrow and risk
 exposure). The audit is incremental. The first audit must be performed
@@ -49,25 +54,48 @@ incoming and outgoing wire transfers that the bank claims to have
 matches the exchange’s database. Its options are as follows.
 .INDENT 0.0
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the merchant to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-\fB\-m\fP \fIKEY\fP | \fB\-\-exchange\-key=\fP‌\fIKEY\fP
+\fB\-i\fP | \fB––internal\fP
+Run additional checks that can only performed on the exchange\-internal
+database and not the "safe" replicated database at the auditor.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIKEY\fP | \fB––exchange\-key=\fP‌\fIKEY\fP
 Public master key of the exchange in Crockford base32 encoding, for
 example as generated by gnunet\-ecc \-p. If this option is missing,
 taler\-auditor will use the MASTER_PUBLIC_KEY value from the
 “exchange” section of the configuration.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
 .UNINDENT
 .SH SEE ALSO
 .sp
-gnunet\-ecc(1), taler\-auditor\-sign(1), taler.conf(5), taler\-auditor\-dbinit(1)
+gnunet\-ecc(1), taler\-auditor\-offline(1), taler.conf(5), taler\-auditor\-dbinit(1)
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://bugs.gnunet.org\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-aggregator.1 b/man/taler-exchange-aggregator.1
index fe0aed2f..4de350b6 100644
--- a/man/taler-exchange-aggregator.1
+++ b/man/taler-exchange-aggregator.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-AGGREGATOR" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-AGGREGATOR" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-aggregator \- aggregate deposits into wire transfers
 .
@@ -33,25 +33,43 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-aggregator\fP
-[\fB\-h\fP\ |\ \fB\-\-help\fP] [\fB\-t\fP\ |\ \fB\-\-test\fP] [\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB––test\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-aggregator\fP is a command line tool to run aggregate deposits
+\fBtaler\-exchange\-aggregator\fP is a command\-line tool to run aggregate deposits
 to the same merchant into larger wire transfers. The actual transfers are then
 done by \fBtaler\-exchange\-transfer\fP\&.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP | \fB––test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB––version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
@@ -60,11 +78,11 @@ taler\-exchange\-transfer(1), taler\-exchange\-closer(1),
 taler\-exchange\-httpd(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-benchmark.1 b/man/taler-exchange-benchmark.1
index 7b2a9d28..5d125fba 100644
--- a/man/taler-exchange-benchmark.1
+++ b/man/taler-exchange-benchmark.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-BENCHMARK" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-BENCHMARK" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-benchmark \- measure exchange performance
 .
@@ -33,14 +33,22 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-benchmark\fP
-[\fB\-c\fP\ \fICONFIG_FILENAME\fP\ |\ \fB\-\-config=\fP‌\fICONFIG_FILENAME\fP]
-[\fB\-b\fP\ \fIBANK_URL\fP\ |\ \fB—bank\-url=\fP‌\fIBANK_URL\fP] [\-f] [\-K]
-[\fB\-n\fP\ \fIHOWMANY_COINS\fP\ |\ \fB\-\-coins\-number=\fP‌\fIHOWMANY_COINS\fP]
-[\fB\-l\fP\ \fILOGLEVEL\fP\ |\ \fB\-\-log\-level=\fP‌\fILOGLEVEL\fP]
-[\fB\-h\fP\ |\ \fB\-\-help\fP]
+[\fB\-c\fP\ \fICONFIG_FILENAME\fP\ |\ \fB––config=\fP‌\fICONFIG_FILENAME\fP]
+[\fB\-F\fP\ |\ \fB––reserves\-first\fP]
+[\fB\-f\fP\ |\ \fB––fakebank\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-K\fP\ |\ \fB––linger\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––log\-level=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIMODE\fP\ |\ \fB––mode=\fP\fIMODE\fP]
+[\fB\-n\fP\ \fIHOWMANY_COINS\fP\ |\ \fB––coins\-number=\fP‌\fIHOWMANY_COINS\fP]
+[\fB\-p\fP\ \fINPROCS\fP\ |\ \fB––parallelism=\fP\fINPROCS\fP]
+[\fB\-R\fP\ \fIRATE\fP\ |\ \fB––refresh\-rate=\fP\fIRATE\fP]
+[\fB\-r\fP\ \fIN\fP\ |\ \fB––reserves=\fP\fIN\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-benchmark\fP is a command line tool to measure the time
+\fBtaler\-exchange\-benchmark\fP is a command\-line tool to measure the time
 spent to serve withdrawals/deposits/refreshes. It usually needs a
 dedicate configuration file where all the services \- the exchange and
 the (fake)bank \- listen to URLs not subject to any reverse proxy, as say
@@ -48,35 +56,51 @@ Nginx. Moreover, the benchmark runs on a “volatile” database, that means
 that table are always erased during a single benchmark run.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fICONFIG_FILENAME\fP | \fB\-\-config=\fP‌\fICONFIG_FILENAME\fP
+\fB\-c\fP \fICONFIG_FILENAME\fP | \fB––config=\fP‌\fICONFIG_FILENAME\fP
 (Mandatory) Use CONFIG_FILENAME.
 .TP
-\fB\-b\fP \fIBANK_URL\fP | \fB—bank\-url=\fP‌\fIBANK_URL\fP
-(Mandatory) The URL where the fakebank listens at. Must match the
-host component in the exchange’s escrow account “payto” URL.
+\fB\-F\fP | \fB––reserves\-first\fP
+Create all reserves first, before starting normal operations.
 .TP
-\fB\-f\fP | \fB\-\-fakebank\fP
+\fB\-f\fP | \fB––fakebank\fP
 Launch a fakebank instead of the Python bank. Only meaningful if the
 mode is to launch more than just a client.  Note that using the
 fakebank will cause the benchmark application to reset all databases
 as the fakebank is stateless and thus previous database state would
 inherently cause trouble.
 .TP
-\fB\-K\fP | \fB\-\-linger\fP
+\fB\-h\fP | \fB––help\fP
+Prints a compiled\-in help text.
+.TP
+\fB\-K\fP | \fB––linger\fP
 Linger around until keypress after the benchmark is done.
 .TP
-\fB\-n\fP \fIHOWMANY_COINS\fP | \fB\-\-coins\-number=\fP‌\fIHOWMANY_COINS\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––log\-level=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIMODE\fP | \fB––mode=\fP\fIMODE\fP
+Mode of operation. Accepted values are: \fBexchange\fP, \fBclients\fP, \fBboth\fP\&.
+.TP
+\fB\-n\fP \fIHOWMANY_COINS\fP | \fB––coins\-number=\fP‌\fIHOWMANY_COINS\fP
 Defaults to 1. Specifies how many coins this benchmark should
 withdraw and spend. After being spent, each coin will be refreshed
-with a REFRESH_PROBABILITY probability, which is (hardcoded as) 0.1;
-future versions of this tool should offer this parameter as a CLI
-option.
+with a probability RATE (see option \fB\-\-refresh\-rate\fP).
 .TP
-\fB\-l\fP \fILOGLEVEL\fP | \fB\-\-log\-level=\fP‌\fILOGLEVEL\fP
-GNUnet\-compatible log level, takes values “ERROR/WARNING/INFO/DEBUG”
+\fB\-p\fP \fINPROCS\fP | \fB––parallelism=\fP\fINPROCS\fP
+Run with \fINPROCS\fP client processes.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
-Prints a compiled\-in help text.
+\fB\-R\fP \fIRATE\fP | \fB––refresh\-rate=\fP\fIRATE\fP
+Defaults to 10.  Probability of refresh per coin (0\-100).
+.TP
+\fB\-r\fP \fIN\fP | \fB––reserves=\fP\fIN\fP
+Create \fIN\fP reserves per client.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
 .UNINDENT
 .SH SEE ALSO
 .sp
@@ -84,11 +108,11 @@ taler\-exchange\-dbinit(1), taler\-exchange\-keyup(1), taler\-merchant\-benchmar
 taler\-exchange\-httpd(1), taler.conf(5)
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-closer.1 b/man/taler-exchange-closer.1
index eebbfad7..ba6c6cb1 100644
--- a/man/taler-exchange-closer.1
+++ b/man/taler-exchange-closer.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-CLOSER" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-CLOSER" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-closer \- close idle reserves
 .
@@ -33,25 +33,43 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-closer\fP
-[\fB\-h\fP\ |\ \fB\-\-help\fP] [\fB\-t\fP\ |\ \fB\-\-test\fP] [\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB––test\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-closer\fP is a command line tool to run close
+\fBtaler\-exchange\-closer\fP is a command\-line tool to run close
 reserves that have been idle for too long, causing transfers
 to the originating bank account to be scheduled.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP | \fB––test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB––version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
@@ -59,11 +77,11 @@ Print version information.
 taler\-exchange\-transfer(1), taler\-exchange\-httpd(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-dbinit.1 b/man/taler-exchange-dbinit.1
index f504add2..07b3fc8a 100644
--- a/man/taler-exchange-dbinit.1
+++ b/man/taler-exchange-dbinit.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-DBINIT" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-DBINIT" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-dbinit \- initialize Taler exchange database
 .
@@ -33,29 +33,41 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-dbinit\fP
-[\fB\-h\fP\ |\ \fB–help\fP] [\fB\-g\fP\ |\ \fB–gc\fP] [\fB\-r\fP\ |\ \fB–reset\fP]
-[\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-g\fP\ |\ \fB––gc\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB––reset\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-dbinit\fP is a command line tool to initialize the Taler
+\fBtaler\-exchange\-dbinit\fP is a command\-line tool to initialize the Taler
 exchange database. It creates the necessary tables and indices for the
 Taler exchange to operate.
 .sp
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB–help\fP
-Print short help on options.
-.TP
-\fB\-g\fP | \fB–gc\fP
+\fB\-g\fP | \fB––gc\fP
 Garbage collect database. Deletes all unnecessary data in the
 database.
 .TP
-\fB\-r\fP | \fB–reset\fP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-r\fP | \fB––reset\fP
 Drop tables. Dangerous, will delete all existing data in the database
 before creating the tables.
 .TP
@@ -68,11 +80,11 @@ taler\-exchange\-httpd(1), taler\-exchange\-keyup(1),
 taler\-exchange\-reservemod(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://bugs.gnunet.org\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-httpd.1 b/man/taler-exchange-httpd.1
index 3de4d6de..adda1666 100644
--- a/man/taler-exchange-httpd.1
+++ b/man/taler-exchange-httpd.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-HTTPD" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-HTTPD" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-httpd \- run Taler exchange (with RESTful API)
 .
@@ -32,44 +32,44 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 ..
 .SH SYNOPSIS
 .sp
-\fBtaler\-exchange\-httpd\fP [\fB\-C\fP\ |\ \fB–connection\-close\fP]
-[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB–config=\fP‌\fIFILENAME\fP]
-[\fB\-f\fP\ \fIFILENAME\fP\ |\ \fB–file\-input=\fP‌\fIFILENAME\fP]
-[\fB\-h\fP\ |\ \fB–help\fP]
-[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB–loglevel=\fP‌\fILOGLEVEL\fP]
-[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB–timeout=\fP‌\fISECONDS\fP] [\fB\-v\fP\ |\ \fB–version\fP]
+\fBtaler\-exchange\-httpd\fP
+[\fB\-a\fP\ |\ \fB––allow\-timetravel\fP]
+[\fB\-C\fP\ |\ \fB––connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-f\fP\ \fIFILENAME\fP\ |\ \fB––file\-input=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-n\fP\ \fIN\fP\ |\ \fB––num\-threads=\fP\fIN\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fISECONDS\fP\ |\ \fB––timeout=\fP‌\fISECONDS\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-httpd\fP is a command line tool to run the Taler
+\fBtaler\-exchange\-httpd\fP is a command\-line tool to run the Taler
 exchange (HTTP server). The required configuration, keys and database
 must exist before running this command.
 .sp
 Its options are as follows:
 .INDENT 0.0
 .TP
-\fB\-a\fP | \fB–allow\-timetravel\fP
+\fB\-a\fP | \fB––allow\-timetravel\fP
 Allow clients to request /keys for arbitrary timestamps.
 This should only be enabled for testing and development,
 as clients could abuse this in denial of service attacks,
 as it makes the /keys response generation much more expensive.
 .TP
-\fB\-C\fP | \fB–connection\-close\fP
+\fB\-C\fP | \fB––connection\-close\fP
 Force each HTTP connection to be closed after each request (useful in
 combination with \fB\-f\fP to avoid having to wait for nc to time out).
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the merchant to operate
 from FILENAME.
 .TP
-\fB\-h\fP | \fB–help\fP
-Print short help on options.
-.TP
-\fB\-v\fP | \fB–version\fP
-Print version information.
-.TP
-\fB\-f\fP \fIFILENAME\fP | \fB–file\-input=\fP‌\fIFILENAME\fP
+\fB\-f\fP \fIFILENAME\fP | \fB––file\-input=\fP‌\fIFILENAME\fP
 This option is only available if the exchange was compiled with the
-configure option –enable\-developer\-mode. It is used for generating
+configure option ––enable\-developer\-mode. It is used for generating
 test cases against the exchange using AFL. When this option is
 present, the HTTP server will
 .INDENT 7.0
@@ -87,13 +87,30 @@ input from an HTTP client and then immediately exit. This is useful
 to test taler\-exchange\-httpd against many different possible inputs
 in a controlled way.
 .TP
-\fB\-t\fP \fISECONDS\fP | \fB–timeout=\fP‌\fISECONDS\fP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-n\fP \fIN\fP | \fB––num\-threads=\fP\fIN\fP
+Use \fIN\fP threads in the thread pool.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP \fISECONDS\fP | \fB––timeout=\fP‌\fISECONDS\fP
 Specifies the number of SECONDS after which the HTTPD should close
 (idle) HTTP connections.
 .TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
-Specifies the log level to use. Accepted values are: DEBUG, INFO,
-WARNING, ERROR.
+\fB\-v\fP | \fB––version\fP
+Print version information.
 .UNINDENT
 .SH SIGNALS
 .sp
@@ -120,11 +137,11 @@ taler\-exchange\-dbinit(1), taler\-exchange\-keyup(1),
 taler\-exchange\-reservemod(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-keycheck.1 b/man/taler-exchange-keycheck.1
deleted file mode 100644
index f91efe86..00000000
--- a/man/taler-exchange-keycheck.1
+++ /dev/null
@@ -1,77 +0,0 @@
-.\" Man page generated from reStructuredText.
-.
-.TH "TALER-EXCHANGE-KEYCHECK" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
-.SH NAME
-taler-exchange-keycheck \- check validity of Taler signing and denomination keys
-.
-.nr rst2man-indent-level 0
-.
-.de1 rstReportMargin
-\\$1 \\n[an-margin]
-level \\n[rst2man-indent-level]
-level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
--
-\\n[rst2man-indent0]
-\\n[rst2man-indent1]
-\\n[rst2man-indent2]
-..
-.de1 INDENT
-.\" .rstReportMargin pre:
-. RS \\$1
-. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
-. nr rst2man-indent-level +1
-.\" .rstReportMargin post:
-..
-.de UNINDENT
-. RE
-.\" indent \\n[an-margin]
-.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.nr rst2man-indent-level -1
-.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
-..
-.SH SYNOPSIS
-.sp
-\fBtaler\-exchange\-keycheck\fP
-[\fB\-h\fP\ |\ \fB–help\fP] [\fB\-v\fP\ |\ \fB–version\fP]
-.SH DESCRIPTION
-.sp
-\fBtaler\-exchange\-keycheck\fP can be used to check if the signing and
-denomination keys in the operation directory are well\-formed. This can
-be useful after importing fresh keys from the offline system to ensure
-that the files are correct.
-.sp
-Its options are as follows:
-.INDENT 0.0
-.TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
-Use the configuration and other resources for the exchange to operate
-from \fIFILENAME\fP\&.
-.TP
-\fB\-h\fP | \fB–help\fP
-Print short help on options.
-.TP
-\fB\-i\fP \fIAMOUNT\fP | \fB–denomination\-info\-hash=\fP‌\fIAMOUNT\fP
-Output the full denomination key hashes and the validity starting times of all denomination keys for the given \fIAMOUNT\fP\&.  Useful to identify hashes when revoking keys.
-.TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
-Specifies the log level to use. Accepted values are: DEBUG, INFO,
-WARNING, ERROR.
-.TP
-\fB\-v\fP | \fB–version\fP
-Print version information.
-.UNINDENT
-.SH SEE ALSO
-.sp
-taler\-exchange\-httpd(1), taler\-exchange\-keyup(1),
-taler\-exchange\-dbinit(1), taler.conf(5).
-.SH BUGS
-.sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
-mail to <\fI\%taler@gnu.org\fP>.
-.SH AUTHOR
-GNU Taler contributors
-.SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
-.\" Generated by docutils manpage writer.
-.
diff --git a/man/taler-exchange-keyup.1 b/man/taler-exchange-keyup.1
deleted file mode 100644
index 50621d88..00000000
--- a/man/taler-exchange-keyup.1
+++ /dev/null
@@ -1,106 +0,0 @@
-.\" Man page generated from reStructuredText.
-.
-.TH "TALER-EXCHANGE-KEYUP" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
-.SH NAME
-taler-exchange-keyup \- set up Taler exchange denomination and signing
-.
-.nr rst2man-indent-level 0
-.
-.de1 rstReportMargin
-\\$1 \\n[an-margin]
-level \\n[rst2man-indent-level]
-level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
--
-\\n[rst2man-indent0]
-\\n[rst2man-indent1]
-\\n[rst2man-indent2]
-..
-.de1 INDENT
-.\" .rstReportMargin pre:
-. RS \\$1
-. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
-. nr rst2man-indent-level +1
-.\" .rstReportMargin post:
-..
-.de UNINDENT
-. RE
-.\" indent \\n[an-margin]
-.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.nr rst2man-indent-level -1
-.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
-..
-.SH SYNOPSIS
-.sp
-\fBtaler\-exchange\-keyup\fP
-[\fB\-h\fP\ |\ \fB–help\fP] [\fB\-m\fP\ \fIFILE\fP\ |\ \fB–master\-key=\fP‌\fIFILE\fP]
-[\fB\-o\fP\ \fIFILE\fP\ |\ \fB–output=\fP‌\fIFILE\fP]
-[\fB\-r\fP\ \fIDKH\fP\ |\ \fB–revoke=\fP‌\fIDKH\fP]
-[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB–time=\fP‌\fITIMESTAMP\fP]
-[\fB\-v\fP\ |\ \fB–version\fP]
-.SH DESCRIPTION
-.sp
-\fBtaler\-exchange\-keyup\fP is a command line tool to setup Taler
-denomination and signing keys. This tool requires access to the
-exchange’s long\-term offline signing key and should be run in a secure
-(offline) environment under strict controls. The resulting keys can then
-be copied to the main online directory where the Taler HTTP server
-operates.
-.sp
-Its options are as follows:
-.INDENT 0.0
-.TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
-Use the configuration and other resources for the merchant to operate
-from FILENAME.
-.TP
-\fB\-f\fP \fIDIRNAME\fP | \fB–feedir=\fP‌\fIDIRNAME\fP
-Directory where to write the wire transfer fee structure. If not given,
-the one from the main configuration will be used.
-.TP
-\fB\-h\fP | \fB–help\fP
-Print short help on options.
-.TP
-\fB\-L\fP \fILOGLEVEL\fP | \fB–loglevel=\fP‌\fILOGLEVEL\fP
-Specifies the log level to use. Accepted values are: DEBUG, INFO,
-WARNING, ERROR.
-.TP
-\fB\-k\fP \fIBITS\fP | \fB–replacement\-keysize=\fP‌\fIBITS\fP
-When revoke an active denomination key (see \fB\-\-r\fP option), use
-\fIBITS\fP bit for the replacement denomination key. Default is 2048 (bits).
-.TP
-\fB\-m\fP \fIFILE\fP | \fB–master\-key=\fP‌\fIFILE\fP
-Location of the private EdDSA offline master key of the exchange. If not
-given, the location given in the configuration file will be used.
-.TP
-\fB\-o\fP \fIFILE\fP | \fB–output=\fP‌\fIFILE\fP
-Where to write a denomination key signing request file to be given to
-the auditor.
-.TP
-\fB\-r\fP \fIDKH\fP | \fB–revoke=\fP‌\fIDKH\fP
-Revoke the denomination key where the denomination public key’s hash
-is DKH.
-.TP
-\fB\-T\fP \fI[+/\-]MICROSECONDS\fP | \fB–timetravel=\fP‌\fI[+/\-]MICROSECONDS\fP
-Modify system time (as seen by this process) by the given offset (for debugging/testing).
-.TP
-\fB\-t\fP \fITIMESTAMP\fP | \fB–time=\fP‌\fITIMESTAMP\fP
-Operate as if the current time was \fITIMESTAMP\fP\&.
-.TP
-\fB\-v\fP | \fB–version\fP
-Print version information.
-.UNINDENT
-.SH SEE ALSO
-.sp
-taler\-exchange\-httpd(1), taler\-exchange\-keyup(1),
-taler\-exchange\-keycheck(1), taler.conf(5).
-.SH BUGS
-.sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
-mail to <\fI\%taler@gnu.org\fP>.
-.SH AUTHOR
-GNU Taler contributors
-.SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
-.\" Generated by docutils manpage writer.
-.
diff --git a/man/taler-exchange-offline.1 b/man/taler-exchange-offline.1
new file mode 100644
index 00000000..858183c5
--- /dev/null
+++ b/man/taler-exchange-offline.1
@@ -0,0 +1,442 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-EXCHANGE-OFFLINE" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-exchange-offline \- operations using the offline key of a Taler exchange
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-exchange\-offline\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+[subcommand …]
+.SH DESCRIPTION
+.sp
+\fBtaler\-exchange\-offline\fP is a command\-line tool to interact with the Taler
+exchange’s master private key. Most operations of this tool require access to
+the exchange’s long\-term offline signing key and should be run in a secure
+(offline) environment under strict controls.  The tool takes a list of
+subcommands as arguments which are then processed sequentially.
+.sp
+The tool includes two subcommands to interact \fIonline\fP with the exchange’s
+REST APIs.  The \fBdownload\fP subcommand downloads the future public keys from the
+running exchange.  The resulting data serves as input to the \fBsign\fP and \fBshow\fP
+subcommands.  The \fBupload\fP subcommand uploads the signatures created with the
+private master key to the exchange.  It handles the output of all subcommands
+(except \fBdownload\fP).  The \fBdownload\fP and \fBupload\fP subcommands must naturally be
+run “online” and do not require access to the offline key.
+.sp
+All other subcommands are intended to be run “offline”. However, especially
+when testing, it is of course possible to run the subcommands online as well.
+Generally, subcommands read inputs (beyond command\-line arguments)
+from \fBstdin\fP\&. However, they may also consume outputs of previous
+subcommands.  The outputs of multiple subcommands are automatically combined,
+and if not consumed the final output is printed to \fBstdout\fP\&.
+.sp
+The general options for \fBtaler\-exchange\-offline\fP are:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the merchant to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH CONFIGURATION
+.sp
+The exchange validates all operations by checking the signatures against the
+master public key that must be provided in the exchange configuration. To
+obtain the master public key, use:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ MASTER_PRIV_FILE=\(gataler\-config \-f \-c $CONF \-s EXCHANGE \-o MASTER_PRIV_FILE\(ga
+$ gnunet\-ecc \-p $MASTER_PRIV_FILE
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Note that if the private key file does not yet exist, the above will fail.
+In this case, create the private key using:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ MASTER_PRIV_FILE=\(gataler\-config \-f \-c $CONF \-s EXCHANGE \-o MASTER_PRIV_FILE\(ga
+$ MASTER_PRIV_DIR=\(gadirname $MASTER_PRIV_FILE\(ga
+$ mkdir \-p $MASTER_PRIV_DIR
+$ gnunet\-ecc \-g1 $MASTER_PRIV_FILE
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Relevant configuration options for \fBtaler\-exchange\-offline\fP are:
+.INDENT 0.0
+.IP \(bu 2
+\fB[exchange/BASE_URL]\fP — how to reach the exchange (for download/upload)
+.IP \(bu 2
+\fB[exchange\-offline/MASTER_PRIV_FILE]\fP — where to store the private keys
+.IP \(bu 2
+\fB[exchange\-offline/SECM_TOFU_FILE]\fP — where to store TOFU data
+.UNINDENT
+.SH SUBCOMMANDS
+.SS download
+.sp
+This subcommand must be run online. It downloads future signing and denomination
+keys with the associated meta data from the exchange and outputs the resulting
+JSON (for consumption by subsequent subcommands, or to \fBstdout\fP).
+.SS show
+.sp
+This subcommand outputs information about future signing and denomination keys for
+manual checking against the business\-approved fee structure, lifetimes and
+other parameters.
+.sp
+It consumes the output of the \fBdownload\fP subcommand, either from \fBstdin\fP or
+directly.
+However, if given arg \fB\-\fP (hyphen), this input is not consumed,
+but instead is passed to the next command.  This functions like the
+tee(1) command.
+.sp
+Its output always goes to \fBstdout\fP for human consumption (not in JSON).  It
+is usually a bad idea (but possible) to combine \fBshow\fP with other subcommands,
+except maybe for testing.
+.SS sign
+.sp
+This subcommand signs information about future signing and denomination keys.
+.sp
+It consumes the output of the \fBdownload\fP subcommand, either from \fBstdin\fP or
+directly.
+.sp
+It outputs the signatures over \fIall\fP denomination and signing keys
+present in the input, in a format suitable for the \fBupload\fP subcommand.
+.SS revoke\-denomination
+.sp
+This subcommand signs a revocation message for a denomination key.
+.sp
+The hash of the denomination public key must be given in the usual
+base32\-encoding as the first and only argument to the subcommand.
+.sp
+It outputs the signature affirming the revocation of the denomination key,
+in a format suitable for the \fBupload\fP subcommand.
+.SS revoke\-signkey
+.sp
+This subcommand signs a revocation message for an exchange online signing key.
+.sp
+The online signing public key must be given in the usual
+base32\-encoding as the first and only argument to the subcommand.
+.sp
+It outputs the signature affirming the revocation of the online signing key,
+in a format suitable for the \fBupload\fP subcommand.
+.SS enable\-auditor
+.sp
+This subcommand
+informs an exchange that an auditor is to be activated. Afterwards, the
+exchange will accept inputs from that auditor’s \fBtaler\-auditor\-offline\fP
+tool.  Note that the auditor also must add the exchange to the list of
+exchanges that it audits via \fBtaler\-auditor\-exchange\fP\&. Furthermore, the
+exchange’s database will need to be provided to the auditor.  This subcommand
+only informs the exchange about the auditor, but does not perform those
+additional mandatory steps for a working auditor.
+.sp
+The auditor’s public key must be given in the usual base32\-encoding as the
+first argument.
+.sp
+The auditor’s REST API base URL must be given as the second argument. The tool
+performs a minimal sanity check, namely that the URL begins with “http”
+(this also allows “https”), but as it runs offline does not perform any further
+validation!
+.sp
+The third argument must be a human\-readable name for the auditor. This may
+be shown to users and should identify the auditor’s business entity.  If
+the name includes spaces, the argument should be quoted.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the addition of the auditor,
+in a format suitable for the \fBupload\fP subcommand.
+.SS disable\-auditor
+.sp
+This subcommand
+informs an exchange that an auditor is to be deactivated. Afterwards, the
+exchange will refuse inputs from that auditor’s \fBtaler\-auditor\-offline\fP
+tool.
+.sp
+The auditor’s public key must be given in the usual base32\-encoding as the
+first argument.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the removal of the auditor,
+in a format suitable for the \fBupload\fP subcommand.
+.SS enable\-account
+.sp
+This subcommand
+informs an exchange that it should advertise a bank account as belonging to
+the exchange on its \fB/wire\fP endpoint.  Note that this does \fInot\fP ensure that
+the exchange will use this bank account for incoming or outgoing wire
+transfers! For this, the \fBtaler\-exchange\-transfer\fP and
+\fBtaler\-exchange\-wirewatch\fP tools must be configured.  Furthermore, the bank
+account information advertised could theoretically differ from that which
+these tool actually use, for example if the public bank account is only a
+front for the actual internal business acounts.
+.sp
+The \fBpayto://\fP URI (RFC 8905) of the exchange’s bank account must be given
+as the first argument to the subcommand.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the addition of the wire account,
+in a format suitable for the \fBupload\fP subcommand.
+.SS disable\-account
+.sp
+This subcommand
+informs an exchange that it should stop advertising a bank account as
+belonging to the exchange on its \fB/wire\fP endpoint.
+.sp
+The \fBpayto://\fP URI (RFC 8905) of the exchange’s (former) bank account must be
+given as the first argument to the subcommand.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the deletion of the wire account, in a
+format suitable for the \fBupload\fP subcommand.
+.SS wire\-fee
+.sp
+This subcommand informs an exchange about the desired wire fee (and closing fee)
+structure for particular wire method and a calendar year (!).  The tool does not
+permit changing wire fees during a calendar year. Also, once the wire fee has been
+set for a calendar year, it cannot be changed.
+.sp
+The subcommand takes the year, wire\-method (see RFC 8905, examples include
+\fBx\-taler\-bank\fP or \fBiban\fP), wire fee and closing fee as arguments.
+Instead of a year, the string \fBnow\fP can be given for the current year
+(this is mostly useful for test cases).  The wire\-method should follow the
+GANA registry as given in RFC 8905.  The fees must be given in the usual
+Taler format of \fBCURRENCY:NUMBER.FRACTION\fP\&.
+.sp
+The subcommand takes no inputs from \fBstdin\fP or other subcommands.
+.sp
+It outputs the signature affirming the wire fees, in a format suitable for the
+\fBupload\fP subcommand.
+.SS upload
+.sp
+This subcommand uploads outputs from other subcommands (except \fBdownload\fP and \fBshow\fP)
+to the exchange.  Note that it is possible that some uploads succeed, while others
+fail, as the operation is not atomic.
+.sp
+The subcommand takes no arguments and has no output.
+.SS help
+.sp
+This subcommand shows a summary of all available subcommands with the
+required arguments.
+.SH EXAMPLES
+.SS Download future public keys from an exchange (online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline download > keys.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Show information about future public keys (offline or online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline show < keys.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Sign future public keys (offline)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline sign < keys.json > sigs.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Upload signatures about future public keys (online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline upload < sigs.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Download, sign and upload, all in one (online)
+.sp
+Note that doing this is only recommended in non\-production deployments.
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline download sign upload
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Here is a variant that shows the output of \fBdownload\fP, but does not consume it,
+so that \fBsign\fP can see it as input, as in the variant without \fBshow\fP\&.
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline download show \- sign upload
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Create signature to enable bank account (offline)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline enable\-account payto://iban/DE24242 > account.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Upload bank account signature (online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline upload < account.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Combine signing keys and enabling bank account (offline)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline sign enable\-account payto://iban/DE24242 < keys.json > combo.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Upload various signatures (online)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline upload < combo.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS Create multiple revocation messages in one pass (offline)
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ taler\-exchange\-offline revoke\-denomination $DKH1 revoke\-denomination $DKH2 > revoke.json
+$ taler\-exchange\-offline revoke\-signkey $SK1 revoke\-signkey $SK2 > revoke.json
+$ taler\-exchange\-offline revoke\-signkey $SK revoke\-denomkey $DKH > mix.json
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+The outputs (“revoke.json”, “mix.json”) must be uploaded using the \fBupload\fP
+subcommand to the exchange to actually revoke the keys.
+.SH SECURITY CONSIDERATIONS
+.sp
+The \fBtaler\-exchange\-offline\fP tool assumes that it is run on a high\-security
+system with \fImonotonic time\fP\&. The time does not have to precisely match that
+of the exchange, but it must be monotonic across tool invocations. The clock
+of the offline system is used in the enable/disable signatures to communicate
+an order of the events to the exchange.  This prevents someone from replaying
+an older “enable” (or “disable”) message after a more recent “disable” (or
+“enable”) message has been provided to the exchange.  Thus, there is no need
+to keep the actual files exchanged with the offline tool secret.
+.sp
+The \fBtaler\-exchange\-offline\fP tool tries to make sure that the online signing
+keys of the the exchange are always created by the same two security modules.
+The goal here is to prevent an attacker who compromised \fBtaler\-exchange\-httpd\fP
+but \fInot\fP the security modules from providing attacker\-controlled keys to the
+offline signing process.
+.sp
+For this, the \fBtaler\-exchange\-offline\fP signing subcommand always
+automatically learns the security module’s public signing key and \fItrusts it
+on first use\fP (TOFU), but stores it to disk (see the \fBSECM_TOFU_FILE\fP option
+in the \fB[exchange\-offline]\fP section of the configuration).  If the keys
+change subsequently, the tool will refuse to sign.
+.SH SEE ALSO
+.sp
+taler\-exchange\-httpd(1), taler\-auditor\-offline(1), taler\-auditor\-exchange(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-exchange-secmod-eddsa.1 b/man/taler-exchange-secmod-eddsa.1
new file mode 100644
index 00000000..82020612
--- /dev/null
+++ b/man/taler-exchange-secmod-eddsa.1
@@ -0,0 +1,95 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-EXCHANGE-SECMOD-EDDSA" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-exchange-secmod-eddsa \- handle private EDDSA key operations for a Taler exchange
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-exchange\-secmod\-eddsa\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-p\fP\ \fIN\fP\ |\ ,**––parallelism=**\fIN\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB––time=\fP\fITIMESTAMP\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-exchange\-secmod\-eddsa\fP is a command\-line tool to
+handle private EDDSA key operations for a Taler exchange.
+.sp
+FIXME: More details.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the merchant to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fBp\fP \fIN\fP | \fB––parallelism=\fP\fIN\fP
+Run with \fIN\fP worker threads.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP \fITIMESTAMP\fP | \fB––time=\fP\fITIMESTAMP\fP
+Pretend it is \fITIMESTAMP\fP for the update.
+\fITIMESTAMP\fP is a human\-readable string (e.g., \fBYYYY\-MM\-DD HH:MM:SS\fP).
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-exchange\-httpd(1).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-exchange-secmod-rsa.1 b/man/taler-exchange-secmod-rsa.1
new file mode 100644
index 00000000..468ef0c7
--- /dev/null
+++ b/man/taler-exchange-secmod-rsa.1
@@ -0,0 +1,95 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-EXCHANGE-SECMOD-RSA" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-exchange-secmod-rsa \- handle private RSA key operations for a Taler exchange
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-exchange\-secmod\-rsa\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-p\fP\ \fIN\fP\ |\ ,**––parallelism=**\fIN\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-t\fP\ \fITIMESTAMP\fP\ |\ \fB––time=\fP\fITIMESTAMP\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-exchange\-secmod\-rsa\fP is a command\-line tool to
+handle private RSA key operations for a Taler exchange.
+.sp
+FIXME: More details.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the merchant to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fBp\fP \fIN\fP | \fB––parallelism=\fP\fIN\fP
+Run with \fIN\fP worker threads.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP \fITIMESTAMP\fP | \fB––time=\fP\fITIMESTAMP\fP
+Pretend it is \fITIMESTAMP\fP for the update.
+\fITIMESTAMP\fP is a human\-readable string (e.g., \fBYYYY\-MM\-DD HH:MM:SS\fP).
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-exchange\-httpd(1).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-exchange-transfer.1 b/man/taler-exchange-transfer.1
index 30255adb..446f0925 100644
--- a/man/taler-exchange-transfer.1
+++ b/man/taler-exchange-transfer.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-TRANSFER" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-TRANSFER" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-transfer \- execute wire transfers
 .
@@ -33,24 +33,42 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-transfer\fP
-[\fB\-h\fP\ |\ \fB\-\-help\fP] [\fB\-t\fP\ |\ \fB\-\-test\fP] [\fB\-v\fP\ |\ \fB\-\-version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel\fP\fIUSEC\fP]
+[\fB\-t\fP\ |\ \fB––test\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-transfer\fP is a command line tool to actually execute scheduled wire transfers (using the bank/wire gateway).
+\fBtaler\-exchange\-transfer\fP is a command\-line tool to actually execute scheduled wire transfers (using the bank/wire gateway).
 The transfers are prepared by the \fBtaler\-exchange\-aggregator\fP and \fBtaler\-exchange\-closer\fP tools.
 .INDENT 0.0
 .TP
-\fB\-c\fP \fIFILENAME\fP | \fB–config=\fP‌\fIFILENAME\fP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
 Use the configuration and other resources for the exchange to operate
 from \fIFILENAME\fP\&.
 .TP
-\fB\-h\fP | \fB\-\-help\fP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-\fB\-t\fP | \fB\-\-test\fP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP | \fB––test\fP
 Run in test mode and exit when idle.
 .TP
-\fB\-v\fP | \fB\-\-version\fP
+\fB\-v\fP | \fB––version\fP
 Print version information.
 .UNINDENT
 .SH SEE ALSO
@@ -59,11 +77,11 @@ taler\-exchange\-aggregator(1), taler\-exchange\-closer(1),
 taler\-exchange\-httpd(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-exchange-wire.1 b/man/taler-exchange-wire.1
deleted file mode 100644
index 15e746ba..00000000
--- a/man/taler-exchange-wire.1
+++ /dev/null
@@ -1,68 +0,0 @@
-.\" Man page generated from reStructuredText.
-.
-.TH "TALER-EXCHANGE-WIRE" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
-.SH NAME
-taler-exchange-wire \- create the master-key signed responses to /wire
-.
-.nr rst2man-indent-level 0
-.
-.de1 rstReportMargin
-\\$1 \\n[an-margin]
-level \\n[rst2man-indent-level]
-level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
--
-\\n[rst2man-indent0]
-\\n[rst2man-indent1]
-\\n[rst2man-indent2]
-..
-.de1 INDENT
-.\" .rstReportMargin pre:
-. RS \\$1
-. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
-. nr rst2man-indent-level +1
-.\" .rstReportMargin post:
-..
-.de UNINDENT
-. RE
-.\" indent \\n[an-margin]
-.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.nr rst2man-indent-level -1
-.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
-..
-.SH SYNOPSIS
-.sp
-\fBtaler\-exchange\-wire\fP [\fB\-h\fP\ |\ \fB–help\fP]
-[\fB\-m\fP\ \fIMASTERKEYFILE\fP\ |\ \fB–master=\fP‌\fIMASTERKEYFILE\fP]
-[\fB\-v\fP\ |\ \fB–version\fP]
-.SH DESCRIPTION
-.sp
-\fBtaler\-exchange\-wire\fP is used to create the exchange’s reply to a
-/wire request. It converts the bank details into the appropriate signed
-response. This needs to be done using the long\-term offline master key.
-.sp
-Its options are as follows:
-.INDENT 0.0
-.TP
-\fB\-h\fP | \fB–help\fP
-Print short help on options.
-.TP
-\fB\-m\fP \fIMASTERKEYFILE\fP | \fB–master=\fP‌\fIMASTERKEYFILE\fP
-Specifies the name of the file containing the exchange’s master key.
-.TP
-\fB\-v\fP | \fB–version\fP
-Print version information.
-.UNINDENT
-.SH SEE ALSO
-.sp
-taler\-exchange\-httpd(1), taler.conf(5).
-.SH BUGS
-.sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
-mail to <\fI\%taler@gnu.org\fP>.
-.SH AUTHOR
-GNU Taler contributors
-.SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
-.\" Generated by docutils manpage writer.
-.
diff --git a/man/taler-exchange-wirewatch.1 b/man/taler-exchange-wirewatch.1
index e8724a31..54797b8d 100644
--- a/man/taler-exchange-wirewatch.1
+++ b/man/taler-exchange-wirewatch.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-EXCHANGE-WIREWATCH" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-EXCHANGE-WIREWATCH" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-exchange-wirewatch \- watch for incoming wire transfers
 .
@@ -33,61 +33,61 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .SH SYNOPSIS
 .sp
 \fBtaler\-exchange\-wirewatch\fP
-[\fB\-t\fP\ \fIPLUGINNAME\fP\ |\ \fB–type=\fP‌\fIPLUGINNAME\fP] [\fB\-h\fP\ |\ \fB–help\fP]
-[\fB\-T\fP\ |\ \fB–test\fP] [\fB\-r\fP\ |\ \fB–reset\fP] [\fB\-v\fP\ |\ \fB–version\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB––reset\fP]
+[\fB\-T\fP\ |\ \fB––test\fP]
+[\fB\-t\fP\ \fIPLUGINNAME\fP\ |\ \fB––type=\fP‌\fIPLUGINNAME\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-exchange\-wirewatch\fP is a command line tool to import wire
+\fBtaler\-exchange\-wirewatch\fP is a command\-line tool to import wire
 transactions into the Taler exchange database.
 .sp
 Its options are as follows:
-.sp
-\fB\-t\fP \fIPLUGINNAME\fP | \fB–type=\fP‌\fIPLUGINNAME\fP
-.INDENT 0.0
-.INDENT 3.5
-Use the specified wire plugin and its configuration to talk to the
-bank.
-.UNINDENT
-.UNINDENT
-.sp
-\fB\-h\fP | \fB–help\fP
 .INDENT 0.0
-.INDENT 3.5
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the exchange to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
-.UNINDENT
-.UNINDENT
-.sp
-\fB\-T\fP | \fB–test\fP
-.INDENT 0.0
-.INDENT 3.5
-Run in test mode and exit when idle.
-.UNINDENT
-.UNINDENT
-.sp
-\fB\-r\fP | \fB–reset\fP
-.INDENT 0.0
-.INDENT 3.5
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-r\fP | \fB––reset\fP
 Ignore our own database and start with transactions from the
 beginning of time.
-.UNINDENT
-.UNINDENT
-.sp
-\fB\-v\fP | \fB–version\fP
-.INDENT 0.0
-.INDENT 3.5
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-t\fP | \fB––test\fP
+Run in test mode and exit when idle.
+.TP
+\fB\-v\fP | \fB––version\fP
 Print version information.
 .UNINDENT
-.UNINDENT
 .SH SEE ALSO
 .sp
 taler\-exchange\-aggregator(1), taler\-exchange\-httpd(1), taler.conf(5).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-helper-auditor-aggregation.1 b/man/taler-helper-auditor-aggregation.1
new file mode 100644
index 00000000..feb41b08
--- /dev/null
+++ b/man/taler-helper-auditor-aggregation.1
@@ -0,0 +1,94 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-HELPER-AUDITOR-AGGREGATION" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-helper-auditor-aggregation \- audit Taler exchange aggregation activity
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-helper\-auditor\-aggregation\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fBi\fP\ |\ \fB––internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB––exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-helper\-auditor\-aggregation\fP is a command\-line tool to
+audit exchange aggregation activity.
+.sp
+FIXME: More detail.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the auditor to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-i\fP | \fB––internal\fP
+Perform checks only applicable for exchange\-internal audits.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIKEY\fP | \fB––exchange\-key=\fP\fIKEY\fP
+Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-auditor(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-helper-auditor-coins.1 b/man/taler-helper-auditor-coins.1
new file mode 100644
index 00000000..231d5935
--- /dev/null
+++ b/man/taler-helper-auditor-coins.1
@@ -0,0 +1,94 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-HELPER-AUDITOR-COINS" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-helper-auditor-coins \- audit Taler coin processing
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-helper\-auditor\-coins\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fBi\fP\ |\ \fB––internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB––exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-helper\-auditor\-coins\fP is a command\-line tool to
+audit Taler coin processing.
+.sp
+FIXME: More detail.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the auditor to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-i\fP | \fB––internal\fP
+Perform checks only applicable for exchange\-internal audits.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIKEY\fP | \fB––exchange\-key=\fP\fIKEY\fP
+Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-auditor(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-helper-auditor-deposits.1 b/man/taler-helper-auditor-deposits.1
new file mode 100644
index 00000000..06d8a79f
--- /dev/null
+++ b/man/taler-helper-auditor-deposits.1
@@ -0,0 +1,94 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-HELPER-AUDITOR-DEPOSITS" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-helper-auditor-deposits \- audit Taler exchange database for deposit confirmation consistency
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-helper\-auditor\-deposits\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fBi\fP\ |\ \fB––internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB––exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-helper\-auditor\-deposits\fP is a command\-line tool to
+audit Taler exchange database for deposit confirmation consistency.
+.sp
+FIXME: More detail.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the auditor to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-i\fP | \fB––internal\fP
+Perform checks only applicable for exchange\-internal audits.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIKEY\fP | \fB––exchange\-key=\fP\fIKEY\fP
+Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-auditor(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-helper-auditor-reserves.1 b/man/taler-helper-auditor-reserves.1
new file mode 100644
index 00000000..94076681
--- /dev/null
+++ b/man/taler-helper-auditor-reserves.1
@@ -0,0 +1,94 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-HELPER-AUDITOR-RESERVES" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-helper-auditor-reserves \- audit Taler exchange reserve handling
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-helper\-auditor\-reserves\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fBi\fP\ |\ \fB––internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB––exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-helper\-auditor\-reserves\fP is a command\-line tool to
+audit Taler exchange reserve handling.
+.sp
+FIXME: More detail.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the auditor to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-i\fP | \fB––internal\fP
+Perform checks only applicable for exchange\-internal audits.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIKEY\fP | \fB––exchange\-key=\fP\fIKEY\fP
+Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-auditor(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-helper-auditor-wire.1 b/man/taler-helper-auditor-wire.1
new file mode 100644
index 00000000..1e8d0e6d
--- /dev/null
+++ b/man/taler-helper-auditor-wire.1
@@ -0,0 +1,94 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-HELPER-AUDITOR-WIRE" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-helper-auditor-wire \- audit exchange database for consistency with the bank's wire transfers
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-helper\-auditor\-wire\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fBi\fP\ |\ \fB––internal\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIKEY\fP\ |\ \fB––exchange\-key=\fP\fIKEY\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel=\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-helper\-auditor\-wire\fP is a command\-line tool to
+audit exchange database for consistency with the bank’s wire transfers.
+.sp
+FIXME: More detail.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the auditor to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-i\fP | \fB––internal\fP
+Perform checks only applicable for exchange\-internal audits.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIKEY\fP | \fB––exchange\-key=\fP\fIKEY\fP
+Use \fIKEY\fP (Crockford base32 encoded) as the public key of the exchange.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-auditor(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-merchant-benchmark.1 b/man/taler-merchant-benchmark.1
index 660a7b79..8a0edfc1 100644
--- a/man/taler-merchant-benchmark.1
+++ b/man/taler-merchant-benchmark.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-MERCHANT-BENCHMARK" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-MERCHANT-BENCHMARK" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-merchant-benchmark \- generate Taler-style benchmarking payments
 .
@@ -35,7 +35,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 \fBtaler\-merchant\-benchmark\fP [\fIsubcommand\fP] [\fIoptions\fP]
 .SH DESCRIPTION
 .sp
-\fBtaler\-merchant\-benchmark\fP is a command line tool to populate your
+\fBtaler\-merchant\-benchmark\fP is a command\-line tool to populate your
 merchant database with payments for benchmarking.
 .SH SUBCOMMANDS
 .INDENT 0.0
@@ -46,10 +46,10 @@ default instance) and aggregated by the exchange.  Takes the following
 options.
 .INDENT 7.0
 .TP
-.BI \-p \ PN\fP,\fB \ \-\-payments\-number\fB= PN
+\fB\-p\fP \fIPN\fP | \fB––payments\-number=\fP\fIPN\fP
 Perform PN many payments, defaults to 1.
 .TP
-.BI \-t \ TN\fP,\fB \ \-\-tracks\-number\fB= TN
+\fB\-t\fP \fITN\fP | \fB––tracks\-number=\fP\fITN\fP
 Perform TN many tracking operations, defaults to 1.
 .UNINDENT
 .TP
@@ -59,15 +59,11 @@ leaving payments unaggregated, or using a non\-default merchant
 instance.  Takes the following options.
 .INDENT 7.0
 .TP
-.BI \-t \ TC\fP,\fB \ \-\-two\-coins\fB= TC
+\fB\-t\fP \fITC\fP | \fB––two\-coins=\fP\fITC\fP
 Perform TC many payments that use two coins (normally, all the
 payments use only one coin).  TC defaults to 1.
 .TP
-.BI \-i \ AI\fP,\fB \ \-\-alt\-instance\fB= AI
-Use AI as the instance, instead of ‘default’ (which is the
-default instance used.)
-.TP
-.BI \-u \ UN\fP,\fB \ \-\-unaggregated\-number\fB= UN
+\fB\-u\fP \fIUN\fP | \fB––unaggregated\-number=\fP\fIUN\fP
 Generate UN payments that will be left unaggregated.  Note that
 subsequent invocations of the generator may pick those
 unaggregated payments and actually aggregated them.
@@ -76,43 +72,40 @@ unaggregated payments and actually aggregated them.
 .SH COMMON OPTIONS
 .INDENT 0.0
 .TP
-.BI \-k \ K\fP,\fB \ \-\-currency\fB= K
-Use currency K, mandatory.
-.TP
-.BI \-m \ URL\fP,\fB \ \-\-merchant\-url\fB= URL
-Use URL as the merchant base URL during the benchmark.  The URL
-is mainly used to download and pay for contracts.  Mandatory.
-.TP
-.BI \-b \ URL\fP,\fB \ \-\-bank\-url\fB= URL
-Use URL as the bank’s base URL during the benchmark.  The URL is
-used to test whether the bank is up and running.  Mandatory.
+\fB\-a\fP \fIAPIKEY\fP | \fB–apikey=\fP\fIAPIKEY\fP
+HTTP ‘Authorization’ header to send to the merchant.
 .TP
-.BI \-c \ FILENAME\fP,\fB \ \-\-config\fB= FILENAME
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP\fIFILENAME\fP
 Use the configuration and other resources for the merchant to
 operate from FILENAME.
 .TP
-.B \-h\fP,\fB  \-\-help
+\fB\-e\fP \fISECTION\fP | \fB–exchange\-account=\fP\fISECTION\fP
+Mandatory.
+Configuration \fISECTION\fP specifying the exchange account to use.
+.TP
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-.B \-v\fP,\fB  \-\-version
-Print version information.
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
 .TP
-.BI \-l \ LF\fP,\fB \ \-\-logfile\fB= LF
-Sends logs to file whose path is LF.
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
 .TP
-.BI \-L \ LOGLEVEL\fP,\fB \ \-\-log\fB= LOGLEVEL
-Use loglevel LOGLEVEL.
+\fB\-v\fP | \fB––version\fP
+Print version information.
 .UNINDENT
-.SH BUGS
-.sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
-mail to <\fI\%taler@gnu.org\fP>.
 .SH SEE ALSO
 .sp
 taler\-merchant\-dbinit(1), taler\-merchant\-tip\-enable(1), taler.conf(5)
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-merchant-dbinit.1 b/man/taler-merchant-dbinit.1
new file mode 100644
index 00000000..a0701658
--- /dev/null
+++ b/man/taler-merchant-dbinit.1
@@ -0,0 +1,84 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-MERCHANT-DBINIT" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-merchant-dbinit \- initialize Taler merchant database
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-merchant\-dbinit\fP
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-r\fP\ |\ \fB––reset\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-merchant\-dbinit\fP is a command\-line tool to initialize the Taler
+merchant database. It creates the necessary tables and indices for the
+Taler merchant to operate.
+.sp
+Its options are as follows:
+.INDENT 0.0
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the configuration and other resources for the merchant to operate
+from \fIFILENAME\fP\&.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-r\fP | \fB––reset\fP
+Drop tables. Dangerous, will delete all existing data in the database
+before creating the tables.
+.TP
+\fB\-v\fP | \fB–version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-merchant\-httpd(1), taler\-merchant\-setup\-reserve(1), taler.conf(5).
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-merchant-httpd.1 b/man/taler-merchant-httpd.1
index ed0f8250..b87556c6 100644
--- a/man/taler-merchant-httpd.1
+++ b/man/taler-merchant-httpd.1
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER-MERCHANT-HTTPD" "1" "Mar 22, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER-MERCHANT-HTTPD" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler-merchant-httpd \- run Taler merchant backend (with RESTful API)
 .
@@ -32,28 +32,47 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 ..
 .SH SYNOPSIS
 .sp
-\fBtaler\-merchant\-httpd\fP [\fIoptions\fP]
+\fBtaler\-merchant\-httpd\fP
+[\fB\-C\fP\ |\ \fB––connection\-close\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-T\fP\ \fIUSEC\fP\ |\ \fB––timetravel\fP\fIUSEC\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
 .SH DESCRIPTION
 .sp
-taler\-merchant\-httpd is a command line tool to run the Taler merchant
+\fBtaler\-merchant\-httpd\fP is a command\-line tool to run the Taler merchant
 (HTTP backend).  The required configuration and database must exist
 before running this command.
 .SH OPTIONS
 .INDENT 0.0
 .TP
-.B \-C\fP,\fB  \-\-connection\-close
+\fB\-C\fP | \fB––connection\-close\fP
 Force each HTTP connection to be closed after each request
 (useful in combination with \-f to avoid having to wait for nc to
 time out).
 .TP
-.BI \-c \ FILENAME\fP,\fB \ \-\-config\fB= FILENAME
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP\fIFILENAME\fP
 Use the configuration and other resources for the merchant to
 operate from FILENAME.
 .TP
-.B \-h\fP,\fB  \-\-help
+\fB\-h\fP | \fB––help\fP
 Print short help on options.
 .TP
-.B \-v\fP,\fB  \-\-version
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-T\fP \fIUSEC\fP | \fB––timetravel=\fP\fIUSEC\fP
+Modify the system time by \fIUSEC\fP microseconds.
+\fIUSEC\fP may be prefixed with \fB+\fP or \fB\-\fP (e.g. \fB\-T +300\fP).
+This option is intended for debugging/testing only.
+.TP
+\fB\-v\fP | \fB––version\fP
 Print version information.
 .UNINDENT
 .SH SIGNALS
@@ -63,16 +82,16 @@ Print version information.
 Sending a SIGTERM to the process will cause it to shutdown
 cleanly.
 .UNINDENT
-.SH BUGS
-.sp
-Report bugs by using Mantis <\fI\%https://gnunet.org/bugs/\fP> or by sending
-electronic mail to <\fI\%taler@gnu.org\fP>
 .SH SEE ALSO
 .sp
 taler\-merchant\-dbinit(1), taler\-merchant\-tip\-enable(1), taler.conf(5)
+.SH BUGS
+.sp
+Report bugs by using Mantis \fI\%https://bugs.taler.net/\fP or by sending
+electronic mail to <\fI\%taler@gnu.org\fP>
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/man/taler-merchant-setup-reserve.1 b/man/taler-merchant-setup-reserve.1
new file mode 100644
index 00000000..6d638e1f
--- /dev/null
+++ b/man/taler-merchant-setup-reserve.1
@@ -0,0 +1,134 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-MERCHANT-SETUP-RESERVE" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-merchant-setup-reserve \- setup reserve for tipping at a Taler merchant backend
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-merchant\-setup\-reserve\fP
+[\fB\-A\fP\ \fIUSERNAME:PASSWORD\fP\ |\ \fB––auth=\fP\fIUSERNAME:PASSWORD\fP]
+[\fB\-a\fP\ \fIVALUE\fP\ |\ \fB––amount=\fP\fIVALUE\fP]
+[\fB\-C\fP\ \fICERTFILE\fP\ |\ \fB––cert=\fP\fICERTFILE\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP\fIFILENAME\fP]
+[\fB\-e\fP\ \fIURL\fP\ |\ \fB––exchange\-url=\fP\fIURL\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-k\fP\ \fIKEYFILE\fP\ |\ \fB––key=\fP\fIKEYFILE\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-m\fP\ \fIURL\fP\ |\ \fB––merchant\-url=\fP\fIURL\fP]
+[\fB\-p\fP\ \fIKEYFILEPASSPHRASE\fP\ |\ \fB––pass=\fP\fIKEYFILEPASSPHRASE\fP]
+[\fB\-t\fP\ \fICERTTYPE\fP\ |\ \fB––type=\fP\fICERTTYPE\fP]
+[\fB\-w\fP\ \fIMETHOD\fP\ |\ \fB––wire\-method=\fP\fIMETHOD\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-merchant\-setup\-reserve\fP is a command\-line tool to setup a reserve
+(creating the private reserve key) and obtaining the wire transfer information
+from the exchange needed to fill the reserve.
+.SH OPTIONS
+.INDENT 0.0
+.TP
+\fB\-A\fP \fIUSERNAME:PASSWORD\fP | \fB––auth=\fP\fIUSERNAME:PASSWORD\fP
+Use \fBUSERNAME\fP and \fBPASSWORD\fP for HTTP client authentication.
+The “:” must be present as a separator.
+Note that this form of authentication has nothing to do with the TLS client
+certificate authentication supported with the \fB\-C\fP, \fB\-k\fP and \fB\-p\fP options.
+The \fBPASSWORD\fP given to this option is given to the server!
+.TP
+\fB\-a\fP \fIVALUE\fP | \fB––amount=\fP\fIVALUE\fP
+Mandatory.
+Amount to be transferred to the reserve.
+.TP
+\fB\-C\fP \fICERTFILE\fP | \fB––cert=\fP\fICERTFILE\fP
+The specified \fBCERTFILE\fP contains a TLS client certificate to be used to
+authenticate the client. See also \fB\-t\fP\&.
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP\fIFILENAME\fP
+Use the configuration and other resources for the merchant to
+operate from \fBFILENAME\fP\&.
+.TP
+\fB\-e\fP \fIURL\fP | \fB––exchange\-url=\fP\fIURL\fP
+Mandatory.
+Use \fBURL\fP for the exchange base URL.
+This is the exchange where the reserve will be created.
+The currency used in the amount specification must be offered by this exchange.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-k\fP \fIKEYFILE\fP | \fB––key=\fP\fIKEYFILE\fP
+The specified \fBKEYFILE\fP contains a TLS client private key to be used to
+authenticate the client. See also \fB\-p\fP and \fB\-C\fP\&.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-m\fP \fIURL\fP | \fB––merchant\-url=\fP\fIURL\fP
+Mandatory.
+Use \fBURL\fP as the merchant base URL.
+Should include the path to the instance if the reserve is to be
+created for a non\-default instance.
+.TP
+\fB\-p\fP \fIKEYFILEPASSPHRASE\fP | \fB––pass=\fP\fIKEYFILEPASSPHRASE\fP
+The specified \fBKEYFILEPASSPHRASE\fP is to be used to decrypt the KEYFILE.
+See also \fB\-k\fP\&. Not to be confused with \fB\-A\fP\&.
+The \fBKEYFILEPASSPHRASE\fP given here is only used locally to decrypt the KEYFILE.
+.TP
+\fB\-t\fP \fICERTTYPE\fP | \fB––type=\fP\fICERTTYPE\fP
+The specified CERTFILE contains a TLS client certificate of \fBCERTTYPE\fP\&.
+Default is \fBPEM\fP\&. See also \fB\-C\fP\&.
+.TP
+\fB\-w\fP \fIMETHOD\fP | \fB––wire\-method=\fP\fIMETHOD\fP
+Mandatory.
+Which wire method should be used.
+Needed to select the wire transfer method of the exchange.
+The method must be supported by the exchange.
+Typical values would be \fBiban\fP or \fBx\-taler\-bank\fP\&.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-merchant\-dbinit(1), taler.conf(5)
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>.
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler-wire-gateway-client.1 b/man/taler-wire-gateway-client.1
new file mode 100644
index 00000000..074ff63f
--- /dev/null
+++ b/man/taler-wire-gateway-client.1
@@ -0,0 +1,146 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "TALER-WIRE-GATEWAY-CLIENT" "1" "Jan 21, 2021" "0.8pre0" "GNU Taler"
+.SH NAME
+taler-wire-gateway-client \- trigger a transfer at the bank
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH SYNOPSIS
+.sp
+\fBtaler\-wire\-gateway\-client\fP
+[\fB\-a\fP\ \fIVALUE\fP\ |\ \fB––amount=\fP‌\fIVALUE\fP]
+[\fB\-b\fP\ \fIURL\fP\ |\ \fB––bank=\fP‌\fIURL\fP]
+[\fB\-C\fP\ \fIACCOUNT\fP\ |\ \fB––credit=\fP‌\fIACCOUNT\fP]
+[\fB\-c\fP\ \fIFILENAME\fP\ |\ \fB––config=\fP‌\fIFILENAME\fP]
+[\fB\-D\fP\ \fIACCOUNT\fP\ |\ \fB––debit=\fP‌\fIACCOUNT\fP]
+[\fB\-h\fP\ |\ \fB––help\fP]
+[\fB\-i\fP\ |\ \fB––credit\-history\fP]
+[\fB\-L\fP\ \fILOGLEVEL\fP\ |\ \fB––loglevel=\fP‌\fILOGLEVEL\fP]
+[\fB\-l\fP\ \fIFILENAME\fP\ |\ \fB––logfile=\fP‌\fIFILENAME\fP]
+[\fB\-o\fP\ |\ \fB––debit\-history\fP]
+[\fB\-p\fP\ \fIPASSPHRASE\fP\ |\ \fB––pass=\fP‌\fIPASSPHRASE\fP]
+[\fB\-S\fP\ \fISTRING\fP\ |\ \fB––subject=\fP‌\fISTRING\fP]
+[\fB\-s\fP\ \fIACCOUNT\-SECTION\fP\ |\ \fB––section=\fP‌\fIACCOUNT\-SECTION\fP]
+[\fB\-u\fP\ \fIUSERNAME\fP\ |\ \fB––user=\fP‌\fIUSERNAME\fP]
+[\fB\-v\fP\ |\ \fB––version\fP]
+[\fB\-w\fP\ \fIROW\fP\ |\ \fB––since\-when=\fP‌\fIROW\fP]
+.SH DESCRIPTION
+.sp
+\fBtaler\-wire\-gateway\-client\fP is a command\-line tool to trigger bank transfers or
+inspect wire transfers for exchange accounts using the wire API.  The tool is
+expected to be used during testing or for diagnostics.
+.sp
+You can do one of the following four operations during one invocation.
+.INDENT 0.0
+.INDENT 3.5
+.INDENT 0.0
+.IP 1. 3
+Execute wire transfer from the exchange to consumer account (\fB\-C\fP).
+.IP 2. 3
+Execute wire transfer from consumer account to the exchange (\fB\-D\fP).
+.IP 3. 3
+Inspect credit history of the exchange (\fB\-i\fP).
+.IP 4. 3
+Inspect debit history of the exchange (\fB\-o\fP).
+.UNINDENT
+.UNINDENT
+.UNINDENT
+.sp
+Doing more than one of these at a time will result in an error.  Note,
+however, that the \fB\-C\fP and \fB\-D\fP options also can be used to act as filters
+on transaction history operations.
+.SH OPTIONS
+.INDENT 0.0
+.TP
+\fB\-a\fP \fIVALUE\fP | \fB––amount=\fP‌\fIVALUE\fP
+Amount to transfer. Given in the Taler\-typical format of
+CURRENCY:VALUE.FRACTION.
+.TP
+\fB\-b\fP \fIURL\fP | \fB––bank=\fP‌\fIURL\fP
+URL at which the bank is operation.  Conflicts with \fB\-s\fP\&.
+.TP
+\fB\-C\fP \fIACCOUNT\fP | \fB––credit=\fP‌\fIACCOUNT\fP
+When doing a wire transfer from the exchange, the money should be credited to \fIACCOUNT\fP\&.
+Specifies the payto:// URI of the account.  Can also be used as a filter by credit
+account when looking at transaction histories.
+.TP
+\fB\-c\fP \fIFILENAME\fP | \fB––config=\fP‌\fIFILENAME\fP
+Use the given configuration file.
+.TP
+\fB\-D\fP \fIACCOUNT\fP | \fB––debit=\fP‌\fIACCOUNT\fP
+When doing a wire transfer to the exchange, the \fIACCOUNT\fP is to be debited.
+Specifies the payto:// URI of the account.  Can also be used as a filter by debit
+account when looking at transaction histories.
+.TP
+\fB\-h\fP | \fB––help\fP
+Print short help on options.
+.TP
+\fB\-i\fP | \fB––credit\-history\fP
+Obtain credit history of the exchange. Conflicts with \fB\-o\fP\&.
+.TP
+\fB\-L\fP \fILOGLEVEL\fP | \fB––loglevel=\fP‌\fILOGLEVEL\fP
+Specifies the log level to use. Accepted values are: \fBDEBUG\fP, \fBINFO\fP,
+\fBWARNING\fP, \fBERROR\fP\&.
+.TP
+\fB\-l\fP \fIFILENAME\fP | \fB––logfile=\fP‌\fIFILENAME\fP
+Send logging output to \fIFILENAME\fP\&.
+.TP
+\fB\-o\fP | \fB––debit\-history\fP
+Obtain debit history of the exchange. Conflicts with \fB\-i\fP\&.
+.TP
+\fB\-p\fP \fIPASSPHRASE\fP | \fB––pass=\fP‌\fIPASSPHRASE\fP
+Specifies the pass phrase for authentication.  Conflicts with \fB\-s\fP\&.
+.TP
+\fB\-S\fP \fISUBJECT\fP | \fB––subject=\fP‌\fISUBJECT\fP
+Use \fISUBJECT\fP for the wire transfer subject.  Must be a reserve public key for credit operations and a wire transfer identifier for debit operations. If not specified, a random value will be generated instead.
+.TP
+\fB\-s\fP \fIACCOUNT_SECTION\fP | \fB––section=\fP‌\fIACCOUNT\-SECTION\fP
+Obtain exchange account information from the \fIACCOUNT\-SECTION\fP of the configuration. Conflicts with \fB\-u\fP, \fB\-p\fP and \fB\-b\fP\&.  Note that either \fB\-b\fP or \fB\-s\fP must be specified.
+.TP
+\fB\-u\fP \fIUSERNAME\fP | \fB––user=\fP‌\fIUSERNAME\fP
+Specifies the username for authentication.  Optional and conflicts with \fB\-s\fP\&. If neither \fB\-u\fP nor \fB\-s\fP are used, we will attempt to talk to the bank without authentication.
+.TP
+\fB\-v\fP | \fB––version\fP
+Print version information.
+.TP
+\fB\-w\fP \fIROW\fP | \fB––since\-when=\fP‌\fIROW\fP
+Specifies a \fIROW\fP from which the history should be obtained. If not given, the 10 youngest transactions are returned.
+.UNINDENT
+.SH SEE ALSO
+.sp
+taler\-bank\-manage(1), taler.conf(5), \fI\%https://docs.taler.net/core/api\-wire.html#wire\-transfer\-test\-apis\fP
+.SH BUGS
+.sp
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
+mail to <\fI\%taler@gnu.org\fP>
+.SH AUTHOR
+GNU Taler contributors
+.SH COPYRIGHT
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+.\" Generated by docutils manpage writer.
+.
diff --git a/man/taler.conf.5 b/man/taler.conf.5
index 9877608a..637eeb06 100644
--- a/man/taler.conf.5
+++ b/man/taler.conf.5
@@ -1,6 +1,6 @@
 .\" Man page generated from reStructuredText.
 .
-.TH "TALER.CONF" "5" "Mar 21, 2020" "0.6pre1" "GNU Taler"
+.TH "TALER.CONF" "5" "Jan 21, 2021" "0.8pre0" "GNU Taler"
 .SH NAME
 taler.conf \- Taler configuration file
 .
@@ -32,21 +32,54 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 ..
 .SH DESCRIPTION
 .sp
-The basic structure of the configuration file is the following. The file
-is split into sections. Every section begins with “[SECTIONNAME]” and
-contains a number of options of the form “OPTION=VALUE”. Empty lines and
-lines beginning with a “#” are treated as comments. Files containing
-default values for many of the options described below are installed
-under $TALER_PREFIX/share/taler/config.d/. The configuration file given
-with \fB\-c\fP to Taler binaries overrides these defaults.
-.SS Global Options
+The configuration file is line\-oriented.
+Blank lines and whitespace at the beginning and end of a line are ignored.
+Comments start with \fB#\fP or \fB%\fP in the first column
+(after any beginning\-of\-line whitespace) and go to the end of the line.
+.sp
+The file is split into sections.
+Every section begins with “[SECTIONNAME]” and
+contains a number of options of the form “OPTION=VALUE”.
+There may be whitespace around the \fB=\fP (equal sign).
+Section names and options are \fIcase\-insensitive\fP\&.
+.sp
+The values, however, are \fIcase\-sensitive\fP\&.
+In particular, boolean values are one of \fBYES\fP or \fBNO\fP\&.
+Values can include whitespace by surrounding
+the entire value with \fB"\fP (double quote).
+Note, however, that there are no escape characters in such strings;
+all characters between the double quotes (including other double quotes)
+are taken verbatim.
+.sp
+Values that represent filenames can begin with a \fB/bin/sh\fP\-like
+variable reference.
+This can be simple, such as \fB$TMPDIR/foo\fP, or complex,
+such as \fB${TMPDIR:\-${TMP:\-/tmp}}/foo\fP\&.
+See \fB[PATHS]\fP (below).
+.sp
+Values that represent a time duration are represented as a series of one or
+more \fBNUMBER UNIT\fP pairs, e.g. \fB60 s\fP, \fB4 weeks 1 day\fP, \fB5 years 2 minutes\fP\&.
+.sp
+Values that represent an amount are in the usual amount syntax:
+\fBCURRENCY:VALUE.FRACTION\fP, e.g. \fBEUR:1.50\fP\&.
+.sp
+Files containing default values for many of the options described below
+are installed under \fB$TALER_PREFIX/share/taler/config.d/\fP\&.
+The configuration file given with \fB\-c\fP to Taler binaries
+overrides these defaults.
+.sp
+A configuration file may include another, by using the \fB@INLINE@\fP directive,
+for example, in \fBmain.conf\fP, you could write \fB@INLINE@ sub.conf\fP to
+include the entirety of \fBsub.conf\fP at that point in \fBmain.conf\fP\&.
+.. TODO: Document ‘taler\-config \-V’ in light of ‘@INLINE@’ in taler\-config(1).
+.SS GLOBAL OPTIONS
 .sp
 The following options are from the “[taler]” section and used by
 virtually all Taler components.
 .INDENT 0.0
 .TP
 .B CURRENCY
-Name of the currency, i.e.\ “EUR” for Euro.
+Name of the currency, e.g.\ “EUR” for Euro.
 .UNINDENT
 .sp
 The “[PATHS]” section is special in that it contains paths that can be
@@ -59,16 +92,16 @@ Home directory of the user, usually “${HOME}”. Can be overwritten by
 testcases by setting ${TALER_TEST_HOME}.
 .TP
 .B TALER_DATA_HOME
-Where should Taler store its long\-term data. Usually
-“${TALER_HOME}/.local/share/taler/”
+Where should Taler store its long\-term data.
+Usually “${TALER_HOME}/.local/share/taler/”.
 .TP
 .B TALER_CONFIG_HOME
-Where is the Taler configuration kept. Usually
-“${TALER_HOME}/.config/taler/”
+Where is the Taler configuration kept.
+Usually “${TALER_HOME}/.config/taler/”.
 .TP
 .B TALER_CACHE_HOME
-Where should Taler store cached data. Usually
-“${TALER_HOME}/.cache/taler/”
+Where should Taler store cached data.
+Usually “${TALER_HOME}/.cache/taler/”.
 .TP
 .B TALER_RUNTIME_DIR
 Where should Taler store system runtime data (like UNIX domain
@@ -81,222 +114,200 @@ exchange tools.
 .INDENT 0.0
 .TP
 .B DB
-Plugin to use for the database, i.e.\ “postgres”
+Plugin to use for the database, e.g.\ “postgres”.
 .TP
 .B PORT
-Port on which the HTTP server listens, i.e.\ 8080.
+Port on which the HTTP server listens, e.g.\ 8080.
 .TP
 .B MASTER_PUBLIC_KEY
 Crockford Base32\-encoded master public key, public version of the
-exchange\'s long\-time offline signing key.
+exchange’s long\-time offline signing key.
 .TP
 .B MASTER_PRIV_FILE
 Location of the master private key on disk. Only used by tools that
 can be run offline (as the master key is for offline signing).
 .TP
 .B BASE_URL
-Specifies the base URL under which the exchange can be reached. Added
-to wire transfers to enable tracking by merchants.
+The base URL under which the exchange can be reached.
+Added to wire transfers to enable tracking by merchants.
 .TP
 .B AGGREGATOR_IDLE_SLEEP_INTERVAL
-For how long should the aggregator sleep when it is idle before trying
-to look for more work? Default is 60 seconds.
-.TP
-.B SIGNKEY_DURATION
-For how long is a signing key valid?
+For how long should the aggregator sleep when it is idle
+before trying to look for more work? Default is 60 seconds.
 .TP
-.B LEGAL_DURATION
+.B SIGNKEY_LEGAL_DURATION
 For how long are signatures with signing keys legally valid?
 .TP
-.B LOOKAHEAD_SIGN
-How long do we generate denomination and signing keys ahead of time?
-.TP
-.B LOOKAHEAD_PROVIDE
-How long into the future do we provide signing and denomination keys
-to clients?
+.B MAX_KEYS_CACHING
+For how long should clients cache \fB/keys\fP responses at most?
 .TP
 .B TERMS_DIR
-Directory where the terms of service of the exchange operator can be fund. The directory must contain sub\-directories for every supported language, using the two\-character language code in lower case, i.e. "en/" or "fr/".  Each subdirectory must then contain files with the terms of service in various formats.  The basename of the file of the current policy must be specified under TERMS_ETAG.  The extension defines the mime type. Supported extensions include "html", "htm", "txt", "pdf", "jpg", "jpeg", "png" and "gif".  For example, using a TERMS_ETAG of "0", the structure could be the following:
-\- $TERMS_DIR/en/0.pdf
-\- $TERMS_DIR/en/0.html
-\- $TERMS_DIR/en/0.txt
-\- $TERMS_DIR/fr/0.pdf
-\- $TERMS_DIR/fr/0.html
-\- $TERMS_DIR/de/0.txt
+Directory where the terms of service of the exchange operator can be fund.
+The directory must contain sub\-directories for every supported language,
+using the two\-character language code in lower case, e.g. “en/” or “fr/”.
+Each subdirectory must then contain files with the terms of service in
+various formats.  The basename of the file of the current policy must be
+specified under \fBTERMS_ETAG\fP\&.  The extension defines the mime type.
+Supported extensions include “html”, “htm”, “txt”, “pdf”, “jpg”, “jpeg”,
+“png” and “gif”.  For example, using a \fBTERMS_ETAG\fP of “0”, the structure
+could be the following:
+.INDENT 7.0
+.IP \(bu 2
+$TERMS_DIR/en/0.pdf
+.IP \(bu 2
+$TERMS_DIR/en/0.html
+.IP \(bu 2
+$TERMS_DIR/en/0.txt
+.IP \(bu 2
+$TERMS_DIR/fr/0.pdf
+.IP \(bu 2
+$TERMS_DIR/fr/0.html
+.IP \(bu 2
+$TERMS_DIR/de/0.txt
+.UNINDENT
 .TP
 .B TERMS_ETAG
-Basename of the file(s) in the TERMS_DIR with the current terms of service.  The value is also used for the "Etag" in the HTTP request to control caching. Whenever the terms of service change, the TERMS_ETAG MUST also change, and old values MUST NOT be repeated.  For example, the date or version number of the terms of service SHOULD be used for the Etag.  If there are minor (i.e. spelling) fixes to the terms of service, the TERMS_ETAG probably SHOULD NOT be changed. However, whenever users must approve the new terms, the TERMS_ETAG MUST change.
+Basename of the file(s) in the \fBTERMS_DIR\fP with the current terms of service.
+The value is also used for the “Etag” in the HTTP request to control
+caching.  Whenever the terms of service change, the \fBTERMS_ETAG\fP MUST also
+change, and old values MUST NOT be repeated.  For example, the date or
+version number of the terms of service SHOULD be used for the Etag.  If
+there are minor (e.g. spelling) fixes to the terms of service, the
+\fBTERMS_ETAG\fP probably SHOULD NOT be changed. However, whenever users must
+approve the new terms, the \fBTERMS_ETAG\fP MUST change.
 .TP
 .B PRIVACY_DIR
-Works the same as TERMS_DIR, just for the privacy policy.
+Works the same as \fBTERMS_DIR\fP, just for the privacy policy.
 .TP
 .B PRIVACY_ETAG
-Works the same as TERMS_ETAG, just for the privacy policy.
+Works the same as \fBTERMS_ETAG\fP, just for the privacy policy.
 .UNINDENT
-.SS EXCHANGE DATABASE OPTIONS
+.SS EXCHANGE OFFLINE SIGNING OPTIONS
 .sp
-The following options must be in the section "[exchangedb]".
+The following options must be in the section “[exchange\-offline]”.
 .INDENT 0.0
 .TP
-.B DURATION_OVERLAP
-How much should validity periods for coins overlap?
-Should be long enough to avoid problems with
-wallets picking one key and then due to network latency
-another key being valid.  The DURATION_WITHDRAW period
-must be longer than this value.
-.TP
-.B IDLE_RESERVE_EXPIRATION_TIME
-After which time period should reserves be closed if they are idle?
-.TP
-.B LEGAL_RESERVE_EXPIRATION_TIME
-After what time do we forget about (drained) reserves during garbage collection?
-.UNINDENT
-.SS EXCHANGE POSTGRES BACKEND DATABASE OPTIONS
-.sp
-The following options must be in section “[exchangedb\-postgres]” if the
-“postgres” plugin was selected for the database.
-.INDENT 0.0
-.TP
-.B CONFIG
-How to access the database, i.e.\ “postgres:///taler” to use the
-“taler” database. Testcases use “talercheck”.
+.B MASTER_PRIV_FILE
+Where to store the offline private key of the exchange.
+Mandatory.
+.TP
+.B SECM_TOFU_FILE
+Where to store the public keys of both crypto helper modules.
+Used to persist the keys after the first invocation of the tool,
+so that if they ever change in the future, this is detected and
+the tool can abort.
+Mandatory.
+.TP
+.B SECM_DENOM_PUBKEY
+Public key of the (RSA) crypto helper module. Optional. If not given,
+we will rely on TOFU.  Note that once TOFU has been established,
+this option will also be ignored.
+.TP
+.B SECM_ESIGN_PUBKEY
+Public key of the (EdDSA) crypto helper module. Optional. If not given,
+we will rely on TOFU.  Note that once TOFU has been established,
+this option will also be ignored.
 .UNINDENT
-.SS MERCHANT OPTIONS
+.SS EXCHANGE RSA CRYPTO HELPER OPTIONS
 .sp
-The following options are from the “[merchant]” section and used by the
-merchant backend.
+The following options must be in the section “[taler\-helper\-crypto\-rsa]”.
 .INDENT 0.0
 .TP
-.B DB
-Plugin to use for the database, i.e.\ “postgres”
+.B LOOKAHEAD_SIGN
+How long do we generate denomination and signing keys ahead of time?
 .TP
-.B PORT
-Port on which the HTTP server listens, i.e.\ 8080.
+.B OVERLAP_DURATION
+How much should validity periods for coins overlap?
+Should be long enough to avoid problems with
+wallets picking one key and then due to network latency
+another key being valid.  The \fBDURATION_WITHDRAW\fP period
+must be longer than this value.
 .TP
-.B WIRE_TRANSFER_DELAY
-How quickly do we want the exchange to send us money? Note that wire
-transfer fees will be higher if we ask for money to be wired often.
-Given as a relative time, i.e.\ “5 s”
+.B SM_PRIV_KEY
+Where should the security module store its long\-term private key?
 .TP
-.B DEFAULT_MAX_WIRE_FEE
-Maximum wire fee we are willing to accept from exchanges. Given as a
-Taler amount, i.e.\ “EUR:0.1”
+.B KEY_DIR
+Where should the security module store the private keys it manages?
 .TP
-.B DEFAULT_MAX_DEPOSIT_FEE
-Maximum deposit fee we are willing to cover. Given as a Taler amount,
-i.e.\ “EUR:0.1”
+.B UNIXPATH
+On which path should the security module listen for signing requests?
 .UNINDENT
-.SS MERCHANT POSTGRES BACKEND DATABASE OPTIONS
 .sp
-The following options must be in section “[merchantdb\-postgres]” if the
-“postgres” plugin was selected for the database.
-.INDENT 0.0
-.TP
-.B CONFIG
-How to access the database, i.e.\ “postgres:///taler” to use the
-“taler” database. Testcases use “talercheck”.
-.UNINDENT
-.SS MERCHANT INSTANCES
+Note that the \fBtaler\-exchange\-secmod\-rsa\fP also evaluates the \fB[coin_*]\fP
+configuration sections described below.
+.SS EXCHANGE EDDSA CRYPTO HELPER OPTIONS
 .sp
-The merchant configuration must specify a set of instances, containing
-at least the “default” instance. The following options must be given in
-each “[instance\-NAME]” section.
+The following options must be in the section “[taler\-helper\-crypto\-eddsa]”.
 .INDENT 0.0
 .TP
-.B KEYFILE
-Name of the file where the instance\'s private key is to be stored,
-i.e.\ “${TALER_CONFIG_HOME}/merchant/instance/name.priv”
-.TP
-.B NAME
-Human\-readable name of the instance, i.e.\ “Kudos Inc.”
-.UNINDENT
-.sp
-Additionally, for instances that support tipping, the following options
-are required.
-.INDENT 0.0
+.B LOOKAHEAD_SIGN
+How long do we generate denomination and signing keys ahead of time?
 .TP
-.B TIP_EXCHANGE
-Base\-URL of the exchange that holds the reserve for tipping,
-i.e.\ “\fI\%https://exchange.demo.taler.net/\fP”
+.B OVERLAP_DURATION
+How much should validity periods for coins overlap?
+Should be long enough to avoid problems with
+wallets picking one key and then due to network latency
+another key being valid.  The \fBDURATION_WITHDRAW\fP period
+must be longer than this value.
 .TP
-.B TIP_EXCHANGE_PRIV_FILENAME
-Filename with the private key granting access to the reserve,
-i.e.\ “${TALER_CONFIG_HOME}/merchant/reserve/tip.priv”
-.UNINDENT
-.SS KNOWN EXCHANGES (for merchants and wallets)
-.sp
-The merchant configuration can include a list of known exchanges if the
-merchant wants to specify that certain exchanges are explicitly trusted.
-For each trusted exchange, a section [exchange\-NAME] must exist, where
-NAME is a merchant\-given name for the exchange. The following options
-must be given in each “[exchange\-NAME]” section.
-.INDENT 0.0
+.B DURATION
+For how long should EdDSA keys be valid for signing?
 .TP
-.B BASE_URL
-Base URL of the exchange, i.e.\ “\fI\%https://exchange.demo.taler.net/\fP”
+.B SM_PRIV_KEY
+Where should the security module store its long\-term private key?
 .TP
-.B MASTER_KEY
-Crockford Base32 encoded master public key, public version of the
-exchange\'s long\-time offline signing key
+.B KEY_DIR
+Where should the security module store the private keys it manages?
 .TP
-.B CURRENCY
-Name of the currency for which this exchange is trusted, i.e.\ “KUDOS”
+.B UNIXPATH
+On which path should the security module listen for signing requests?
 .UNINDENT
-.SS KNOWN AUDITORS (for merchants and wallets)
+.SS EXCHANGE DATABASE OPTIONS
 .sp
-The merchant configuration can include a list of known exchanges if the
-merchant wants to specify that certain auditors are explicitly trusted.
-For each trusted exchange, a section [auditor\-NAME] must exist, where
-NAME is a merchant\-given name for the exchange. The following options
-must be given in each “[auditor\-NAME]” section.
+The following options must be in the section “[exchangedb]”.
 .INDENT 0.0
 .TP
-.B BASE_URL
-Base URL of the auditor, i.e.\ “\fI\%https://auditor.demo.taler.net/\fP”
-.TP
-.B AUDITOR_KEY
-Crockford Base32 encoded auditor public key.
+.B IDLE_RESERVE_EXPIRATION_TIME
+After which time period should reserves be closed if they are idle?
 .TP
-.B CURRENCY
-Name of the currency for which this auditor is trusted, i.e.\ “KUDOS”
+.B LEGAL_RESERVE_EXPIRATION_TIME
+After what time do we forget about (drained) reserves during garbage collection?
 .UNINDENT
-.SS MERCHANT ACCOUNT OPTIONS
+.SS EXCHANGE POSTGRES BACKEND DATABASE OPTIONS
+.sp
+The following options must be in section “[exchangedb\-postgres]” if the
+“postgres” plugin was selected for the database.
 .INDENT 0.0
 .TP
-.B PAYTO_URI
-Specifies the payto://\-URL of the account. The general format is
-payto://METHOD/DETAILS.
-.TP
-.B WIRE_RESPONSE (exchange and merchant)
-Specifies the name of the file in which the wire details for this merchant
-account should be located. Used by the Taler exchange service and the
-taler\-merchant\-httpd (to generate and then use the file).
-.TP
-.B HONOR_instance
-Must be set to YES for the instances (where "instance" is the section
-name of the instance) of the merchant backend that should allow
-incoming wire transfers for this bank account.
-.TP
-.B ACTIVE_instance
-Must be set to YES for the instances (where “instance” is the section
-name of the instance) of the merchant backend that should use this
-bank account in new offers/contracts. Setting ACTIVE_instance to YES
-requires also setting HONOR_instance to YES.
+.B CONFIG
+How to access the database, e.g.\ “postgres:///taler” to use the
+“taler” database. Testcases use “talercheck”.
 .UNINDENT
 .SS EXCHANGE ACCOUNT OPTIONS
 .sp
 An exchange (or merchant) can have multiple bank accounts. The following
-options are for sections named “[account\-SOMETHING]”. The SOMETHING is
+options are for sections named “[exchange\-account\-SOMETHING]”. The \fBSOMETHING\fP is
 arbitrary and should be chosen to uniquely identify the bank account for
-the operator.
+the operator.  These options are used by the \fBtaler\-exchange\-transfer\fP
+and \fBtaler\-exchange\-wirewatch\fP tools.
 .INDENT 0.0
 .TP
 .B PAYTO_URI
 Specifies the payto://\-URL of the account. The general format is
-payto://METHOD/DETAILS.
+\fBpayto://$METHOD/$DETAILS\fP\&.  Examples:
+\fBpayto://x\-taler\-bank/localhost:8899/Exchange\fP or
+\fBpayto://iban/GENODEF1SLR/DE67830654080004822650/\fP or
+\fBpayto://iban/DE67830654080004822650/\fP (providing the BIC is optional).
+Note: only the wire\-method is actually used from the URI.
 .TP
 .B WIRE_GATEWAY_URL
-URL of the wire gateway
+URL of the wire gateway.  Typically of the form
+\fBhttps://$HOSTNAME[:$PORT]/taler\-wire\-gateway/$USERNAME/\fP
+where $HOSTNAME is the hostname of the system running the bank
+(such as the Taler Python bank or the Nexus) and \fB$USERNAME\fP is
+the username of the exchange’s bank account (usually matching
+the \fBUSERNAME\fP option used for authentication).  Example:
+\fBhttps://bank.demo.taler.net/taler\-wire\-gateway/Exchange/\fP\&.
 .TP
 .B WIRE_GATEWAY_AUTH_METHOD
 This option determines how the exchange (auditor/wirewatch/aggregator)
@@ -308,67 +319,30 @@ User name for \fBbasic\fP authentication with the wire gateway.
 .B PASSWORD
 Password for \fBbasic\fP authentication with the wire gateway.
 .TP
-.B WIRE_RESPONSE
-Specifies the name of the file in which the /wire response for this
-account should be located. Used by the Taler exchange service and the
-taler\-exchange\-wire tool.
-.TP
 .B ENABLE_DEBIT
-Must be set to YES for the accounts that the
-taler\-exchange\-aggregator should debit. Not used by merchants.
+Must be set to \fBYES\fP for the accounts that the
+\fBtaler\-exchange\-aggregator\fP and \fBtaler\-exchange\-closer\fP should debit.
 .TP
 .B ENABLE_CREDIT
-Must be set to YES for the accounts that the taler\-exchange\-wirewatch
+Must be set to \fBYES\fP for the accounts that the \fBtaler\-exchange\-wirewatch\fP
 should check for credits. It is yet uncertain if the merchant
 implementation may check this flag as well.
 .UNINDENT
-.SS TALER\-BANK AUTHENTICATION OPTIONS (for accounts)
-.sp
-The following authentication options are supported by the “taler\-bank”
-wire plugin. They must be specified in the “[account\-]” section that
-uses the “taler\-bank” plugin.
-.INDENT 0.0
-.TP
-.B TALER_BANK_AUTH_METHOD
-Authentication method to use. “none” or “basic” are currently
-supported.
-.TP
-.B USERNAME
-Username to use for authentication. Used with the “basic”
-authentication method.
-.TP
-.B PASSWORD
-Password to use for authentication. Used with the “basic”
-authentication method.
-.UNINDENT
-.SS EXCHANGE WIRE FEE OPTIONS
-.sp
-For each supported wire method (i.e.\ “x\-taler\-bank” or “sepa”), sections
-named “[fees\-METHOD]” state the (aggregate) wire transfer fee and the
-reserve closing fees charged by the exchange. Note that fees are
-specified using the name of the wire method, not by the plugin name. You
-need to replace “YEAR” in the option name by the calendar year for which
-the fee should apply. Usually, fees should be given for serveral years
-in advance.
-.INDENT 0.0
-.TP
-.B WIRE\-FEE\-YEAR
-Aggregate wire transfer fee merchants are charged in YEAR. Specified
-as a Taler amount using the usual amount syntax
-(CURRENCY:VALUE.FRACTION).
-.TP
-.B CLOSING\-FEE\-YEAR
-Reserve closing fee customers are charged in YEAR. Specified as a
-Taler amount using the usual amount syntax (CURRENCY:VALUE.FRACTION).
-.UNINDENT
 .SS EXCHANGE COIN OPTIONS
 .sp
-The following options must be in sections starting with \fB"[coin_]"\fP and
-are used by taler\-exchange\-keyup to create denomination keys.
+The following options must be in sections starting with \fB"[coin_]"\fP and are
+largely used by \fBtaler\-exchange\-httpd\fP to determine the meta data for the
+denomination keys.  Some of the options are used by the
+\fBtaler\-exchange\-secmod\-rsa\fP to determine which RSA keys to create (and of
+what key length).  Note that the section names must match, so this part of the
+configuration MUST be shared between the RSA helper and the exchange.
+Configuration values MUST NOT be changed in a running setup. Instead, if
+parameters for a denomination type are to change, a fresh \fIsection name\fP should
+be introduced (and the existing section should be deleted).
 .INDENT 0.0
 .TP
 .B VALUE
-Value of the coin, i.e.\ “EUR:1.50” for 1 Euro and 50 Cents (per
+Value of the coin, e.g.\ “EUR:1.50” for 1 Euro and 50 Cents (per
 coin).
 .TP
 .B DURATION_WITHDRAW
@@ -378,8 +352,11 @@ this value?
 .B DURATION_SPEND
 How long do clients have to spend these coins?
 .TP
+.B DURATION_LEGAL
+How long does the exchange have to keep records for this denomination?
+.TP
 .B FEE_WITHDRAW
-What fee is charged for withdrawl?
+What fee is charged for withdrawal?
 .TP
 .B FEE_DEPOSIT
 What fee is charged for depositing?
@@ -394,6 +371,84 @@ fee is returned. Instead, the refund fee is charged to the customer.
 .B RSA_KEYSIZE
 What is the RSA keysize modulos (in bits)?
 .UNINDENT
+.SS MERCHANT OPTIONS
+.sp
+The following options are from the “[merchant]” section and used by the
+merchant backend.
+.INDENT 0.0
+.TP
+.B DB
+Plugin to use for the database, e.g._“postgres”.
+.TP
+.B PORT
+Port on which the HTTP server listens, e.g.\ 8080.
+.TP
+.B LEGAL_PRESERVATION
+How long do we keep data in the database for tax audits after the
+transaction has completed?  Default is 10 years.
+.TP
+.B FORCE_AUDIT
+Force the merchant to report every transaction to the auditor
+(if the exchange has an auditor)?  Default is \fBNO\fP\&.
+Do not change except for testing.
+.UNINDENT
+.SS MERCHANT POSTGRES BACKEND DATABASE OPTIONS
+.sp
+The following options must be in section “[merchantdb\-postgres]” if the
+“postgres” plugin was selected for the database.
+.INDENT 0.0
+.TP
+.B CONFIG
+How to access the database, e.g.\ “postgres:///taler” to use the
+“taler” database. Testcases use “talercheck”.
+.UNINDENT
+.SS KNOWN EXCHANGES (for merchants)
+.sp
+The merchant configuration can include a list of known exchanges if the
+merchant wants to specify that certain exchanges are explicitly trusted.
+For each trusted exchange, a section [merchant\-exchange\-$NAME] must exist, where
+$NAME is a merchant\-given name for the exchange. The following options
+must be given in each “[exchange\-$NAME]” section.
+.INDENT 0.0
+.TP
+.B EXCHANGE_BASE_URL
+Base URL of the exchange, e.g.\ “\fI\%https://exchange.demo.taler.net/\fP”
+.TP
+.B MASTER_KEY
+Crockford Base32 encoded master public key, public version of the
+exchange’s long\-time offline signing key.  Can be omitted, in that
+case the exchange will NOT be trusted unless it is audited by
+a known auditor.
+Omitting \fBMASTER_KEY\fP can be useful if we do not trust the exchange
+without an auditor, but should pre\-load the keys of this
+particular exchange on startup instead of waiting for it to be
+required by a client.
+.TP
+.B CURRENCY
+Name of the currency for which this exchange is used, e.g.\ “KUDOS”.
+The entire section is ignored if the currency does not match the currency
+we use, which must be given in the \fB[taler]\fP section.
+.UNINDENT
+.SS KNOWN AUDITORS (for merchants)
+.sp
+The merchant configuration can include a list of known exchanges if the
+merchant wants to specify that certain auditors are explicitly trusted.
+For each trusted exchange, a section “[merchant\-auditor\-$NAME]” must exist, where
+\fB$NAME\fP is a merchant\-given name for the auditor. The following options
+must be given in each “[merchant\-auditor\-$NAME]” section.
+.INDENT 0.0
+.TP
+.B AUDITOR_BASE_URL
+Base URL of the auditor, e.g.\ “\fI\%https://auditor.demo.taler.net/\fP”
+.TP
+.B AUDITOR_KEY
+Crockford Base32 encoded auditor public key.
+.TP
+.B CURRENCY
+Name of the currency for which this auditor is trusted, e.g.\ “KUDOS”
+The entire section is ignored if the currency does not match the currency
+we use, which must be given in the \fB[taler]\fP section.
+.UNINDENT
 .SS AUDITOR OPTIONS
 .sp
 The following options must be in section “[auditor]” for the Taler
@@ -401,10 +456,17 @@ auditor.
 .INDENT 0.0
 .TP
 .B DB
-Plugin to use for the database, i.e.\ “postgres”
+Plugin to use for the database, e.g.\ “postgres”
 .TP
 .B AUDITOR_PRIV_FILE
-Name of the file containing the auditor’s private key
+Name of the file containing the auditor’s private key.
+.TP
+.B PUBLIC_KEY
+Crockford Base32 encoded auditor public key.  Used by (online) auditor
+processes that do not have access to the (offline) auditor private key file.
+.TP
+.B BASE_URL
+Base URL of the auditor, e.g.\ “\fI\%https://auditor.demo.taler.net/\fP”
 .UNINDENT
 .SS AUDITOR POSTGRES BACKEND DATABASE OPTIONS
 .sp
@@ -413,20 +475,20 @@ The following options must be in section “[auditordb\-postgres]” if the
 .INDENT 0.0
 .TP
 .B CONFIG
-How to access the database, i.e.\ "postgres:///taler" to use the
-"taler" database. Testcases use “talercheck”.
+How to access the database, e.g.\ “postgres:///taler” to use the
+“taler” database. Testcases use “talercheck”.
 .UNINDENT
 .SH SEE ALSO
 .sp
 taler\-exchange\-dbinit(1), taler\-exchange\-httpd(1),
-taler\-exchange\-keyup(1), taler\-exchange\-wire(1).
+taler\-exchange\-offline(1), taler\-auditor\-offline(1).
 .SH BUGS
 .sp
-Report bugs by using \fI\%https://gnunet.org/bugs/\fP or by sending electronic
+Report bugs by using \fI\%https://bugs.taler.net/\fP or by sending electronic
 mail to <\fI\%taler@gnu.org\fP>.
 .SH AUTHOR
 GNU Taler contributors
 .SH COPYRIGHT
-2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 .\" Generated by docutils manpage writer.
 .
diff --git a/texinfo/onboarding-figures/exchange-db.png b/texinfo/onboarding-figures/exchange-db.png
deleted file mode 100644
index 421e5941..00000000
--- a/texinfo/onboarding-figures/exchange-db.png
+++ /dev/null
diff --git a/texinfo/onboarding.texi b/texinfo/onboarding.texi
deleted file mode 100644
index 0ae99b39..00000000
--- a/texinfo/onboarding.texi
+++ /dev/null
@@ -1,663 +0,0 @@
-\input texinfo   @c -*-texinfo-*-
-@c %**start of header
-@setfilename onboarding.info
-@documentencoding UTF-8
-@ifinfo
-@*Generated by Sphinx 2.2.0.@*
-@end ifinfo
-@settitle Taler Onboarding Manual
-@defindex ge
-@paragraphindent 0
-@exampleindent 4
-@finalout
-@dircategory CATEGORY
-@direntry
-* MENU ENTRY: (onboarding.info). DESCRIPTION
-@end direntry
-
-@definfoenclose strong,`,'
-@definfoenclose emph,`,'
-@c %**end of header
-
-@copying
-@quotation
-GNU Taler 0.6.0pre1, Sep 18, 2019
-
-GNU Taler team
-
-Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
-@end quotation
-
-@end copying
-
-@titlepage
-@title Taler Onboarding Manual
-@insertcopying
-@end titlepage
-@contents
-
-@c %** start of user preamble
-
-@c %** end of user preamble
-
-@ifnottex
-@node Top
-@top Taler Onboarding Manual
-@insertcopying
-@end ifnottex
-
-@c %**start of body
-@anchor{onboarding doc}@anchor{0}
-@menu
-* Taler installation:: 
-* Building the documentation:: 
-* Building the Websites.: Building the Websites. 
-* Code coverage.: Code coverage. 
-* Online services checker.: Online services checker. 
-* Topping the tip reserve up:: 
-* Producing auditor reports:: 
-* Releases:: 
-* Code:: 
-* Bugtracking:: 
-* Continuous integration:: 
-* Code coverage: Code coverage<2>. 
-* Appendix:: 
-
-@detailmenu
- --- The Detailed Node Listing ---
-
-Taler installation
-
-* User Acccounts:: 
-* Compile and switch color.: Compile and switch color. 
-* Full bootstrap.: Full bootstrap. 
-* How to upgrade the code.: How to upgrade the code. 
-
-Releases
-
-* Release Process and Checklists:: 
-* Tagging:: 
-* Database for tests:: 
-* Exchange@comma{} merchant: Exchange merchant. 
-* Wallet WebExtension:: 
-* Upload to GNU mirrors:: 
-
-Appendix
-
-* Testing library:: 
-
-@end detailmenu
-@end menu
-
-@node Taler installation,Building the documentation,Top,Top
-@anchor{onboarding developer-onboarding-manual}@anchor{1}@anchor{onboarding taler-installation}@anchor{2}
-@chapter Taler installation
-
-
-This section describes the GNU Taler deployment on @code{gv.taler.net}.
-
-@menu
-* User Acccounts:: 
-* Compile and switch color.: Compile and switch color. 
-* Full bootstrap.: Full bootstrap. 
-* How to upgrade the code.: How to upgrade the code. 
-
-@end menu
-
-@node User Acccounts,Compile and switch color,,Taler installation
-@anchor{onboarding user-acccounts}@anchor{3}
-@section User Acccounts
-
-
-On @code{gv.taler.net}, there are four users that are set up to serve Taler on
-the internet:
-
-
-@itemize -
-
-@item 
-@code{taler-test}: serves @code{*.test.taler.net} and gets automatically
-built by Buildbot.
-
-@item 
-@code{taler-internal}: serves @code{*.int.taler.net}, and does @emph{NOT} get
-automatically built.
-@end itemize
-
-The following two users are @emph{never} automatically built, and they both
-serve @code{*.demo.taler.net}. At any given time, only one is active and
-serves the HTTP requests from the outside; the other one can so be
-compiled without any downtime. If the compilation succeeds, the inactive
-user can be switched to become active (see next section), and vice versa.
-
-
-@itemize -
-
-@item 
-@code{demo-blue}
-
-@item 
-@code{demo-green}
-@end itemize
-
-@node Compile and switch color,Full bootstrap,User Acccounts,Taler installation
-@anchor{onboarding compile-and-switch-color}@anchor{4}
-@section Compile and switch color.
-
-
-If the setup is already bootstrapped, then it should only be needed to
-login as ’demo-X’ (with X being the inactive color); and then:
-
-@example
-$ source activate
-$ taler-deployment-build
-@end example
-
-and then switch the color by logging in as the @emph{demo} user, and switch
-the color with the following command:
-
-@example
-$ taler-deployment-switch-demo-X
-@end example
-
-@node Full bootstrap,How to upgrade the code,Compile and switch color,Taler installation
-@anchor{onboarding full-bootstrap}@anchor{5}
-@section Full bootstrap.
-
-
-In order to bootstrap a Taler installation under a empty home directory,
-do:
-
-@example
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-@end example
-
-Then run the prepare script that will (1) download all the repositories
-(2) build the codebases, (3) configure the system, and (4) generate the
-needed data.
-
-
-@table @asis
-
-@item ::
-
-$ ./deployment/bin/taler-deployment-prepare [test | int | demo]
-@end table
-
-
-@quotation
-
-@strong{Note}
-
-If the DB schema of merchant/exchange/auditor changed, at this point
-it MIGHT be necessary to reset all the tables. To this regard,
-consider running one of the following commands:
-
-@example
-# To reset the merchant DB.
-$ taler-merchant-dbinit -r
-
-# To reset the exchange DB.
-$ taler-exchange-dbinit -r
-
-# To reset the exchange DB.
-$ taler-auditor-dbinit -r
-@end example
-@end quotation
-
-If all the steps succeeded, then it should be possible to launch all the
-services. Give:
-
-@example
-$ taler-deployment-start
-
-# or restart, if you want to kill old processes and
-# start new ones.
-$ taler-deployment-restart
-@end example
-
-Verify that all services are up and running:
-
-@example
-$ taler-deployment-arm -I
-$ tail logs/<component>-<date>.log
-@end example
-
-@node How to upgrade the code,,Full bootstrap,Taler installation
-@anchor{onboarding how-to-upgrade-the-code}@anchor{6}
-@section How to upgrade the code.
-
-
-Some repositories, especially the ones from the released components,
-have a @emph{stable} branch, that keeps older and more stable code.
-Therefore, upon each release we must rebase those stable branches on the
-master.
-
-The following commands do that:
-
-@example
-$ cd $REPO
-
-$ git pull origin master stable
-$ git checkout stable
-
-# option a: resolve conflicts resulting from hotfixes
-$ git rebase master
-$ ...
-
-# option b: force stable to master
-$ git update-ref refs/heads/stable master
-
-$ git push # possibly with --force
-
-# continue development
-$ git checkout master
-@end example
-
-@node Building the documentation,Building the Websites,Taler installation,Top
-@anchor{onboarding building-the-documentation}@anchor{7}@anchor{onboarding testing-components}@anchor{8}
-@chapter Building the documentation
-
-
-All the Taler documentation is built by the user @cite{docbuilder} that
-runs a Buildbot worker.  The following commands set the @cite{docbuilder} up,
-starting with a empty home directory.
-
-
-@table @asis
-
-@item ::
-
-# Log-in as the 'docbuilder' user.
-
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-$ ./deployment/bootstrap-docbuilder
-
-# If the previous step worked, the setup is
-# complete and the Buildbot worker can be started.
-
-$ buildbot-worker start worker/
-@end table
-
-@node Building the Websites,Code coverage,Building the documentation,Top
-@anchor{onboarding building-the-websites}@anchor{9}
-@chapter Building the Websites.
-
-
-Taler Websites, @cite{www.taler.net} and @cite{stage.taler.net}, are built by the
-user @cite{taler-websites} by the means of a Buildbot worker.  The following
-commands set the @cite{taler-websites} up, starting with a empty home directory.
-
-
-@table @asis
-
-@item ::
-
-# Log-in as the 'taler-websites' user.
-
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-$ ./deployment/bootstrap-sitesbuilder
-
-# If the previous step worked, the setup is
-# complete and the Buildbot worker can be started.
-
-$ buildbot-worker start worker/
-@end table
-
-@node Code coverage,Online services checker,Building the Websites,Top
-@anchor{onboarding code-coverage}@anchor{a}
-@chapter Code coverage.
-
-
-Code coverage tests are run by the @cite{lcovworker} user, and are also driven
-by Buildbot.
-
-@example
-# Log-in as the 'lcovworker' user.
-
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-$ ./deployment/bootstrap-taler lcov
-
-# If the previous step worked, the setup is
-# complete and the Buildbot worker can be started.
-
-$ buildbot-worker start worker/
-@end example
-
-The results are then published at @cite{https://lcov.taler.net/}.
-
-@node Online services checker,Topping the tip reserve up,Code coverage,Top
-@anchor{onboarding online-services-checker}@anchor{b}
-@chapter Online services checker.
-
-
-The user @cite{demo-checker} runs periodic checks to see if all the
-@cite{*.demo.taler.net} services are up and running.  It is driven by
-Buildbot, and can be bootstrapped as follows.
-
-@example
-# Log-in as the 'demo-checker' user
-
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-$ ./deployment/bootstrap-demochecker
-
-# If the previous step worked, the setup is
-# complete and the Buildbot worker can be started.
-
-$ buildbot-worker start worker/
-@end example
-
-@node Topping the tip reserve up,Producing auditor reports,Online services checker,Top
-@anchor{onboarding topping-the-tip-reserve-up}@anchor{c}
-@chapter Topping the tip reserve up
-
-
-Both 'test' and 'demo' setups get their tip reserve topped up
-by a Buildbot worker.  The following steps get the reserve topper
-prepared.
-
-
-@table @asis
-
-@item ::
-
-# Log-in as <env>-topper, with <env> being either 'test' or 'demo'
-
-$ git clone git://git.taler.net/deployment
-$ ./deployment/prepare-reservetopper <env>
-
-# If the previous steps worked, then it should suffice to start
-# the worker, with:
-
-$ buildbot-worker start worker/
-@end table
-
-@node Producing auditor reports,Releases,Topping the tip reserve up,Top
-@anchor{onboarding producing-auditor-reports}@anchor{d}
-@chapter Producing auditor reports
-
-
-Both 'test' and 'demo' setups get their auditor reports compiled
-by a Buildbot worker.  The following steps get the reports compiler
-prepared.
-
-
-@table @asis
-
-@item ::
-
-# Log-in as <env>-auditor, with <env> being either 'test' or 'demo'
-
-$ git clone git://git.taler.net/deployment
-$ ./deployment/prepare-auditorreporter <env>
-
-# If the previous steps worked, then it should suffice to start
-# the worker, with:
-
-$ buildbot-worker start worker/
-@end table
-
-@node Releases,Code,Producing auditor reports,Top
-@anchor{onboarding id1}@anchor{e}@anchor{onboarding releases}@anchor{f}
-@chapter Releases
-
-
-@menu
-* Release Process and Checklists:: 
-* Tagging:: 
-* Database for tests:: 
-* Exchange@comma{} merchant: Exchange merchant. 
-* Wallet WebExtension:: 
-* Upload to GNU mirrors:: 
-
-@end menu
-
-@node Release Process and Checklists,Tagging,,Releases
-@anchor{onboarding release-process-and-checklists}@anchor{10}
-@section Release Process and Checklists
-
-
-This document describes the process for releasing a new version of the
-various Taler components to the official GNU mirrors.
-
-The following components are published on the GNU mirrors
-
-
-@itemize -
-
-@item 
-taler-exchange (exchange.git)
-
-@item 
-taler-merchant (merchant.git)
-
-@item 
-talerdonations (donations.git)
-
-@item 
-talerblog (blog.git)
-
-@item 
-taler-bank (bank.git)
-
-@item 
-taler-wallet-webex (wallet-webex.git)
-@end itemize
-
-@node Tagging,Database for tests,Release Process and Checklists,Releases
-@anchor{onboarding tagging}@anchor{11}
-@section Tagging
-
-
-Tag releases with an @strong{annotated} commit, like
-
-@example
-git tag -a v0.1.0 -m "Official release v0.1.0"
-git push origin v0.1.0
-@end example
-
-@node Database for tests,Exchange merchant,Tagging,Releases
-@anchor{onboarding database-for-tests}@anchor{12}
-@section Database for tests
-
-
-For tests in the exchange and merchant to run, make sure that a database
-@emph{talercheck} is accessible by @emph{$USER}. Otherwise tests involving the
-database logic are skipped.
-
-@node Exchange merchant,Wallet WebExtension,Database for tests,Releases
-@anchor{onboarding exchange-merchant}@anchor{13}
-@section Exchange, merchant
-
-
-Set the version in @code{configure.ac}. The commit being tagged should be
-the change of the version.
-
-For the exchange test cases to pass, @code{make install} must be run first.
-Without it, test cases will fail because plugins can’t be located.
-
-@example
-./bootstrap
-./configure # add required options for your system
-make dist
-tar -xf taler-$COMPONENT-$VERSION.tar.gz
-cd taler-$COMPONENT-$VERSION
-make install check
-@end example
-
-@node Wallet WebExtension,Upload to GNU mirrors,Exchange merchant,Releases
-@anchor{onboarding wallet-webextension}@anchor{14}
-@section Wallet WebExtension
-
-
-The version of the wallet is in @emph{manifest.json}. The @code{version_name}
-should be adjusted, and @emph{version} should be increased independently on
-every upload to the WebStore.
-
-@example
-./configure
-make dist
-@end example
-
-@node Upload to GNU mirrors,,Wallet WebExtension,Releases
-@anchor{onboarding upload-to-gnu-mirrors}@anchor{15}
-@section Upload to GNU mirrors
-
-
-See
-@emph{https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads}
-
-Directive file:
-
-@example
-version: 1.2
-directory: taler
-filename: taler-exchange-0.1.0.tar.gz
-@end example
-
-Upload the files in @strong{binary mode} to the ftp servers.
-
-@node Code,Bugtracking,Releases,Top
-@anchor{onboarding code}@anchor{16}@anchor{onboarding id2}@anchor{17}
-@chapter Code
-
-
-Taler code is versioned via Git. For those users without write access,
-all the codebases are found at the following URL:
-
-@example
-git://git.taler.net/<repository>
-@end example
-
-A complete list of all the existing repositories is currently found at
-@code{https://git.taler.net/}. Note: @code{<repository>} must NOT have the
-@code{.git} extension.
-
-@node Bugtracking,Continuous integration,Code,Top
-@anchor{onboarding bugtracking}@anchor{18}@anchor{onboarding id3}@anchor{19}
-@chapter Bugtracking
-
-
-Bug tracking is done with Mantis (@indicateurl{https://www.mantisbt.org/}). All the
-bugs are then showed and managed at @code{https://bugs.gnunet.org/}, under
-the "Taler" project. A registration on the Web site is needed in order
-to use the bug tracker.
-
-@node Continuous integration,Code coverage<2>,Bugtracking,Top
-@anchor{onboarding continuous-integration}@anchor{1a}@anchor{onboarding id4}@anchor{1b}
-@chapter Continuous integration
-
-
-CI is done with Buildbot (@indicateurl{https://buildbot.net/}), and builds are
-triggered by the means of Git hooks. The results are published at
-@code{https://buildbot.wild.gv.taler.net/}.
-
-In order to avoid downtimes, CI uses a "blue/green" deployment
-technique. In detail, there are two users building code on the system,
-the "green" and the "blue" user; and at any given time, one is running
-Taler services and the other one is either building the code or waiting
-for that.
-
-There is also the possibility to trigger builds manually, but this is
-only reserved to "admin" users.
-
-@node Code coverage<2>,Appendix,Continuous integration,Top
-@anchor{onboarding id5}@anchor{1c}@anchor{onboarding id6}@anchor{1d}
-@chapter Code coverage
-
-
-Code coverage is done with the Gcov / Lcov
-(@indicateurl{http://ltp.sourceforge.net/coverage/lcov.php}) combo, and it is run
-*nightly* (once a day) by a Buildbot worker. The coverage results are
-then published at @code{https://lcov.taler.net/}.
-
-@node Appendix,,Code coverage<2>,Top
-@anchor{onboarding appendix}@anchor{1e}
-@chapter Appendix
-
-
-@menu
-* Testing library:: 
-
-@end menu
-
-@node Testing library,,,Appendix
-@anchor{onboarding testing-library}@anchor{1f}
-@section Testing library
-
-
-This chapter is a VERY ABSTRACT description of how testing is
-implemented in Taler, and in NO WAY wants to substitute the reading of
-the actual source code by the user.
-
-In Taler, a test case is a array of @code{struct TALER_TESTING_Command},
-informally referred to as @code{CMD}, that is iteratively executed by the
-testing interpreter. This latter is transparently initiated by the
-testing library.
-
-However, the developer does not have to defined CMDs manually, but
-rather call the proper constructor provided by the library. For example,
-if a CMD is supposed to test feature @code{x}, then the library would
-provide the @code{TALER_TESTING_cmd_x ()} constructor for it. Obviously,
-each constructor has its own particular arguments that make sense to
-test @code{x}, and all constructor are thoroughly commented within the
-source code.
-
-Internally, each CMD has two methods: @code{run ()} and @code{cleanup ()}. The
-former contains the main logic to test feature @code{x}, whereas the latter
-cleans the memory up after execution.
-
-In a test life, each CMD needs some internal state, made by values it
-keeps in memory. Often, the test has to @emph{share} those values with other
-CMDs: for example, CMD1 may create some key material and CMD2 needs this
-key material to encrypt data.
-
-The offering of internal values from CMD1 to CMD2 is made by @emph{traits}. A
-trait is a @code{struct TALER_TESTING_Trait}, and each CMD contains a array
-of traits, that it offers via the public trait interface to other
-commands. The definition and filling of such array happens transparently
-to the test developer.
-
-For example, the following example shows how CMD2 takes an amount object
-offered by CMD1 via the trait interface.
-
-Note: the main interpreter and the most part of CMDs and traits are
-hosted inside the exchange codebase, but nothing prevents the developer
-from implementing new CMDs and traits within other codebases.
-
-@example
-/* Withouth loss of generality, let's consider the
- * following logic to exist inside the run() method of CMD1 */
-..
-
-struct TALER_Amount *a;
-/**
- * the second argument (0) points to the first amount object offered,
- * in case multiple are available.
- */
-if (GNUNET_OK != TALER_TESTING_get_trait_amount_obj (cmd2, 0, &a))
-  return GNUNET_SYSERR;
-...
-
-use(a); /* 'a' points straight into the internal state of CMD2 */
-@end example
-
-In the Taler realm, there is also the possibility to alter the behaviour
-of supposedly well-behaved components. This is needed when, for example,
-we want the exchange to return some corrupted signature in order to
-check if the merchant backend detects it.
-
-This alteration is accomplished by another service called @emph{twister}. The
-twister acts as a proxy between service A and B, and can be programmed
-to tamper with the data exchanged by A and B.
-
-Please refer to the Twister codebase (under the @code{test} directory) in
-order to see how to configure it.
-
-@c %**end of body
-@bye
diff --git a/texinfo/taler-auditor-figures/auditor-db.png b/texinfo/taler-auditor-figures/auditor-db.png
new file mode 100644
index 00000000..3f10f3ab
--- /dev/null
+++ b/texinfo/taler-auditor-figures/auditor-db.png
diff --git a/texinfo/taler-auditor-figures/replication.png b/texinfo/taler-auditor-figures/replication.png
new file mode 100644
index 00000000..855237fc
--- /dev/null
+++ b/texinfo/taler-auditor-figures/replication.png
diff --git a/texinfo/taler-auditor.texi b/texinfo/taler-auditor.texi
new file mode 100644
index 00000000..0647fc3f
--- /dev/null
+++ b/texinfo/taler-auditor.texi
@@ -0,0 +1,1658 @@
+\input texinfo   @c -*-texinfo-*-
+@c %**start of header
+@setfilename taler-auditor.info
+@documentencoding UTF-8
+@ifinfo
+@*Generated by Sphinx 3.4.3.@*
+@end ifinfo
+@settitle Taler Auditor Manual
+@defindex ge
+@paragraphindent 0
+@exampleindent 4
+@finalout
+@dircategory CATEGORY
+@direntry
+* MENU ENTRY: (taler-auditor.info). DESCRIPTION
+@end direntry
+
+@definfoenclose strong,`,'
+@definfoenclose emph,`,'
+@c %**end of header
+
+@copying
+@quotation
+GNU Taler 0.8.0pre0, Jan 21, 2021
+
+GNU Taler team
+
+Copyright @copyright{} 2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
+@end quotation
+
+@end copying
+
+@titlepage
+@title Taler Auditor Manual
+@insertcopying
+@end titlepage
+@contents
+
+@c %** start of user preamble
+
+@c %** end of user preamble
+
+@ifnottex
+@node Top
+@top Taler Auditor Manual
+@insertcopying
+@end ifnottex
+
+@c %**start of body
+@anchor{taler-auditor-manual doc}@anchor{0}
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2019-2020 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU 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 General Public License for more details.
+@c 
+@c You should have received a copy of the GNU General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+
+@menu
+* Introduction:: 
+* Installation:: 
+* Configuration:: 
+* Deployment:: 
+* Operation:: 
+* Auditor implementation guide:: 
+* Index:: 
+
+@detailmenu
+ --- The Detailed Node Listing ---
+
+Introduction
+
+* About GNU Taler:: 
+* About this manual:: 
+* Organizational prerequisites:: 
+* Architecture overview:: 
+
+Installation
+
+* Installing from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
+
+Configuration
+
+* Configuration format:: 
+* Using taler-config:: 
+* Keys:: 
+* Serving:: 
+* Bank account:: 
+* Database:: 
+
+Deployment
+
+* Exchange:: 
+* Signing Denominations:: 
+* Database: Database<2>. 
+
+Database
+
+* Ingres replication of the exchange production database:: 
+* Safe replication of the ingres database into the auditor production database:: 
+
+Operation
+
+* Web service:: 
+* Audit:: 
+* Reading the report:: 
+* Database upgrades:: 
+* Database reset:: 
+* Revocations:: 
+* Failures:: 
+
+Auditor implementation guide
+
+* The auditor’s database:: 
+* Invariants checked by the auditor:: 
+* Testing the auditor:: 
+
+Invariants checked by the auditor
+
+* Invariants checked by the taler-helper-auditor-aggregation:: 
+* Invariants checked by the taler-helper-auditor-coins:: 
+* Invariants checked by the taler-helper-auditor-deposits:: 
+* Invariants checked by the taler-helper-auditor-reserves:: 
+* Invariants checked by the taler-helper-auditor-wire:: 
+
+@end detailmenu
+@end menu
+
+@node Introduction,Installation,Top,Top
+@anchor{taler-auditor-manual gnu-taler-auditor-operator-manual}@anchor{1}@anchor{taler-auditor-manual introduction}@anchor{2}
+@chapter Introduction
+
+
+This manual is an early draft that still needs significant editing work
+to become readable.
+
+@menu
+* About GNU Taler:: 
+* About this manual:: 
+* Organizational prerequisites:: 
+* Architecture overview:: 
+
+@end menu
+
+@node About GNU Taler,About this manual,,Introduction
+@anchor{taler-auditor-manual about-gnu-taler}@anchor{3}
+@section About GNU Taler
+
+
+GNU Taler is an open protocol for an electronic payment system with a
+free software reference implementation. GNU Taler offers secure, fast
+and easy payment processing using well understood cryptographic
+techniques. GNU Taler allows customers to remain anonymous, while
+ensuring that merchants can be held accountable by governments. Hence,
+GNU Taler is compatible with anti-money-laundering (AML) and
+know-your-customer (KYC) regulation, as well as data protection
+regulation (such as GDPR).
+
+@node About this manual,Organizational prerequisites,About GNU Taler,Introduction
+@anchor{taler-auditor-manual about-this-manual}@anchor{4}
+@section About this manual
+
+
+This tutorial targets exchange operators, auditors and governments
+who want to run the auditor to verify that a GNU Taler exchange is
+operating correctly.
+
+@node Organizational prerequisites,Architecture overview,About this manual,Introduction
+@anchor{taler-auditor-manual organizational-prerequisites}@anchor{5}
+@section Organizational prerequisites
+
+
+Operating a GNU Taler auditor means that you (henceforth: auditor) have a
+business relationship with (or regulatory authority over) a GNU Taler exchange
+operator (henceforth: exchange).  Your objective is to verify that the
+exchange is operating correctly, and if not to alert the exchange, the
+state or even the public about any misbehavior to limit financial losses
+to other parties.
+
+To perform this duty, you will need at least (read-only) access to the bank
+transactions of the exchange, as well as a continuously synchronized replica
+of the exchange’s database.  The general assumption for running the auditor
+is that this is done on a separate system controlled by the auditor. After
+all, the goal is to detect nerfarious activity of the exchange operator,
+which cannot be effectively done on a machine controlled by the exchange
+operator.
+
+For this, every auditor needs to operate a Postgres database.  The data
+collected will include sensitive information about Taler users, including
+withdrawals made by consumers and income received by merchants.  As a result,
+the auditor is expected to provide high confidentiality for the database.  In
+general, the auditor does not have to offer high-availability: the exchange
+operator can continue operations without the auditor, and the auditor can
+catch up with it later when the auditor’s systems are restored. However, of
+course any downtime would provide a window of opportunity for fraud and should
+thus be minimized.  Finally, the auditor’s copy of the exchange’s database can
+be useful as a backup to the exchange in case the exchange experiences a loss
+of its own copies. Thus, business agreements between auditor and exchanges may
+include availability requirements as well.
+
+Then, with the software provided, auditors can verify the cryptographic proofs
+collected by the exchange and detect if any improper bank transactions have been
+made.  There are additional tasks which an auditor should perform.  While this
+manual only focuses on the audit of the exchange’s database and wire transfers
+with the existing tools, a proper auditor should also perform the following
+tasks:
+
+
+@itemize -
+
+@item 
+security audit of the source code
+
+@item 
+audit of the operational procedures of the exchange
+
+@item 
+audit of the physical security of the deployment
+
+@item 
+background check of the individuals operating the exchange
+
+@item 
+verification that the exchange properly implements the @code{/link} protocol
+(feature yet to be implemented in common Taler wallets)
+
+@item 
+verification that the exchange properly reports coins issued during
+the refresh protocol (by irregularly refreshing coins withdrawn by
+the auditor and comparing against the exchange’s database — the
+code required to support this is not yet implemented)
+@end itemize
+
+@node Architecture overview,,Organizational prerequisites,Introduction
+@anchor{taler-auditor-manual architecture-overview}@anchor{6}
+@section Architecture overview
+
+
+Taler is a pure payment system, not a new crypto-currency. As such, it
+operates in a traditional banking context. In particular, this means that in
+order to receive funds via Taler, the merchant must have a regular bank
+account, and payments can be executed in ordinary currencies such as USD or
+EUR. Similarly, the exchange must interact with a bank. The bank of the
+exchange holds the exchange’s funds in an escrow account.  As a result,
+exchanges operate in a regulated environment, and auditors provide a crucial
+oversight function.
+
+Auditors should generally be independent third parties that verify that the
+exchange operates correctly.  However, an exchange is likely to also run the
+auditing logic, as it is also used to calculate the exchange’s profits, risk
+and liabilities.  Furthermore, it’s usually a good idea to not only rely on
+third parties to verify one’s own work.
+
+The Taler software stack for an auditor consists of the following
+components:
+
+
+@itemize -
+
+@item 
+DBMS: Postgres
+
+The auditor requires a DBMS to store a local copy of the transaction history for
+the Taler exchange, as well as for its own internal bookkeeping and checkpointing.
+The DBMS is assumed to be able to assure the auditor of the database invariants (foreign
+key, uniqueness, length restrictions).  Should the exported data from the exchange
+fail to be imported due to constraint violations, this is an immediate serious
+concern that must be addressed manually.  The software only verifies the content
+of a well-formed exchange database (well-formed with respect to SQL).
+For now, the GNU Taler reference implementation
+only supports Postgres, but the code could be easily extended to
+support another DBMS.
+
+@item 
+The auditor Web service
+
+The auditor is expected to provide a public Web service. At this REST API,
+merchants can (probabilistically) provide deposit confirmations, allowing
+the auditor to detect if an exchange is underreporting deposits.
+
+In the future, the Web service should be extended to allow customers and
+merchants to automatically upload cryptographic proof of other violations
+of the specification by the exchange.  However, for now it is assumed that
+the respective cryptographic proofs are reported and verified manually —
+as with a well-behaved exchange this should obviously be a rare event.
+
+The main binary of this component is the @code{taler-auditor-httpd}.
+
+@item 
+The (main) auditor
+
+The main auditor logic checks the various signatures, totals up the
+amounts and checks for arithmetic inconsistencies. It also
+computes the expected bank balance, revenue and risk exposure of the
+exchange operator. The main script of this component is the @code{taler-auditor}.
+This script invokes several helper binaries sequentially. Production
+users may want to modify the script to run those binaries in parallel,
+possibly using different privileges (as only the @code{taler-helper-auditor-wire}
+needs access to the wire gateway).
+
+The @code{taler-helper-auditor-wire} auditor verifies that the bank
+transactions performed by the exchange
+were done properly.  This component must have access to the bank account
+of the exchange, as well as to a copy of the exchange’s database.
+
+The @code{taler-auditor} script invokes the various helpers, each generating
+a JSON report. It then invokes the @code{taler-helper-auditor-render.py}
+script to combine those JSON files with a Jinja2 template into a
+LaTeX report.  Finally, @code{pdflatex} is used to generate a PDF report.
+
+The resulting report includes performance data, reports on hard violations
+(resulting in financial losses) and reports on soft violations (such as the
+exchange not performing certain operations in a timely fashion).  The
+report also includes figures on the losses of violations. Careful reading
+of the report is required, as not every detail in the report is necessarily
+indicative of a problem.
+@end itemize
+
+@node Installation,Configuration,Introduction,Top
+@anchor{taler-auditor-manual installation}@anchor{7}
+@chapter Installation
+
+
+@menu
+* Installing from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
+
+@end menu
+
+@node Installing from source,Installing the GNU Taler binary packages on Debian,,Installation
+@anchor{taler-auditor-manual installing-from-source}@anchor{8}
+@section Installing from source
+
+
+Please install the following packages before proceeding with the
+exchange compilation.
+
+
+@itemize -
+
+@item 
+libsqlite3 >= 3.16.2
+
+@item 
+GNU libunistring >= 0.9.3
+
+@item 
+libcurl >= 7.26 (or libgnurl >= 7.26)
+
+@item 
+libqrencode >= 4.0.0
+
+@item 
+GNU libgcrypt >= 1.6
+
+@item 
+libsodium >= 1.0
+
+@item 
+libargon2 >= 20171227
+
+@item 
+libjansson >= 2.7
+
+@item 
+Postgres >= 9.6, including libpq
+
+@item 
+GNU libmicrohttpd >= 0.9.71
+
+@item 
+GNUnet >= 0.14.0 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
+
+@item 
+GNU Taler exchange (from download directory@footnote{http://ftpmirror.gnu.org/taler/},
+see release announcement@footnote{https://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=taler&idxname=info-gnu&max=20&result=normal&sort=date:late})
+@end itemize
+
+Except for the last two, these are available in most GNU/Linux
+distributions and should just be installed using the respective package
+manager.
+
+The following instructions will show how to install libgnunetutil and
+the exchange (which includes the code for the auditor).
+
+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.
+
+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.
+
+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.
+
+@node Installing the GNU Taler binary packages on Debian,,Installing from source,Installation
+@anchor{taler-auditor-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{9}
+@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
+Sid, which means you should use a system which at least includes
+unstable packages in its source list.  We recommend using APT pinning
+to limit unstable packages to those explicitly requested. To do this,
+set your @code{/etc/apt/preferences} as follows:
+
+@example
+Package: *
+Pin: release a=stable
+Pin-Priority: 700
+
+Package: *
+Pin: release a=testing
+Pin-Priority: 650
+
+Package: *
+Pin: release a=unstable
+Pin-Priority: 600
+
+Package: *
+Pin: release l=Debian-Security
+Pin-Priority: 1000
+@end example
+
+A typical @code{/etc/apt/sources.list} file for this setup
+would look like this:
+
+@example
+deb http://ftp.ch.debian.org/debian/ buster main
+deb http://security.debian.org/debian-security buster/updates main
+deb http://ftp.ch.debian.org/debian/ testing main
+deb http://ftp.ch.debian.org/debian/ unstable main
+deb https://deb.taler.net/apt/debian sid main
+@end example
+
+The last line is crucial, as it adds the GNU Taler packages.
+
+Next, you must import the Taler Systems SA public package signing key
+into your keyring and update the package lists:
+
+@example
+# wget -O - https://taler.net/taler-systems.gpg.key | apt-sign add -
+# 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 auditor, you can now simply run:
+
+@example
+# apt install taler-auditor
+@end example
+
+For the auditor, you must manually configure access to the exchange database,
+the HTTP reverse proxy (typically with TLS certificates) and offline signing.
+
+Sample configuration files for the HTTP reverse proxy can be found in
+@code{/etc/taler-exchange/}.
+
+@node Configuration,Deployment,Installation,Top
+@anchor{taler-auditor-manual configuration}@anchor{a}
+@chapter Configuration
+
+
+The auditor’s configuration works the same way as the configuration of other
+Taler components.
+This section discusses configuration options related to the auditor.
+
+@menu
+* Configuration format:: 
+* Using taler-config:: 
+* Keys:: 
+* Serving:: 
+* Bank account:: 
+* Database:: 
+
+@end menu
+
+@node Configuration format,Using taler-config,,Configuration
+@anchor{taler-auditor-manual configuration-format}@anchor{b}
+@section Configuration format
+
+
+In Taler realm, any component obeys to the same pattern to get
+configuration values. According to this pattern, once the component has
+been installed, the installation deploys default values in
+$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
+these defaults, the user can write a custom .conf file and either pass
+it to the component at execution time, or name it taler.conf and place
+it under $HOME/.config/.
+
+A config file is a text file containing sections, and each section
+contains its values. The right format follows:
+
+@example
+[section1]
+value1 = string
+value2 = 23
+
+[section2]
+value21 = string
+value22 = /path22
+@end example
+
+Throughout any configuration file, it is possible to use @code{$}-prefixed
+variables, like @code{$VAR}, especially when they represent filesystem
+paths. It is also possible to provide defaults values for those
+variables that are unset, by using the following syntax:
+@code{$@{VAR:-default@}}. However, there are two ways a user can set
+@code{$}-prefixable variables:
+
+by defining them under a @code{[paths]} section, see example below,
+
+@example
+[paths]
+TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
+..
+[section-x]
+path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
+@end example
+
+or by setting them in the environment:
+
+@example
+$ export VAR=/x
+@end example
+
+The configuration loader will give precedence to variables set under
+@code{[path]}, though.
+
+The utility @code{taler-config}, which gets installed along with the
+exchange, serves to get and set configuration values without directly
+editing the .conf. The option @code{-f} is particularly useful to resolve
+pathnames, when they use several levels of @code{$}-expanded variables. See
+@code{taler-config --help}.
+
+Note that, in this stage of development, the file
+@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
+component. For example, both an exchange and a bank can read values from
+it.
+
+The repository @code{git://taler.net/deployment} contains examples of
+configuration file used in our demos. See under @code{deployment/config}.
+
+@quotation
+
+@strong{Note}
+
+Expectably, some components will not work just by using default
+values, as their work is often interdependent. For example, a
+merchant needs to know an exchange URL, or a database name.
+@end quotation
+
+@node Using taler-config,Keys,Configuration format,Configuration
+@anchor{taler-auditor-manual using-taler-config}@anchor{c}
+@section Using taler-config
+
+
+The tool @code{taler-config} can be used to extract or manipulate
+configuration values; however, the configuration use the well-known INI
+file format and can also be edited by hand.
+
+Run
+
+@example
+$ taler-config -s $SECTION
+@end example
+
+to list all of the configuration values in section @code{$SECTION}.
+
+Run
+
+@example
+$ taler-config -s $section -o $option
+@end example
+
+to extract the respective configuration value for option @code{$option} in
+section @code{$section}.
+
+Finally, to change a setting, run
+
+@example
+$ taler-config -s $section -o $option -V $value
+@end example
+
+to set the respective configuration value to @code{$value}. Note that you
+have to manually restart the Taler backend after you change the
+configuration to make the new configuration go into effect.
+
+Some default options will use $-variables, such as @code{$DATADIR} within
+their value. To expand the @code{$DATADIR} or other $-variables in the
+configuration, pass the @code{-f} option to @code{taler-config}. For example,
+compare:
+
+@example
+$ taler-config -s ACCOUNT-bank \
+               -o WIRE_RESPONSE
+$ taler-config -f -s ACCOUNT-bank \
+               -o WIRE_RESPONSE
+@end example
+
+While the configuration file is typically located at
+@code{$HOME/.config/taler.conf}, an alternative location can be specified
+to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
+option.
+
+@node Keys,Serving,Using taler-config,Configuration
+@anchor{taler-auditor-manual auditorkeys}@anchor{d}@anchor{taler-auditor-manual keys}@anchor{e}
+@section Keys
+
+
+The auditor works with one signing key to certify that it is auditing
+a particular exchange’s denomination keys.  This key can and should
+be kept @emph{offline} (and backed up adequately). As with the exchange’s
+offline key, it is only used for a few cryptographic signatures and
+thus the respective code can be run on modest hardware, like a
+Raspberry Pi.
+
+The following values are to be configured in the section @code{[auditor]}:
+
+
+@itemize -
+
+@item 
+@code{AUDITOR_PRIV_FILE}: Path to the auditor’s private key file.
+
+@item 
+@code{PUBLIC_KEY}: Public key of the auditor, in Base32 encoding.
+Set from value printed by @code{gnunet-ecc -p $AUDITOR_PRIV_FILE}.
+@end itemize
+
+@node Serving,Bank account,Keys,Configuration
+@anchor{taler-auditor-manual auditorserving}@anchor{f}@anchor{taler-auditor-manual serving}@anchor{10}
+@section Serving
+
+
+The auditor can serve HTTP over both TCP and UNIX domain socket.
+
+The following values are to be configured in the section @code{[auditor]}:
+
+
+@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 
+@code{unixpath_mode}: number giving the mode with the access permission MASK
+for @code{unixpath} (i.e. 660 = @code{rw-rw----}).
+@end itemize
+
+@node Bank account,Database,Serving,Configuration
+@anchor{taler-auditor-manual auditorbank-account}@anchor{11}@anchor{taler-auditor-manual bank-account}@anchor{12}
+@section Bank account
+
+
+Bank accounts for the auditor are configured in exactly the
+same way as bank accounts for the exchange. See the exchange
+documentation for details.
+
+@node Database,,Bank account,Configuration
+@anchor{taler-auditor-manual auditordatabaseconfiguration}@anchor{13}@anchor{taler-auditor-manual database}@anchor{14}
+@section Database
+
+
+The option @code{DB} under section @code{[auditor]} gets the DB backend’s name the
+exchange is going to use. So far, only @code{DB = postgres} is supported. After
+choosing the backend, it is mandatory to supply the connection string
+(namely, the database name). This is possible in two ways:
+
+
+@itemize -
+
+@item 
+via an environment variable: @code{TALER_AUDITORDB_POSTGRES_CONFIG}.
+
+@item 
+via configuration option @code{CONFIG}, under section @code{[auditordb-BACKEND]}.
+For example, the demo exchange is configured as follows:
+
+@example
+[auditor]
+...
+DB = postgres
+...
+
+[auditordb-postgres]
+CONFIG = postgres:///auditordemo
+@end example
+@end itemize
+
+If an exchange runs its own auditor, it may use the same database for
+the auditor and the exchange itself.
+
+The @code{taler-auditor-dbinit} tool is used to initialize the auditor’s
+tables. After running this tool, the rights to CREATE or DROP tables
+are no longer required and should be removed.
+
+Both the @code{taler-auditor-httpd} and the @code{taler-auditor} (and its helpers)
+also need (read-only) access to a (recent, current, synchronized) copy of the
+exchange’s database.  The configuration options are the same that are also
+used when configuring the exchange’ database:
+
+@quotation
+
+@example
+[exchange]
+...
+DB = postgres
+...
+
+[exchangedb-postgres]
+CONFIG = postgres:///exchangedemo
+@end example
+@end quotation
+
+@node Deployment,Operation,Configuration,Top
+@anchor{taler-auditor-manual auditordeployment}@anchor{15}@anchor{taler-auditor-manual deployment}@anchor{16}
+@chapter Deployment
+
+@anchor{taler-auditor-manual wallets}@anchor{17}
+Before GNU Taler wallets will happily interact with an exchange,
+the respective auditor’s public key (to be obtained via @code{gnunet-ecc -p})
+must be added under the respective currency to the wallet.  This
+is usually expected to be hard-coded into the Taler wallet.
+
+Users can also manually add auditors for a particular currency via a
+Web page offering the respective pairing.
+
+FIXME-DOLD: explain how that Web page works, once it works…
+
+@menu
+* Exchange:: 
+* Signing Denominations:: 
+* Database: Database<2>. 
+
+@end menu
+
+@node Exchange,Signing Denominations,,Deployment
+@anchor{taler-auditor-manual auditorexchange}@anchor{18}@anchor{taler-auditor-manual exchange}@anchor{19}
+@section Exchange
+
+
+The next step is to add the exchange’s master public key and the base
+URL of the exchange to the list of exchanges audited by the auditor.
+This is done using the @code{taler-auditor-exchange} tool.  The tool
+basically creates the respective record in the auditor’s database.
+
+If this step is skipped, the auditor will malfunction at all future
+stages with a foreign key violation, as it doesn’t know the exchange’s
+master public key.
+
+@example
+$ taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL
+@end example
+
+The equivalent step must be performed by the exchange operator.
+Here, the exchange operator must use the @code{taler-exchange-offline}
+tool to add the auditor’s public key, base URL and (business) name
+to the list of approved auditors of the exchange. For details,
+see Auditor-configuration in the exchange operator manual.
+
+@node Signing Denominations,Database<2>,Exchange,Deployment
+@anchor{taler-auditor-manual signing-denominations}@anchor{1a}@anchor{taler-auditor-manual signingdenominations}@anchor{1b}
+@section Signing Denominations
+
+
+@geindex maintenance
+
+This step must be performed regularly whenever the exchange is
+deploying new denomination keys. After the exchange operator
+has signed new keys using the @code{taler-exchange-offline} tool,
+each auditor should run:
+
+@example
+$ taler-auditor-offline download > input.json
+@end example
+
+to import the latest set of denomination keys. The key data
+should then be inspected using:
+
+@example
+$ taler-auditor-offline show < input.json
+@end example
+
+and compared with the data the exchange operator saw when doing the offline
+signature. This process should involve directly the humans operating both
+systems and may require them to establish a trustworthy connection. The
+details how the auditor communicates with the exchange operator are a business
+process that is outside of the scope of this document.
+
+Note that the @code{input.json} does not contain any confidential data.  However,
+signing the wrong keys would be fatal in that it may allow an illegitimate
+exchange to convince users that it is a trustworthy operator and subsequently
+betray the user’s trust that is anchored in the existence of a trustworthy
+auditor.
+
+Given the verified JSON input, the auditor can then sign it (typically
+on its offline system) using:
+
+@example
+$ taler-auditor-offline sign < input.json > output.json
+@end example
+
+The resulting @code{output.json} should then be copied to an online system,
+and from there uploaded to the exchange using:
+
+@example
+$ taler-auditor-offline upload < output.json
+@end example
+
+The contents of @code{output.json} can again be public and require no special
+handling.
+
+If the auditor has been correctly added, the exchange’s @code{/keys}
+response will contain an entry in the @code{auditors} array mentioning the
+auditor’s URL.
+
+Commands, like @code{taler-auditor-offline}, that support the @code{-l LOGFILE}
+command-line option, send logging output to standard error by default.
+
+@node Database<2>,,Signing Denominations,Deployment
+@anchor{taler-auditor-manual auditordatabaseinitialization}@anchor{1c}@anchor{taler-auditor-manual id1}@anchor{1d}
+@section Database
+
+
+The next key step for the auditor is to configure replication of the
+@emph{exchange}’s database in-house. This should be performed in two steps
+as illustrated in the following figure:
+
+@image{taler-auditor-figures/replication,,,,png}
+
+First, the exchange should use standard Postgres replication features to
+enable the auditor to obtain a full copy of the exchange’s database.
+Second, the auditor should make a “trusted” local copy, ensuring that it
+never replicates malicious changes using @code{taler-auditor-sync}. Both
+of these steps are described in more detail below.
+
+We note that as a result of these steps, the auditor will have three
+databases: its own production primary database (as configured in
+@code{auditordb-postgres}), its on production copy of the exchange’s database
+(@code{exchangedb-postgress}), and a third, untrusted “ingres” copy of the
+exchange database.  The untrusted database should run as a separate Postgres
+instance and is only accessed via @code{taler-auditor-sync} and the replication
+mechanism driven by the exchange operator.
+
+@menu
+* Ingres replication of the exchange production database:: 
+* Safe replication of the ingres database into the auditor production database:: 
+
+@end menu
+
+@node Ingres replication of the exchange production database,Safe replication of the ingres database into the auditor production database,,Database<2>
+@anchor{taler-auditor-manual ingres-replication-of-the-exchange-production-database}@anchor{1e}
+@subsection Ingres replication of the exchange production database
+
+
+The full copy can be obtained in various ways with Postgres.  It is
+possible to use log shipping with streaming replication as described
+in @indicateurl{https://www.postgresql.org/docs/13/warm-standby.html}, or to use
+logical replication, as described in
+@indicateurl{https://www.postgresql.org/docs/13/logical-replication.html}. We note
+that asynchronous replication should suffice.
+
+The resulting auditor database should be treated as read-only on the auditor
+side.  The @code{taler-exchange-dbinit} tool can be used to setup the schema, or
+the schema can be replicated using Postgres’s standard mechanisms. The same
+applies for schema upgrades: if logical replication is used (which does not
+replicate schema changes), @code{taler-exchange-dbinit} can be used to migrate
+the schema(s) in both the ingres and production copies of the exchange’s
+database as well.
+
+For details, we refer to the Postgres manual.
+
+@cartouche
+@quotation Note 
+Depending on the replication method used, the exchange may perform
+unexpected changes to the schema or perform @code{UPDATE}, @code{DELETE} or
+@code{DROP} operations on the tables.  Hence, the auditor cannot rely upon the
+exchange’s primary copy to respect schema constraints, especially as we
+have to presume that the exchange could act maliciously.  Furthermore, it
+is unclear to what degree Postgres database replication mechanisms are
+robust against a malicious master database.  Thus, the auditor should
+isolate its primary copy of the exchange database, including the Postgres
+process, from its actual operational data.
+@end quotation
+@end cartouche
+
+@node Safe replication of the ingres database into the auditor production database,,Ingres replication of the exchange production database,Database<2>
+@anchor{taler-auditor-manual safe-replication-of-the-ingres-database-into-the-auditor-production-database}@anchor{1f}
+@subsection Safe replication of the ingres database into the auditor production database
+
+
+Using @code{taler-auditor-sync}, the auditor should make a second “safe” copy of
+the exchange’s ingres database.  @code{taler-auditor-sync} basically reads from one
+exchange database and inserts all records found into a second exchange
+database. If the source database violates invariants, the tool halts with an
+error. This way, records violating invariants are never even copied, and in
+particular schema changes and deletions or updates are not propagated into the
+auditor’s production database.
+
+While @code{taler-auditor-sync} could in theory be run directly against the
+exchange’s production system, this is likely a bad idea due to the high
+latency from the network between auditor and exchange operator. Thus, we
+recommend first making an “untrusted” ingress copy of the exchange’s
+production database using standard Postgres tooling, and then using
+@code{taler-auditor-sync} to create a second “safe” copy.  The “safe” copy used
+by the production system should also run under a different UID.
+
+Before @code{taler-auditor-sync} can be used, the target database must be
+initialized with the exchange schema using @code{taler-exchange-dbinit}.
+Note that running @code{taler-auditor-sync} requires the use of two
+configuration files, one specifying the options for accessing the source
+database, and a second with the options for accessing the destination
+database.  In both cases, likely only the @code{[exchangedb]/CONFIG} option
+needs to be changed.
+
+When the exchange performs garbage collection to @code{DELETE} obsolete records,
+this change should be automatically replicated to the auditors untrusted
+ingress database.  However, as @code{taler-auditor-sync} tries to be “safe”,
+it will not replicate those deletions to the auditor’s production database.
+Thus, it is necessary to (occasonally) run @code{taler-exchange-dbinit -g} on
+the auditor’s production database to garbage collect old data in the
+auditor’s production copy.  We note that this does not have to be done
+at the same time when the exchange runs its garbage collection.
+
+@node Operation,Auditor implementation guide,Deployment,Top
+@anchor{taler-auditor-manual id2}@anchor{20}@anchor{taler-auditor-manual operation}@anchor{21}
+@chapter Operation
+
+
+@menu
+* Web service:: 
+* Audit:: 
+* Reading the report:: 
+* Database upgrades:: 
+* Database reset:: 
+* Revocations:: 
+* Failures:: 
+
+@end menu
+
+@node Web service,Audit,,Operation
+@anchor{taler-auditor-manual id3}@anchor{22}@anchor{taler-auditor-manual web-service}@anchor{23}
+@section Web service
+
+
+The @code{taler-auditor-httpd} runs the required REST API for the auditor.  The
+service must have @code{INSERT} (and @code{SELECT}) rights on the
+@code{deposit_confirmations} table in the auditor’s database.  We expect that in
+future versions additional rights may be required.
+
+As the @code{taler-auditor-httpd} does not include HTTPS-support, it is
+advisable to run it behind a reverse proxy that offers TLS termination.
+
+@node Audit,Reading the report,Web service,Operation
+@anchor{taler-auditor-manual audit}@anchor{24}@anchor{taler-auditor-manual id4}@anchor{25}
+@section Audit
+
+
+Performing an audit is done by invoking the @code{taler-auditor} shell script.
+The shell script invokes the various helper processes. For additional
+performance and security, one may want to run the various helpers individually
+and with the respective minimal set of access rights (only
+@code{taler-helper-auditor-wire} needs the credentials to query the bank for wire
+transfers).  The shell script combines the final JSON outputs of the various
+helpers using the @code{taler-helper-auditor-render.py} script into the TeX
+report.  Regardless, the simplest way to obtain a report is to run:
+
+@example
+$ taler-audit
+@end example
+
+This generates a file @code{auditor-report.pdf} (in a temporary directory created
+for this purpose) with all of the issues found and the financial assessment of
+the exchange.  The exact filename will be output to the console upon
+completion.
+
+We note that @code{taler-audit} by default runs in incremental mode. As a result,
+running the commands again will only check the database entries that have been
+added since the last run.
+
+You can use @code{taler-auditor-dbinit -r} to force a full check since the
+beginning of time. However, as this may require excessive time and
+interactions with the bank (which may not even have the wire transfer records
+anymore), this is not recommended in a production setup.
+
+@node Reading the report,Database upgrades,Audit,Operation
+@anchor{taler-auditor-manual reading-the-report}@anchor{26}
+@section Reading the report
+
+
+The auditor’s report needs to be read carefully, as it includes
+several categories of failures of different severity:
+
+
+@itemize -
+
+@item 
+Delayed operations, where an operation was expected to have
+happened, but did not happen yet, possibly because of a
+disagreement in system time or overloading of the system.
+These failures only require action if the delays are
+significant.
+
+@item 
+Inconsistencies in the data that have no clear financial
+impact.
+
+@item 
+Inconsistencies in the data that show that the exchange
+experienced an unexpected financial loss (such as accepting a coin for
+deposit with an invalid signature).
+
+@item 
+Inconsistencies in the data that show that the exchange
+caused some other party to experience a financial loss (such as not wiring
+the correct amount to a merchant).
+
+@item 
+Configuration issues (such was wire fees unavailable).
+@end itemize
+
+@node Database upgrades,Database reset,Reading the report,Operation
+@anchor{taler-auditor-manual auditordatabaseupgrades}@anchor{27}@anchor{taler-auditor-manual database-upgrades}@anchor{28}
+@section Database upgrades
+
+
+To upgrade the database between Taler versions can be done by running:
+
+@example
+$ taler-auditor-dbinit
+$ taler-exchange-dbinit
+@end example
+
+In any case, it is recommended that exchange and auditor coordinate closely
+during schema-changing database upgrades as without coordination the database
+replication or @code{taler-auditor-sync} will likely experience problematic
+failures.  In general, we recommend:
+
+@quotation
+
+
+@itemize *
+
+@item 
+halting the exchange business logic,
+
+@item 
+allowing the replication and @code{taler-auditor-sync} to complete
+(see also the @strong{-t} option of @code{taler-auditor-sync})
+
+@item 
+completing a @code{taler-audit} run against the old schema
+
+@item 
+migrating the exchange schema (@code{taler-exchange-dbinit}) of
+the master database, possibly the ingres database and the
+auditor’s production copy
+
+@item 
+migrating the auditor database (@code{taler-auditor-dbinit})
+
+@item 
+resuming database replication between the exchange’s master
+database and the auditor’s ingres copy
+
+@item 
+resuming @code{taler-auditor-sync}
+
+@item 
+resuming the regular exchange and auditor business logic
+@end itemize
+@end quotation
+
+Regardless, the above is merely the general rule. Please review the specific
+release notes to ensure this procedure is correct for the specific upgrade.
+
+@node Database reset,Revocations,Database upgrades,Operation
+@anchor{taler-auditor-manual database-reset}@anchor{29}
+@section Database reset
+
+
+The auditor database can be reset using:
+
+@example
+$ taler-auditor-dbinit -R
+@end example
+
+However, running this command will result in all data in the database being
+@emph{lost}, including steps like enabling an exchange using
+@code{taler-auditor-exchange}. Thus, doing so may result in significant
+commputation (and bandwidth consumption with the bank) when the auditor is
+next launched, as it will re-download and re-verify all historic transactions.
+Hence this should not be done in a production system.
+
+@node Revocations,Failures,Database reset,Operation
+@anchor{taler-auditor-manual auditorrevocations}@anchor{2a}@anchor{taler-auditor-manual revocations}@anchor{2b}
+@section Revocations
+
+
+When an auditor detects that the private key of a denomination key pair has
+been compromised, one important step is to revoke the denomination key.  The
+exchange operator includes the details on how to revoke a denomination key, so
+the auditor should only have to report (and possibly enforce) this step.
+For more information, see Revocations in the exchange operator manual.
+
+If all denominations of an exchange are revoked, the exchange includes logic
+to wire back all returned funds to the bank accounts from which they
+originate.  If some denominations remain operational, wallets will generally
+exchange old coins of revoked denominations for new coins – while providing
+additional information to demonstrate that these coins were not forged from
+the compromised private key but obtained via a legitimate withdraw operation.
+
+@node Failures,,Revocations,Operation
+@anchor{taler-auditor-manual failures}@anchor{2c}
+@section Failures
+
+
+Most audit failures are handled by the auditor’s regular reporting functionality,
+creating a (hopefully descriptive) PDF report detailing the problems found.
+
+However, there is one category of errors where this is not possible, which
+concerns arithmetic overflows for amounts. Taler’s specification limits amount
+values to at most 2^52. If, during the auditor’s calculations, amounts are
+encountered that exceed this threshold, the auditor will not generate a regular
+report, but instead write a log statement explaining where the problem happened
+and exit with a status code of @emph{42}.
+
+The most common expected case when this happens is a corrupted database. This
+could be because the exchange is actively malicious, or more likely due to
+some data corruption.  The audit cannot continue until the corruption has been
+addressed. If it is not possible to restore a fully @emph{correct} version of the
+database, the suggestion is to replace the corrupted (and likely very large)
+amounts with zero (Note: this does not apply to the value of denominations or
+fees, here it is crucial that the correct amounts are restored). While an
+amount of zero would be incorrect, the auditing logic should be able to do its
+calculations with zero instead.
+
+After patching the database, the audit can
+be restarted. A full reset is not required, as the audit transaction is aborted
+when the auditor exits with code @emph{42}.  After restarting, the resulting audit
+report is likely to indicates errors relating to the corrupted fields (such as
+invalid signatures, arithmetic errors by the exchange, etc.), but at least the
+loss/gain calculations will be meaningful and actually indicative of the scope
+of the error created by the corrupted data.
+
+@node Auditor implementation guide,Index,Operation,Top
+@anchor{taler-auditor-manual auditor-implementation-guide}@anchor{2d}
+@chapter Auditor implementation guide
+
+
+The auditor implementation is split into five main processes, called
+@code{taler-helper-auditor-XXX}.  The split was done to realize the principle of
+least privilege and to enable independent logic to be possibly run in
+parallel.  Only the taler-wire-auditor must have (read-only) access to the
+exchange’s bank account, the other components only need access to the
+database.
+
+All auditor subsystems basically start their audit from a certain transaction
+index (@code{BIG SERIAL}) in the auditor database which identifies where the last
+audit concluded. They then check that the transactions claimed in the
+exchange’s database match up internally, including the cryptographic
+signatures and also with respect to amounts adding up. The auditor also
+calculates the exchange’s profits and expected bank balances.  Once all
+existing transactions are processed, the auditor processes store the current
+checkpoint in its database and generate a JSON report.
+
+The @code{taler-auditor} shell script calls the five helpers and then
+uses Jinja2 with a TeX template to convert the five individual
+JSON reports into LaTeX and then into PDF.
+
+@menu
+* The auditor’s database:: 
+* Invariants checked by the auditor:: 
+* Testing the auditor:: 
+
+@end menu
+
+@node The auditor’s database,Invariants checked by the auditor,,Auditor implementation guide
+@anchor{taler-auditor-manual the-auditor-s-database}@anchor{2e}
+@section The auditor’s database
+
+
+The database scheme used by the exchange looks as follows:
+
+@image{taler-auditor-figures/auditor-db,,,,png}
+
+@node Invariants checked by the auditor,Testing the auditor,The auditor’s database,Auditor implementation guide
+@anchor{taler-auditor-manual invariants-checked-by-the-auditor}@anchor{2f}
+@section Invariants checked by the auditor
+
+
+The auditor verifies a large number of invariants that must hold for a Taler
+exchange.  One objective in the design of the auditor was to check each
+invariant only once, both to minimize cost and to avoid duplicate reporting of
+problems where possible. As a result, not every invariant is checked in every
+pass where it might seem applicable.
+
+@menu
+* Invariants checked by the taler-helper-auditor-aggregation:: 
+* Invariants checked by the taler-helper-auditor-coins:: 
+* Invariants checked by the taler-helper-auditor-deposits:: 
+* Invariants checked by the taler-helper-auditor-reserves:: 
+* Invariants checked by the taler-helper-auditor-wire:: 
+
+@end menu
+
+@node Invariants checked by the taler-helper-auditor-aggregation,Invariants checked by the taler-helper-auditor-coins,,Invariants checked by the auditor
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-aggregation}@anchor{30}
+@subsection Invariants checked by the taler-helper-auditor-aggregation
+
+
+This is from CodeBlau’s analysis. A proper write-up is pending.
+CodeBlau reports the following checks:
+
+
+@itemize -
+
+@item 
+arithmetic inconsistencies
+
+
+@itemize -
+
+@item 
+disagreement in fee for deposit between auditor and exchange db
+
+@item 
+disagreement in fee for melt between auditor and exchange db
+
+@item 
+disagreement in fee for refund between auditor and exchange db
+
+@item 
+aggregation of fee is negative
+
+@item 
+aggregation (contribution): Expected coin contributions differ:
+coin value without fee, total deposit without refunds
+
+@item 
+wire out fee is negative
+@end itemize
+
+@item 
+coin arithmetic inconsistencies
+
+
+@itemize -
+
+@item 
+refund (merchant) is negative
+
+@item 
+refund (balance) is negative
+
+@item 
+spend > value
+@end itemize
+
+@item 
+coin denomination signature invalid
+
+@item 
+start date before previous end date
+
+@item 
+end date after next start date
+
+@item 
+wire out inconsistencies in amount
+
+@item 
+row inconsistencies
+
+
+@itemize -
+
+@item 
+wire account given is malformed
+
+@item 
+h(wire) does not match wire
+
+@item 
+failed to compute hash of given wire data
+
+@item 
+database contains wrong hash code for wire details
+
+@item 
+no transaction history for coin claimed in aggregation
+
+@item 
+could not get coin details for coin claimed in aggregation
+
+@item 
+could not find denomination key for coin claimed in aggregation
+
+@item 
+coin denomination signature invalid
+
+@item 
+target of outgoing wire transfer do not match hash of wire from deposit
+
+@item 
+date given in aggregate does not match wire transfer date
+
+@item 
+wire fee signature invalid at given time
+
+@item 
+specified wire address lacks method
+
+@item 
+wire fee unavailable for given time
+@end itemize
+@end itemize
+
+@node Invariants checked by the taler-helper-auditor-coins,Invariants checked by the taler-helper-auditor-deposits,Invariants checked by the taler-helper-auditor-aggregation,Invariants checked by the auditor
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-coins}@anchor{31}
+@subsection Invariants checked by the taler-helper-auditor-coins
+
+
+This is from CodeBlau’s analysis. A proper write-up is pending.
+CodeBlau reports the following checks:
+
+
+@itemize -
+
+@item 
+check that all denominations used by the exchange have been signed using
+this auditor’s key. All denominations encountered in the database that
+this auditor did not officially sign for are reported (but still included
+in the audit as they obviously may impact the exchange’s bank balance).
+Depending on the business situation, this may be normal (say if an exchange
+is changing auditors and newer denominations are no longer supported until
+their end-of-life by the current auditor).
+
+@item 
+emergency on denomination over loss
+
+
+@itemize -
+
+@item 
+value of coins deposited exceed value of coins issued
+@end itemize
+
+@item 
+emergency on number of coins, num mismatch
+
+@item 
+arithmetic inconsistencies
+
+
+@itemize -
+
+@item 
+melt contribution vs. fee
+
+@item 
+melt (cost)
+
+@item 
+refund fee
+@end itemize
+
+@item 
+row inconsistencies
+
+
+@itemize -
+
+@item 
+revocation signature invalid
+
+@item 
+denomination key not found
+
+@item 
+denomination key for fresh coin unknown to auditor
+
+@item 
+denomination key for dirty coin unknown to auditor
+
+@item 
+denomination key for deposited coin unknown to auditor
+@end itemize
+
+@item 
+coin validity in known_coin, by checking denomination signatures
+
+@item 
+coin validity in melt, by checking signatures
+
+@item 
+refresh hanging, zero reveals (harmless)
+
+@item 
+verify deposit signature
+
+@item 
+verify refund signature
+
+@item 
+recoup, check coin
+
+@item 
+recoup, check signature
+
+@item 
+recoup, denomination not revoked
+@end itemize
+
+@node Invariants checked by the taler-helper-auditor-deposits,Invariants checked by the taler-helper-auditor-reserves,Invariants checked by the taler-helper-auditor-coins,Invariants checked by the auditor
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-deposits}@anchor{32}
+@subsection Invariants checked by the taler-helper-auditor-deposits
+
+
+This tool verifies that the deposit confirmations reported by merchants
+directly to the auditor are also included in the database duplicated from the
+exchange at the auditor.  This is to ensure that the exchange cannot defraud
+merchants by simply not reporting deposits to the auditor.
+
+@node Invariants checked by the taler-helper-auditor-reserves,Invariants checked by the taler-helper-auditor-wire,Invariants checked by the taler-helper-auditor-deposits,Invariants checked by the auditor
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-reserves}@anchor{33}
+@subsection Invariants checked by the taler-helper-auditor-reserves
+
+
+This is from CodeBlau’s analysis. A proper write-up is pending.
+CodeBlau reports the following checks:
+
+
+@itemize -
+
+@item 
+report arithmetic inconsistency
+
+
+@itemize -
+
+@item 
+closing aggregation fee
+
+@item 
+global escrow balance
+@end itemize
+
+@item 
+denomination key validity withdraw inconsistencies
+
+@item 
+bad signature losses in withdraw
+
+@item 
+bad signature losses in recoup
+
+@item 
+bad signature losses in recoup-master
+
+@item 
+reserve balance, insufficient, losses and gains
+
+@item 
+reserve balance, summary wrong
+
+@item 
+reserve not closed after expiration time
+
+@item 
+could not determine closing fee / closing-fee unavailable
+
+@item 
+denomination key not found for withdraw
+
+@item 
+denomination key not in revocation set for recoup
+
+@item 
+target account not verified, auditor does not know reserve
+
+@item 
+target account does not match origin account
+@end itemize
+
+@node Invariants checked by the taler-helper-auditor-wire,,Invariants checked by the taler-helper-auditor-reserves,Invariants checked by the auditor
+@anchor{taler-auditor-manual invariants-checked-by-the-taler-helper-auditor-wire}@anchor{34}
+@subsection Invariants checked by the taler-helper-auditor-wire
+
+
+This auditor is special in that it is the only pass that is required to have
+@emph{read-only} access to the exchange’s bank account (privilege separation).  Its
+main role is to verify that the wire transfers in the exchange’s database and
+those reported by the bank are identical.
+
+This is from CodeBlau’s analysis. A proper write-up is pending.
+CodeBlau reports the following checks:
+
+
+@itemize -
+
+@item 
+check pending
+
+@item 
+wire missing
+
+@item 
+execution date mismatch
+
+@item 
+wire out consistency
+
+@item 
+wire transfer not made (yet?)
+
+@item 
+receiver account mismatch
+
+@item 
+wire amount does not match
+
+@item 
+justification for wire transfer not found
+
+@item 
+duplicate subject hash
+
+@item 
+duplicate wire offset
+
+@item 
+incoming wire transfer claimed by exchange not found
+
+@item 
+wire subject does not match
+
+@item 
+wire amount does not match
+
+@item 
+debit account url does not match
+
+@item 
+execution date mismatch
+
+@item 
+closing fee above total amount
+@end itemize
+
+@node Testing the auditor,,Invariants checked by the auditor,Auditor implementation guide
+@anchor{taler-auditor-manual testing-the-auditor}@anchor{35}
+@section Testing the auditor
+
+
+The main objective of the auditor is to detect inconsistencies. Thus, the
+@code{test-auditor.sh} script deliberately introduces various inconsistencies into
+a synthetic exchange database.  For this, an “normal” exchange database is
+first generated using the @code{taler-wallet-cli}.  Then, various fields or rows
+of that database are manipulated, and the auditor is let loose on the modified
+database.  Afterwards, the test verifies that the JSON contains values
+indicating that the auditor found the inconsistencies.  The script also
+verifies that template expansion and LaTeX run work for the JSON output,
+but it does not verify the correctness of the final PDF.
+
+The @code{test-auditor.sh} script is written to maximize code coverage: it should
+cover as many code paths as possible in both the exchange and the auditor.  It
+should also ideally create all interesting possible variations of the exchange
+database fields (within the constraints of the database schema).
+
+In general, @code{test-auditor.sh} runs the tests against an “old” database where
+some transactions are past the due-date (and hence the aggregator would trigger
+wire transfers), as well as a freshly generated exchange database where the
+auditor would not perform any transfers.  Auditor interactions can be made
+before or after the aggregator, depending on what is being tested.
+
+The current script also rudimentarily tests the auditor’s resume logic,
+by re-starting the auditor once against a database that the auditor has
+already seen.
+
+The @code{test-revocation.sh} script performs tests related to the handling of
+key revocations.
+
+The @code{test-sync.sh} script performs tests related to the @code{taler-auditor-sync}
+tool.
+
+@c TODO
+@c 
+@c More extensive auditor testing where additional transactions
+@c have been made against the database when the audit is being resumed
+@c should be done in the future.
+
+@node Index,,Auditor implementation guide,Top
+@unnumbered Index
+
+
+@printindex ge
+
+
+@c %**end of body
+@bye
diff --git a/texinfo/taler-bank-figures/auditor-db.png b/texinfo/taler-bank-figures/auditor-db.png
new file mode 100644
index 00000000..3f10f3ab
--- /dev/null
+++ b/texinfo/taler-bank-figures/auditor-db.png
diff --git a/texinfo/taler-bank-figures/exchange-db.png b/texinfo/taler-bank-figures/exchange-db.png
index b088da04..f99e2664 100644
--- a/texinfo/taler-bank-figures/exchange-db.png
+++ b/texinfo/taler-bank-figures/exchange-db.png
diff --git a/texinfo/taler-bank-figures/merchant-db.png b/texinfo/taler-bank-figures/merchant-db.png
new file mode 100644
index 00000000..cd5f7bd6
--- /dev/null
+++ b/texinfo/taler-bank-figures/merchant-db.png
diff --git a/texinfo/taler-bank-figures/replication.png b/texinfo/taler-bank-figures/replication.png
new file mode 100644
index 00000000..855237fc
--- /dev/null
+++ b/texinfo/taler-bank-figures/replication.png
diff --git a/texinfo/taler-bank.texi b/texinfo/taler-bank.texi
index 075df81e..c2edaeca 100644
--- a/texinfo/taler-bank.texi
+++ b/texinfo/taler-bank.texi
@@ -3,7 +3,7 @@
 @setfilename taler-bank.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 2.2.0.@*
+@*Generated by Sphinx 3.4.3.@*
 @end ifinfo
 @settitle Taler Bank Manual
 @defindex ge
@@ -21,11 +21,11 @@
 
 @copying
 @quotation
-GNU Taler 0.6.0pre1, Dec 20, 2019
+GNU Taler 0.8.0pre0, Jan 21, 2021
 
 GNU Taler team
 
-Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @end quotation
 
 @end copying
@@ -50,7 +50,7 @@ Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Hars
 @anchor{taler-bank-manual doc}@anchor{0}
 @menu
 * Introduction:: 
-* Reference:: 
+* Headless Testing API Reference:: 
 
 @detailmenu
  --- The Detailed Node Listing ---
@@ -60,20 +60,10 @@ Introduction
 * About GNU Taler:: 
 * About this manual:: 
 
-Reference
-
-* Bank-Wallet interaction:: 
-* Bank-Exchange interaction:: 
-
-Bank-Exchange interaction
-
-* Withdraw:: 
-* Exchange pays merchant:: 
-
 @end detailmenu
 @end menu
 
-@node Introduction,Reference,Top,Top
+@node Introduction,Headless Testing API Reference,Top,Top
 @anchor{taler-bank-manual gnu-taler-bank-manual}@anchor{1}@anchor{taler-bank-manual introduction}@anchor{2}
 @chapter Introduction
 
@@ -111,238 +101,59 @@ local/regional currency. Finally, “real” banks might use it as a
 reference implementation for a tight integration with the GNU Taler
 wallet.
 
-@node Reference,,Introduction,Top
-@anchor{taler-bank-manual id1}@anchor{5}@anchor{taler-bank-manual reference}@anchor{6}
-@chapter Reference
-
-
-@menu
-* Bank-Wallet interaction:: 
-* Bank-Exchange interaction:: 
-
-@end menu
-
-@node Bank-Wallet interaction,Bank-Exchange interaction,,Reference
-@anchor{taler-bank-manual bank-002dwallet-interaction}@anchor{7}@anchor{taler-bank-manual bank-wallet-interaction}@anchor{8}
-@section Bank-Wallet interaction
-
-
-The HTTP status code @code{202 Accepted} can be used by the bank website to
-trigger operations in the user agent. The operation is determined by the
-@code{X-Taler-Operation} header. The following operations are understood:
-
-
-@table @asis
-
-@item @code{create-reserve}
-
-Ask the Taler wallet to create a reserve and call back the bank with
-the reserve public key. The following headers are mandatory:
-
-
-@itemize -
-
-@item 
-@code{X-Taler-Callback-Url}: URL that the wallet will visit when the
-reserve was created and the user has selected an exchange.
-
-@item 
-@code{X-Taler-Wt-Types}: JSON-encoded array of wire transfer types
-that this bank supports.
-
-@item 
-@code{X-Taler-Amount}: The amount that will be transferred to the
-reserve.
-
-@item 
-@code{X-Taler-Sender-Wire}: JSON-encoded wire account details of the
-sender, that is the user that is currently logged in with the bank
-and creates the reserve.
-@end itemize
-
-The following header is optional:
-
-
-@itemize -
+@node Headless Testing API Reference,,Introduction,Top
+@anchor{taler-bank-manual headless-testing-api-reference}@anchor{5}
+@chapter Headless Testing API Reference
 
-@item 
-@code{X-Taler-Suggested-Exchange}: Exchange that the bank recommends
-the customer to use. Note that this is a suggestion and can be
-ignored by the wallet or changed by the user.
-@end itemize
 
-On successful reserve creation, the wallet will navigate to the
-callback URL (effectively requesting it with a GET) with the
-following additional request parameters:
+The demonstrator bank offers the following APIs to allow automated testing.  These APIs should
+be switched off during a production deployment.
+@anchor{taler-bank-manual bank-register}@anchor{6}
+@anchor{taler-bank-manual post--register}@anchor{7}
+@deffn {HTTP Post} POST /register
 
+This API provides programmatic user registration at the bank.
 
-@itemize -
+@strong{Request} The body of this request must have the format of a
+@ref{8,,BankRegistrationRequest}.
 
-@item 
-@code{exchange}: The URL of the exchange selected by the user
-
-@item 
-@code{wire_details}: The wire details of the exchange.
-
-@item 
-@code{reserve_pub}: The reserve public key that the bank should
-transmit to the exchange when transmitting the funds.
-@end itemize
-
-@item @code{confirm-reserve}
-
-To secure the operation, the (demo) bank then shows a “CAPTCHA page”
-– a real bank would instead show some PIN entry dialog or similar
-security method – where the customer can finally prove she their
-identity and thereby confirm the withdraw operation to the bank.
-
-Afterwards, the bank needs to confirm to the wallet that the user
-completed the required steps to transfer funds to an exchange to
-establish the reserve identified by the @code{X-Taler-Reserve-Pub}
-header.
-
-This does not guarantee that the reserve is already created at the
-exchange (since the actual money transfer might be executed
-asynchronously), but it informs that wallet that it can start polling
-for the reserve.
-@end table
-
-@node Bank-Exchange interaction,,Bank-Wallet interaction,Reference
-@anchor{taler-bank-manual bank-002dexchange-interaction}@anchor{9}@anchor{taler-bank-manual bank-exchange-interaction}@anchor{a}
-@section Bank-Exchange interaction
-
-
-The interaction between a bank and the exchange happens in two
-situations: when a wallet withdraws coins, and when the exchange pays a
-merchant.
-
-@menu
-* Withdraw:: 
-* Exchange pays merchant:: 
-
-@end menu
-
-@node Withdraw,Exchange pays merchant,,Bank-Exchange interaction
-@anchor{taler-bank-manual withdraw}@anchor{b}
-@subsection Withdraw
-
-
-Once a withdrawal operation with the wallet has been confirmed, the the
-bank must wire transfer the withdrawn amount from the customer account
-to the exchange’s. After this operation is done, the exchange needs to
-be informed so that it will create the reserve.
-
-For the moment, the bank will use the exchange’s @code{/admin/add/incoming}
-API, providing those arguments it got along the @code{X-Taler-Callback-Url}
-URL. (In the future, the exchange will poll for this information.)
-However, the bank will define two additional values for this API:
-@code{execution_date} (a operation’s timestamp), and @code{transfer_details}
-(just a “seed” to make unique the operation). See
-@indicateurl{https://docs.taler.net/api/api-exchange.html#administrative-api-bank-transactions}.
-
-The polling mechanism is possbile thanks to the @code{/history} API
-provided by the bank. The exchange will periodically use this API to see
-if it has received new wire transfers; upon receiving a new wire
-transfer, the exchange will automatically create a reserve and allow the
-money sender to withdraw.
+@strong{Response}
 
 
 @table @asis
 
-@item @code{GET /history}
-
-Ask the bank to return a list of money transactions related to a
-caller’s bank account.
+@item 200 OK@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1}:
 
+The new user has been correctly registered.
 
-@itemize -
+@item 409 Conflict@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10}:
 
-@item 
-@code{auth} a string indicating the authentication method to use;
-only @code{"basic"} value is accepted so far. The username and
-password credentials have to be sent along the HTTP request
-headers. Namely, the bank will look for the following two headers:
-@code{X-Taler-Bank-Username} and @code{X-Taler-Bank-Password}, which
-will contain those plain text credentials.
+The username requested by the client is not available anymore.
 
-@item 
-@code{delta} returns the first @code{N} records younger (older) than
-@code{start} if @code{+N} (@code{-N}) is specified.
+@item 400 Bad request@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1}:
 
-@item 
-@code{start} according to delta, only those records with row id
-strictly greater (lesser) than start will be returned. This
-argument is optional; if not given, delta youngest records will be
-returned.
-
-@item 
-@code{direction} optional argument taking values debit or credit,
-according to the caller willing to receive both incoming and
-outgoing, only outgoing, or only incoming records
-
-@item 
-@code{account_number} optional argument indicating the bank account
-number whose history is to be returned. If not given, then the
-history of the calling user will be returned
-@end itemize
+Unacceptable characters were given for the username. See
+@indicateurl{https://docs.djangoproject.com/en/2.2/ref/contrib/auth/#django.contrib.auth.models.User.username}
+for the accepted character set.
 @end table
+@end deffn
 
-@node Exchange pays merchant,,Withdraw,Bank-Exchange interaction
-@anchor{taler-bank-manual exchange-pays-merchant}@anchor{c}
-@subsection Exchange pays merchant
-
+@strong{Details}
 
-To allow the exchange to send payments to a merchant, the bank exposes
-the @code{/admin/add/incoming} API to exchanges.
+@example
+interface BankRegistrationRequest @{
 
+  // Username to use for registration; max length is 150 chars.
+  username: string;
 
-@table @asis
-
-@item @code{POST /admin/add/incoming}
-
-Ask the bank to transfer money from the caller’s account to the
-receiver’s.
-
-
-@itemize -
-
-@item 
-@code{auth} a string indicating the authentication method to use;
-only @code{"basic"} value is accepted so far. The username and
-password credentials have to be sent along the HTTP request
-headers. Namely, the bank will look for the following two headers:
-@code{X-Taler-Bank-Username} and @code{X-Taler-Bank-Password}, which
-will contain those plain text credentials.
-
-@item 
-@code{amount} a JSON object complying to the Taler amounts layout.
-Namely, this object must contain the following fields: @code{value}
-(number), @code{fraction} (number), and @code{currency} (string).
-
-@item 
-@code{exchange_url} a string indicating the calling exchange base
-URL. The bank will use this value to define wire transfers subject
-lines.
-
-@item 
-@code{wtid} a alphanumeric string that uniquely identifies this
-transfer at the exchange database. The bank will use this value
-too to define wire transfers subject lines. Namely, subject lines
-will have the following format: @code{'wtid exchange_url'}.
-
-@item 
-@code{debit_account} number indicating the exchange bank account.
-NOTE: this field is currently ignored, as the bank can retrieve
-the exchange account number from the login credentials. However,
-in future release, an exchange could have multiple account at the
-same bank, thereby it will have the chance to specify any of them
-in this field.
-
-@item 
-@code{credit_account} bank account number that will receive the
-transfer. Tipically the merchant account number.
-@end itemize
-@end table
+  // Password to associate with the username.  Any characters and
+  // any length are valid; next releases will enforce a minimum length
+  // and a safer characters choice.
+  password: string;
+@}
+@end example
+@anchor{taler-bank-manual tsref-type-BankRegistrationRequest}@w{                              }
+@anchor{8}@w{                              }
 
 @c %**end of body
 @bye
diff --git a/texinfo/taler-exchange-figures/auditor-db.png b/texinfo/taler-exchange-figures/auditor-db.png
new file mode 100644
index 00000000..3f10f3ab
--- /dev/null
+++ b/texinfo/taler-exchange-figures/auditor-db.png
diff --git a/texinfo/taler-exchange-figures/exchange-db.png b/texinfo/taler-exchange-figures/exchange-db.png
index b088da04..f99e2664 100644
--- a/texinfo/taler-exchange-figures/exchange-db.png
+++ b/texinfo/taler-exchange-figures/exchange-db.png
diff --git a/texinfo/taler-exchange-figures/replication.png b/texinfo/taler-exchange-figures/replication.png
new file mode 100644
index 00000000..855237fc
--- /dev/null
+++ b/texinfo/taler-exchange-figures/replication.png
diff --git a/texinfo/taler-exchange.texi b/texinfo/taler-exchange.texi
index 7e2fa5fb..5251f547 100644
--- a/texinfo/taler-exchange.texi
+++ b/texinfo/taler-exchange.texi
@@ -3,7 +3,7 @@
 @setfilename taler-exchange.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 2.2.0.@*
+@*Generated by Sphinx 3.4.3.@*
 @end ifinfo
 @settitle Taler Exchange Manual
 @defindex ge
@@ -21,11 +21,11 @@
 
 @copying
 @quotation
-GNU Taler 0.6.0pre1, Dec 20, 2019
+GNU Taler 0.8.0pre0, Jan 21, 2021
 
 GNU Taler team
 
-Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @end quotation
 
 @end copying
@@ -48,12 +48,31 @@ Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Hars
 
 @c %**start of body
 @anchor{taler-exchange-manual doc}@anchor{0}
+@c This file is part of GNU TALER.
+@c 
+@c Copyright (C) 2014-2020 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU 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 General Public License for more details.
+@c 
+@c You should have received a copy of the GNU General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Christian Grothoff
+
 @menu
 * Introduction:: 
 * Installation:: 
-* Configuration:: 
+* Configuration: Configuration<2>. 
 * Deployment:: 
 * Diagnostics:: 
+* Benchmarking:: 
+* Index:: 
 
 @detailmenu
  --- The Detailed Node Listing ---
@@ -64,6 +83,20 @@ Introduction
 * About this manual:: 
 * Organizational prerequisites:: 
 * Architecture overview:: 
+* Offline keys:: 
+* Online signing key security:: 
+
+Online signing key security
+
+* Functionality:: 
+* Security goals:: 
+* Setup:: 
+* Configuration:: 
+
+Installation
+
+* Installing from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
 
 Configuration
 
@@ -72,38 +105,36 @@ Configuration
 * Keying:: 
 * Serving:: 
 * Currency:: 
-* Bank account:: 
 * Database:: 
 * Coins (denomination keys): Coins denomination keys. 
-* Keys duration:: 
+* Sign keys:: 
 * Terms of Service:: 
-
-Bank account
-
-* Wire plugin “taler_bank”:: 
-* Wire plugin “ebics”:: 
-* Wire fee structure:: 
+* Bank account:: 
+* Auditor configuration:: 
 
 Terms of Service
 
 * Example:: 
 
+Bank account
+
+* Wire fee structure:: 
+
 Deployment
 
+* Launching an exchange:: 
 * Keys generation:: 
+* Private key storage:: 
 * Database upgrades:: 
 
-Diagnostics
+Database upgrades
 
-* Reserve management:: 
-* Database Scheme:: 
-* Signing key storage:: 
-* Denomination key storage:: 
-* Auditor signature storage:: 
+* Revocations:: 
 
-Denomination key storage
+Diagnostics
 
-* Revocations:: 
+* Internal audits:: 
+* Database Scheme:: 
 
 @end detailmenu
 @end menu
@@ -121,6 +152,8 @@ to become readable.
 * About this manual:: 
 * Organizational prerequisites:: 
 * Architecture overview:: 
+* Offline keys:: 
+* Online signing key security:: 
 
 @end menu
 
@@ -164,12 +197,7 @@ license and/or follow applicable financial regulation.
 GNU Taler payment service providers generally need to ensure high
 availability and have @emph{really} good backups (synchronous replication,
 asynchronous remote replication, off-site backup, 24/7 monitoring,
-etc.). @footnote{@w{(1)} 
-Naturally, you could operate a Taler exchange for a toy currency
-without any real value on low-cost setups like a Raspberry Pi, but we
-urge you to limit the use of such setups to research and education as
-with GNU Taler data loss instantly results in financial losses.
-} This manual will not cover these aspects of operating a
+etc.).  This manual will not cover these aspects of operating a
 payment service provider.
 
 We will assume that you can operate a (high-availability,
@@ -177,18 +205,9 @@ high-assurance) Postgres database. Furthermore, we expect some moderate
 familiarity with the compilation and installation of free software
 packages. You need to understand the cryptographic concepts of private
 and public keys and must be able to protect private keys stored in files
-on disk. An exchange uses an @emph{offline} master key as well as @emph{online}
-keys. You are advised to secure your private master key and any copies
-on encrypted, always-offline computers. Again, we assume that you are
-familiar with good best practices in operational security, including
-securing key material. @footnote{@w{(2)} 
-The current implementation does not make provisions for secret
-splitting. Still, the use of a hardware security module (HSM) for
-protecting private keys is adviseable, so please contact the
-developers for HSM integration support.
-}
-
-@node Architecture overview,,Organizational prerequisites,Introduction
+on disk.
+
+@node Architecture overview,Offline keys,Organizational prerequisites,Introduction
 @anchor{taler-exchange-manual architecture-overview}@anchor{6}
 @section Architecture overview
 
@@ -201,6 +220,13 @@ currencies such as USD or EUR. Similarly, the Taler exchange must
 interact with a bank. The bank of the exchange holds the exchange’s
 funds in an escrow account.
 
+Note that, given the technical burden (XML-based communications,
+additional cryptography, and a vast variety of standards) due to
+interact with banks, the exchange uses a intermediary system to talk
+to its bank.  Such intermediary system abstracts the native banking
+protocol by exposing the @emph{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 escrow account, the bank notifies the
 exchange about the incoming wire transfers. The exchange then creates a
 @emph{reserve} based on the subject of the wire transfer. The wallet which
@@ -235,47 +261,209 @@ 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} and @code{taler-exchange-secmod-eddsa}
+are two 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 be charge a fee per wire transfer to discourage
+exchange may charge a fee per wire transfer to discourage
 excessively frequent transfers. The binary is the
 @code{taler-exchange-aggregator}.
 
 @item 
-Auditor
-The auditor verifies that the transactions performed by the exchange
-were done properly. It checks the various signatures, totals up the
-amounts and alerts the operator to any inconsistencies. It also
-computes the expected bank balance, revenue and risk exposure of the
-exchange operator. The main binary is the @code{taler-auditor}.
+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.
+
+
+@enumerate 
+
+@item 
+The libtalerfakebank implements a bank with a wire adapter API
+inside of a testcase.
+
+@item 
+For the demonstration Web site (or local currencies),
+the Python bank provides a bank that directly provides
+the wire adapter API.
 
 @item 
-Wire plugin
-A wire plugin enables the HTTP frontend to talk to the bank. Its role
-is to allow the exchange to validate bank addresses (i.e. IBAN
-numbers), for the aggregator to execute wire transfers and for the
-auditor to query bank transaction histories. Wire plugins are
-@emph{plugins} as there can be many different implementations to deal with
-different banking standards. Wire plugins are automatically located
-and used by the exchange, aggregator and auditor.
+For production, libeufin’s Nexus component implements a wire
+adapter towards the traditional SEPA banking system with IBAN
+accounts.
+@end enumerate
+
+The client-side wire adapter API is implemented in libtalerbank and
+is used by the transfer to execute wire transfers and for the
+auditor to query bank transaction histories.
 
 @item 
 DBMS
-Postgres
 The exchange requires a DBMS to stores the transaction history for
 the Taler exchange and aggregator, and a (typically separate) DBMS
-for the Taler auditor. For now, the GNU Taler reference implemenation
+for the Taler auditor. For now, the GNU Taler reference implementation
 only supports Postgres, but the code could be easily extended to
 support another DBMS.
+.. index:: Postgres
+
+@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 database.
 @end itemize
 
-@node Installation,Configuration,Introduction,Top
-@anchor{taler-exchange-manual installation}@anchor{7}
+@node Offline keys,Online signing key security,Architecture overview,Introduction
+@anchor{taler-exchange-manual offline-keys}@anchor{7}
+@section Offline keys
+
+
+The exchange (and ideally also auditors) 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 your private master key and
+any copies on encrypted, always-offline computers. Again, we assume that you
+are familiar with good best practices in operational security, including
+securing key material.
+
+@node Online signing key security,,Offline keys,Introduction
+@anchor{taler-exchange-manual online-signing-key-security}@anchor{8}
+@section Online signing key security
+
+
+To provide an additional level of protection for the private @emph{online} signing
+keys used by the exchange, the actual cryptographic signing operations are
+performed by two helper processes, the @code{taler-exchange-secmod-rsa} and the
+@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{9}
+@subsection Functionality
+
+
+The UNIX domain sockets have mode 0620 (u+rw, g+w).  The exchange process
+MUST be in the same group as the the crypto helper processes.
+
+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{a}
+@subsection Security goals
+
+
+From a security point of view, the helpers are designed to @emph{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{b}
+@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.  For security,
+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.  To enable access to the keys, the service’s user
+must be in the group of the helper processes (and no other users should be in
+that group).
+
+@node Configuration,,Setup,Online signing key security
+@anchor{taler-exchange-manual configuration}@anchor{c}
+@subsection Configuration
+
+
+The helpers and the 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<2>,Introduction,Top
+@anchor{taler-exchange-manual installation}@anchor{d}
 @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.
+
 Please install the following packages before proceeding with the
 exchange compilation.
 
@@ -283,31 +471,25 @@ exchange compilation.
 @itemize -
 
 @item 
-GNU autoconf >= 2.69
+libsqlite3 >= 3.16.2
 
 @item 
-GNU automake >= 1.14
-
-@item 
-GNU libtool >= 2.4
+GNU libunistring >= 0.9.3
 
 @item 
-GNU autopoint >= 0.19
+libcurl >= 7.26 (or libgnurl >= 7.26)
 
 @item 
-GNU libltdl >= 2.4
+libqrencode >= 4.0.0
 
 @item 
-GNU libunistring >= 0.9.3
-
-@item 
-libcurl >= 7.26 (or libgnurl >= 7.26)
+GNU libgcrypt >= 1.6
 
 @item 
-GNU libmicrohttpd >= 0.9.59
+libsodium >= 1.0
 
 @item 
-GNU libgcrypt >= 1.6
+libargon2 >= 20171227
 
 @item 
 libjansson >= 2.7
@@ -316,45 +498,60 @@ libjansson >= 2.7
 Postgres >= 9.6, including libpq
 
 @item 
-libgnunetutil (from Git)
+GNU libmicrohttpd >= 0.9.71
+
+@item 
+GNUnet >= 0.14.0 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
 
 @item 
-GNU Taler exchange (from Git)
+GNU Taler exchange (from download directory@footnote{http://ftpmirror.gnu.org/taler/},
+see release announcement@footnote{https://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=taler&idxname=info-gnu&max=20&result=normal&sort=date:late})
 @end itemize
 
 Except for the last two, these are available in most GNU/Linux
 distributions and should just be installed using the respective package
 manager.
 
+@menu
+* Installing from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
+
+@end menu
+
+@node Installing from source,Installing the GNU Taler binary packages on Debian,,Installation
+@anchor{taler-exchange-manual installing-from-source}@anchor{e}
+@section Installing from source
+
+
 The following instructions will show how to install libgnunetutil and
-the GNU Taler exchange.
+the GNU Taler exchange from source.
 
-Before you install libgnunetutil, you must download and install the
-dependencies mentioned above, otherwise the build may succeed but fail
-to export some of the tooling required by Taler.
+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.
 
-To download and install libgnunetutil, proceed as follows:
+To install GNUnet, unpack the tarball and change
+into the resulting directory, then proceed as follows:
 
 @example
-$ git clone https://git.gnunet.org/gnunet/
-$ cd gnunet/
-$ ./bootstrap
 $ ./configure [--prefix=GNUNETPFX]
 $ # Each dependency can be fetched from non standard locations via
 $ # the '--with-<LIBNAME>' option. See './configure --help'.
 $ make
 # make install
+# 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.
 
-To download and install the GNU Taler exchange, proceeds as follows:
+After installing GNUnet, unpack the GNU Taler exchange tarball,
+change into the resulting directory, and proceed as follows:
 
 @example
-$ git clone git://git.taler.net/exchange
-$ cd exchange
-$ ./bootstrap
 $ ./configure [--prefix=EXCHANGEPFX] \
               [--with-gnunet=GNUNETPFX]
 $ # Each dependency can be fetched from non standard locations via
@@ -363,13 +560,88 @@ $ make
 # make install
 @end example
 
-If you did not specify a prefix, the exchange will install to
-@code{/usr/local}, which requires you to run the last step as @code{root}.
-Note that you have to specify @code{--with-gnunet=/usr/local} if you
-installed GNUnet to @code{/usr/local} in the previous step.
+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.
+
+@node Installing the GNU Taler binary packages on Debian,,Installing from source,Installation
+@anchor{taler-exchange-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{f}
+@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
+Sid, which means you should use a system which at least includes
+unstable packages in its source list.  We recommend using APT pinning
+to limit unstable packages to those explicitly requested. To do this,
+set your @code{/etc/apt/preferences} as follows:
+
+@example
+Package: *
+Pin: release a=stable
+Pin-Priority: 700
+
+Package: *
+Pin: release a=testing
+Pin-Priority: 650
+
+Package: *
+Pin: release a=unstable
+Pin-Priority: 600
+
+Package: *
+Pin: release l=Debian-Security
+Pin-Priority: 1000
+@end example
+
+A typical @code{/etc/apt/sources.list} file for this setup
+would look like this:
+
+@example
+deb http://ftp.ch.debian.org/debian/ buster main
+deb http://security.debian.org/debian-security buster/updates main
+deb http://ftp.ch.debian.org/debian/ testing main
+deb http://ftp.ch.debian.org/debian/ unstable main
+deb https://deb.taler.net/apt/debian sid main
+@end example
+
+The last line is crucial, as it adds the GNU Taler packages.
+
+Next, you must import the Taler Systems SA public package signing key
+into your keyring and update the package lists:
+
+@example
+# wget -O - https://taler.net/taler-systems.gpg.key | apt-sign add -
+# 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
+# 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.
 
-@node Configuration,Deployment,Installation,Top
-@anchor{taler-exchange-manual configuration}@anchor{8}
+Sample configuration files for the HTTP reverse proxy can be found in
+@code{/etc/taler-exchange/}.
+
+@node Configuration<2>,Deployment,Installation,Top
+@anchor{taler-exchange-manual id1}@anchor{10}
 @chapter Configuration
 
 
@@ -383,16 +655,17 @@ of some of the options.
 * Keying:: 
 * Serving:: 
 * Currency:: 
-* Bank account:: 
 * Database:: 
 * Coins (denomination keys): Coins denomination keys. 
-* Keys duration:: 
+* Sign keys:: 
 * Terms of Service:: 
+* Bank account:: 
+* Auditor configuration:: 
 
 @end menu
 
-@node Configuration format,Using taler-config,,Configuration
-@anchor{taler-exchange-manual configuration-format}@anchor{9}
+@node Configuration format,Using taler-config,,Configuration<2>
+@anchor{taler-exchange-manual configuration-format}@anchor{11}
 @section Configuration format
 
 
@@ -466,8 +739,8 @@ values, as their work is often interdependent. For example, a
 merchant needs to know an exchange URL, or a database name.
 @end quotation
 
-@node Using taler-config,Keying,Configuration format,Configuration
-@anchor{taler-exchange-manual using-taler-002dconfig-exchange}@anchor{a}@anchor{taler-exchange-manual using-taler-config}@anchor{b}
+@node Using taler-config,Keying,Configuration format,Configuration<2>
+@anchor{taler-exchange-manual using-taler-002dconfig-exchange}@anchor{12}@anchor{taler-exchange-manual using-taler-config}@anchor{13}
 @section Using taler-config
 
 
@@ -519,34 +792,57 @@ While the configuration file is typically located at
 to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
 option.
 
-@node Keying,Serving,Using taler-config,Configuration
-@anchor{taler-exchange-manual id3}@anchor{c}@anchor{taler-exchange-manual keying}@anchor{d}
+@node Keying,Serving,Using taler-config,Configuration<2>
+@anchor{taler-exchange-manual id2}@anchor{14}@anchor{taler-exchange-manual keying}@anchor{15}
 @section Keying
 
 
-The exchange works with three types of keys:
+The exchange works with four types of keys:
 
 
 @itemize -
 
 @item 
-master key
+master key (kept offline)
+
+To create a master public key:
+
+@example
+$ gnunet-ecc --generate-keys=1 FILENAME
+$ gnunet-ecc --print-public-key FILENAME
+@end example
+
+FIXME: Add link to @code{gnunet-ecc} manpage.
 
 @item 
-sign keys
+sign keys (signs normal messages from the exchange)
 
 @item 
-denomination keys (see section Coins)
+denomination keys (signs electronic coins, see section Coins)
 
 @item 
-MASTER_PRIV_FILE: Path to the exchange’s master private file.
+security module keys (signs sign 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).
+
+Key options include:
+
+
+@itemize -
 
 @item 
-MASTER_PUBLIC_KEY: Must specify the exchange’s master public key.
+@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.
+
+@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.
 @end itemize
 
-@node Serving,Currency,Keying,Configuration
-@anchor{taler-exchange-manual id4}@anchor{e}@anchor{taler-exchange-manual serving}@anchor{f}
+@node Serving,Currency,Keying,Configuration<2>
+@anchor{taler-exchange-manual id3}@anchor{16}@anchor{taler-exchange-manual serving}@anchor{17}
 @section Serving
 
 
@@ -573,182 +869,21 @@ unixpath_mode: number giving the mode with the access permission MASK
 for the unixpath (i.e. 660 = rw-rw—-).
 @end itemize
 
-@node Currency,Bank account,Serving,Configuration
-@anchor{taler-exchange-manual currency}@anchor{10}@anchor{taler-exchange-manual id5}@anchor{11}
+@node Currency,Database,Serving,Configuration<2>
+@anchor{taler-exchange-manual currency}@anchor{18}@anchor{taler-exchange-manual id4}@anchor{19}
 @section Currency
 
 
 The exchange supports only one currency. This data is set under the
-respective option currency in section [taler].
-
-@node Bank account,Database,Currency,Configuration
-@anchor{taler-exchange-manual bank-account}@anchor{12}@anchor{taler-exchange-manual id6}@anchor{13}
-@section Bank account
-
-
-To configure a bank account in Taler, we need to furnish four pieces of
-information:
-
-
-@itemize -
-
-@item 
-The @code{payto://} URL of the bank account, which uniquely idenfies the
-account. Examples for such URLs include
-@code{payto://sepa/CH9300762011623852957} for a bank account in the
-single European payment area (SEPA) or
-@code{payto://x-taler-bank/localhost:8080/2} for the 2nd bank account a
-the Taler bank demonstrator running at @code{localhost} on port 8080.
-The first part of the URL following @code{payto://} (“sepa” or
-“x-taler-bank”) is called the wire method.
-
-@item 
-A matching wire plugin that implements a protocol to interact with
-the banking system. For example, the EBICS plugin can be used for
-SEPA transfers, or the “taler-bank” plugin can interact with the
-Taler bank demonstrator. A wire plugin only supports one particular
-wire method. Thus, you must make sure to pick a plugin that supports
-the wire method used in the URL.
-
-@item 
-A file containing the signed JSON-encoded bank account details for
-the /wire API. This is necessary as Taler supports offline signing
-for bank accounts for additional security.
-
-@item 
-Finally, the plugin needs to be provided resources for authentication
-to the respective banking service. The format in which the
-authentication information must be provided depends on the wire
-plugin.
-@end itemize
-
-You can configure multiple accounts for an exchange by creating sections
-starting with “account-” for the section name. You can ENABLE for each
-account whether it should be used, and for what (incoming or outgoing
-wire transfers):
-
-@example
-[account-1]
-URL = "payto://sepa/CH9300762011623852957"
-WIRE_RESPONSE = $@{TALER_CONFIG_HOME@}/account-1.json
-
-# Currently, only the 'taler_bank' plugin is implemented.
-PLUGIN = <plugin_name_here>
-
-# Use for exchange-aggregator (outgoing transfers)
-ENABLE_DEBIT = YES
-# Use for exchange-wirewatch (and listed in /wire)
-ENABLE_CREDIT = YES
-
-# Authentication options for the chosen plugin go here.
-# (Next sections have examples of authentication mechanisms)
-@end example
-
-The command line tool taler-exchange-wire is used to create the
-@code{account-1.json} file. For example, the utility may be invoked as
-follows to create all of the WIRE_RESPONSE files (in the locations
-specified by the configuration):
-
-@example
-$ taler-exchange-wire
-@end example
-
-The generated file will be echoed by the exchange when serving
-/wire @footnote{@w{(3)} 
-@indicateurl{https://api.taler.net/api-exchange.html#wire-req}
-} requests.
-
-@menu
-* Wire plugin “taler_bank”:: 
-* Wire plugin “ebics”:: 
-* Wire fee structure:: 
-
-@end menu
-
-@node Wire plugin “taler_bank”,Wire plugin “ebics”,,Bank account
-@anchor{taler-exchange-manual wire-plugin-0060-0060taler-005fbank-0027-0027}@anchor{14}@anchor{taler-exchange-manual wire-plugin-taler-bank}@anchor{15}
-@subsection Wire plugin “taler_bank”
+respective option @code{CURRENCY} in section [taler].
 
-
-x-taler-bank
-taler_bank plugin
-The @code{taler_bank} plugin implements the wire method “x-taler-bank”.
-
-The format of the @code{payto://} URL is
-@code{payto://x-taler-bank/HOSTNAME[:PORT]}.
-
-For basic authentication, the @code{taler_bank} plugin only supports simple
-password-based authentication. For this, the configuration must contain
-the “USERNAME” and “PASSWORD” of the respective account at the bank.
-
-@example
-[account-1]
-
-# Bank account details here..
-# ..
-
-# Authentication options for the taler_bank plugin below:
-
-TALER_BANK_AUTH_METHOD = basic
-USERNAME = exchange
-PASSWORD = super-secure
-@end example
-
-@node Wire plugin “ebics”,Wire fee structure,Wire plugin “taler_bank”,Bank account
-@anchor{taler-exchange-manual wire-plugin-0060-0060ebics-0027-0027}@anchor{16}@anchor{taler-exchange-manual wire-plugin-ebics}@anchor{17}
-@subsection Wire plugin “ebics”
-
-
-The “ebics” wire plugin is not fully implemented and today does not
-support actual wire transfers.
-
-@quotation
-
-@strong{Note}
-
-The rationale behind having multiple bank accounts is that the
-exchange operator, as a security measure, may want to instruct the
-bank that the incoming bank account is only supposed to @emph{receive}
-money.
-@end quotation
-
-@node Wire fee structure,,Wire plugin “ebics”,Bank account
-@anchor{taler-exchange-manual id8}@anchor{18}@anchor{taler-exchange-manual wire-fee-structure}@anchor{19}
-@subsection Wire fee structure
-
-
-wire fee
-fee
-For each wire method (“sepa” or “x-taler-wire”, but not per plugin!) the
-exchange configuration must specify applicable wire fees. This is done
-in configuration sections of the format @code{fees-METHOD}. There are two
-types of fees, simple wire fees and closing fees. Wire fees apply
-whenever the aggregator transfers funds to a merchant. Closing fees
-apply whenever the exchange closes a reserve (sending back funds to the
-customer). The fees must be constant for a full year, which is specified
-as part of the name of the option.
-
-@example
-[fees-iban]
-WIRE-FEE-2018 = EUR:0.01
-WIRE-FEE-2019 = EUR:0.01
-CLOSING-FEE-2018 = EUR:0.01
-CLOSING-FEE-2019 = EUR:0.01
-
-[fees-x-taler-bank]
-WIRE-FEE-2018 = KUDOS:0.01
-WIRE-FEE-2019 = KUDOS:0.01
-CLOSING-FEE-2018 = KUDOS:0.01
-CLOSING-FEE-2019 = KUDOS:0.01
-@end example
-
-@node Database,Coins denomination keys,Bank account,Configuration
-@anchor{taler-exchange-manual database}@anchor{1a}@anchor{taler-exchange-manual id9}@anchor{1b}
+@node Database,Coins denomination keys,Currency,Configuration<2>
+@anchor{taler-exchange-manual database}@anchor{1a}@anchor{taler-exchange-manual id5}@anchor{1b}
 @section Database
 
 
-The option db under section [exchange] gets the DB backend’s name the
-exchange is going to use. So far, only db = postgres is supported. After
+The option @code{DB} in section @code{[exchange]} gets the database backend’s name the
+exchange is going to use. So far, only @code{db = postgres} is supported. After
 choosing the backend, it is mandatory to supply the connection string
 (namely, the database name). This is possible in two ways:
 
@@ -773,99 +908,149 @@ DB = postgres
 CONFIG = postgres:///talerdemo
 @end example
 
-@node Coins denomination keys,Keys duration,Database,Configuration
-@anchor{taler-exchange-manual coins-denomination-keys}@anchor{1c}@anchor{taler-exchange-manual id10}@anchor{1d}
+Given this database configuration, the database can be initialized using:
+
+@example
+$ taler-exchange-dbinit
+@end example
+
+Note that to run this command, the user must have @code{CREATE TABLE}, @code{CREATE
+INDEX}, @code{ALTER TABLE} and (in the future possibly even) @code{DROP TABLE}
+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 @code{CREATE} or @code{ALTER} tables are not required by
+any of the Taler exchange processes and thus should not be granted.
+For more information, see manpages/taler-exchange-dbinit.1.
+
+Commands, like @code{taler-exchange-dbinit}, that support the @code{-l LOGFILE}
+command-line option, send logging output to standard error by default.
+
+@node Coins denomination keys,Sign keys,Database,Configuration<2>
+@anchor{taler-exchange-manual coins-denomination-keys}@anchor{1c}@anchor{taler-exchange-manual id6}@anchor{1d}
 @section Coins (denomination keys)
 
 
-Sections specifying denomination (coin) information start with @code{coin_}.
-By convention, the name continues with “$CURRENCY_[$SUBUNIT]_$VALUE”,
-i.e. @code{[coin_eur_ct_10]} for a 10 cent piece. However, only the @code{coin_}
-prefix is mandatory. Each @code{coin_}-section must then have the following
-options:
+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 
-value: How much is the coin worth, the format is
+@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 
-duration_withdraw: How long can a coin of this type be withdrawn?
+@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 
-duration_overlap: What is the overlap of the withdrawal timespan for
-this coin type?
-
-@item 
-duration_spend: How long is a coin of the given type valid? Smaller
+@code{DURATION_SPEND}: How long is a coin of the given type valid? Smaller
 values result in lower storage costs for the exchange.
 
 @item 
-fee_withdraw: What does it cost to withdraw this coin? Specified
+@code{FEE_WITHDRAW}: What does it cost to withdraw this coin? Specified
 using the same format as value.
 
 @item 
-fee_deposit: What does it cost to deposit this coin? Specified using
+@code{FEE_DEPOSIT}: What does it cost to deposit this coin? Specified using
 the same format as value.
 
 @item 
-fee_refresh: What does it cost to refresh this coin? Specified using
+@code{FEE_REFRESH}: What does it cost to refresh this coin? Specified using
 the same format as value.
 
 @item 
-rsa_keysize: How many bits should the RSA modulus (product of the two
+@code{RSA_KEYSIZE}: How many bits should the RSA modulus (product of the two
 primes) have for this type of coin.
 @end itemize
 
-@node Keys duration,Terms of Service,Coins denomination keys,Configuration
-@anchor{taler-exchange-manual id11}@anchor{1e}@anchor{taler-exchange-manual keys-duration}@anchor{1f}
-@section Keys duration
+See manpages/taler.conf.5 for information on @emph{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:
 
 
-Both signkeys and denom keys have a starting date. The option
-lookahead_provide, under section [exchange], is such that only keys
-whose starting date is younger than lookahead_provide will be issued by
-the exchange.
+@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
 
-signkeys. The option lookahead_sign is such that, being t the time when
-taler-exchange-keyup is run, taler-exchange-keyup will generate n
-signkeys, where t + (n * signkey_duration) = t + lookahead_sign. In
-other words, we generate a number of keys which is sufficient to cover a
-period of lookahead_sign. As for the starting date, the first generated
-key will get a starting time of t, and the j-th key will get a starting
-time of x + signkey_duration, where x is the starting time of the
-(j-1)-th key.
+@geindex maintenance
 
-denom keys. The option lookahead_sign is such that, being t the time
-when taler-exchange-keyup is run, taler-exchange-keyup will generate n
-denom keys for each denomination, where t + (n * duration_withdraw) = t
-+ lookahead_sign. In other words, for each denomination, we generate a
-number of keys which is sufficient to cover a period of lookahead_sign.
-As for the starting date, the first generated key will get a starting
-time of t, and the j-th key will get a starting time of x +
-duration_withdraw, where x is the starting time of the (j-1)-th key.
+@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
 
-To change these settings, edit the following values in section
-[exchange]:
+@node Sign keys,Terms of Service,Coins denomination keys,Configuration<2>
+@anchor{taler-exchange-manual id7}@anchor{1e}@anchor{taler-exchange-manual sign-keys}@anchor{1f}
+@section Sign keys
+
+
+There are three global configuration options of note for sign keys:
 
 
 @itemize -
 
 @item 
-SIGNKEY_DURATION: How long should one signing key be used?
+@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 
-LOOKAHEAD_SIGN: How much time we want to cover with our signing keys?
-Note that if SIGNKEY_DURATION is bigger than LOOKAHEAD_SIGN,
-@code{taler-exchange-keyup} will generate a quantity of signing keys
-which is sufficient to cover all the gap.
+@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
 
-@node Terms of Service,,Keys duration,Configuration
+@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 Terms of Service,Bank account,Sign keys,Configuration<2>
 @anchor{taler-exchange-manual terms-of-service}@anchor{20}
 @section Terms of Service
 
@@ -951,82 +1136,298 @@ If the user requests an HTML with language preferences “fr” followed by “e
 the exchange would return “TERMS_DIR/en/v1.html” lacking an HTML version in
 French.
 
-@node Deployment,Diagnostics,Configuration,Top
-@anchor{taler-exchange-manual deployment}@anchor{22}@anchor{taler-exchange-manual id12}@anchor{23}
-@chapter Deployment
+@node Bank account,Auditor configuration,Terms of Service,Configuration<2>
+@anchor{taler-exchange-manual bank-account}@anchor{22}@anchor{taler-exchange-manual id8}@anchor{23}
+@section Bank account
 
 
-This chapter describes how to deploy the exchange once it has been
-properly configured.
+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://} (“iban” or
+“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
+
+You can configure multiple accounts for an exchange by creating sections
+starting with “exchange-account-” for the section name. You can ENABLE for
+each account whether it should be used, and for what (incoming or outgoing
+wire transfers):
+
+@example
+[exchange-account-1]
+# With x-taler-bank (say for PyBank)
+PAYTO_URI = "payto://x-taler-bank/bank.demo.taler.net/Exchange"
+
+# Example using IBAN (for use with LibEuFin)
+# PAYTO_URI = "payto://iban/CH9300762011623852957"
+
+# URL for talking to the bank wire the wire API.
+WIRE_GATEWAY_URL = https://bank.demo.taler.net/taler-wire-gateway/Exchange
+
+# Use for exchange-aggregator (outgoing transfers)
+ENABLE_DEBIT = YES
+# Use for exchange-wirewatch (and listed in /wire)
+ENABLE_CREDIT = YES
+
+# Authentication options for exchange bank account go here.
+# (Next sections have examples of authentication mechanisms)
+WIRE_GATEWAY_AUTH_METHOD = basic
+USERNAME = exchange
+PASSWORD = super-secure
+@end example
+
+The command line tool @code{taler-exchange-offline} 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.
+For example, the utility may be invoked as
+follows to enable a wire account:
+
+@example
+$ taler-exchange-offline enable-account payto://iban/CH9300762011623852957
+@end example
+
+The resulting JSON output must be uploaded to the exchange using
+@code{taler-exchange-offline upload}.
+For details, see manpages/taler-exchange-offline.1.
 
 @menu
-* Keys generation:: 
-* Database upgrades:: 
+* Wire fee structure:: 
 
 @end menu
 
-@node Keys generation,Database upgrades,,Deployment
-@anchor{taler-exchange-manual id13}@anchor{24}@anchor{taler-exchange-manual keys-generation}@anchor{25}
-@section Keys generation
+@node Wire fee structure,,,Bank account
+@anchor{taler-exchange-manual id9}@anchor{24}@anchor{taler-exchange-manual wire-fee-structure}@anchor{25}
+@subsection Wire fee structure
+
 
+@geindex wire fee
 
-Once the configuration is properly set up, all the keys can be generated
-by the tool @code{taler-exchange-keyup}. The following command generates
-denomkeys and signkeys, plus the “blob” that is to be signed by the
-auditor.
+@geindex fee
+
+For each wire method (“sepa” or “x-taler-wire”) the
+exchange must know about applicable wire fees. This is also done
+using the @code{taler-exchange-offline} tool:
 
 @example
-taler-exchange-keyup -o blob
+$ taler-exchange-offline wire-fee iban 2040 EUR:0.05 EUR:0.10
 @end example
 
-@emph{blob} contains data about denomkeys that the exchange operator needs to
-get signed by every auditor he wishes (or is forced to) work with.
+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,,Bank account,Configuration<2>
+@anchor{taler-exchange-manual auditor-configuration}@anchor{26}@anchor{taler-exchange-manual id10}@anchor{27}
+@section Auditor configuration
 
-In a normal scenario, an auditor must have some way of receiving the
-blob to sign (Website, manual delivery, ..). Nonetheless, the exchange
-admin can fake an auditor signature — for testing purposes — by running
-the following command
+
+The exchange 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 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.  Given this
+information, the exchange operator can enable the auditor:
 
 @example
-taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o OUTPUT_FILE
+$ taler-exchange-offline enable-auditor $PUB_KEY $REST_URL "$AUDITOR_NAME" > auditor.json
 @end example
 
-Those arguments are all mandatory.
+As before, the @emph{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.
+
+@node Deployment,Diagnostics,Configuration<2>,Top
+@anchor{taler-exchange-manual deployment}@anchor{28}@anchor{taler-exchange-manual id11}@anchor{29}
+@chapter Deployment
+
+
+This chapter describes how to deploy the exchange once it has been
+configured.
+
+@menu
+* Launching an exchange:: 
+* Keys generation:: 
+* Private key storage:: 
+* Database upgrades:: 
+
+@end menu
+
+@node Launching an exchange,Keys generation,,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{EXCHANGE_MASTER_PUB} the base32 Crockford-encoded exchange’s
-master public key. Tipically, this value lies in the configuration
-option @code{[exchange]/master_public_key}.
+@code{taler-exchange-secmod-rsa} (as special user, sharing group with the HTTPD)
 
 @item 
-@code{BLOB} the blob generated in the previous step.
+@code{taler-exchange-secmod-eddsa} (as special user, sharing group with the HTTPD)
 
 @item 
-@code{AUDITOR_URL} the URL that identifies the auditor.
+@code{taler-exchange-httpd} (needs database access)
 
 @item 
-@code{OUTPUT_FILE} where on the disk the signed blob is to be saved.
+@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
 
-@code{OUTPUT_FILE} must then be copied into the directory specified by the
-option @code{AUDITOR_BASE_DIR} under the section @code{[exchangedb]}. Assuming
-@code{AUDITOR_BASE_DIR = $@{HOME@}/.local/share/taler/auditors}, the
-following command will “add” the auditor identified by @code{AUDITOR_URL}
-to the exchange.
+The crypto helpers 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 Postgres 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
+@emph{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
+@emph{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
+
+@node Keys generation,Private key storage,Launching an exchange,Deployment
+@anchor{taler-exchange-manual id12}@anchor{2c}@anchor{taler-exchange-manual keys-generation}@anchor{2d}
+@section Keys generation
+
+
+Once the configuration is properly set up, all the keys can be signed using
+the offline key on the offline system by the tool @code{taler-exchange-offline}.
+To do this, one must first start the crypto helpers and the @code{taler-exchange-httpd}
+process (the tools for wire transfers may also be started, but do not have to
+run yet).
+
+Next, the @emph{future} key material should be downloaded using:
+
+@example
+$ taler-exchange-offline download > future-keys.json
+@end example
+
+Afterwards, @emph{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 @emph{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 @emph{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.  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 the auditor
+to affirm that they are auditing this exchange.  Details about
+this are described in taler-auditor-manual.
+
+The simplistic (without using offline keys for the auditor) way
+to do this would be:
 
 @example
-cp OUTPUT_FILE $@{HOME@}/.local/share/taler/auditors
+$ taler-auditor-offline download sign upload
 @end example
 
-If the auditor has been correctly added, the exchange’s @code{/keys}
-response must contain an entry in the @code{auditors} array mentioning the
-auditor’s URL.
+For more information, see manpages/taler-auditor-offline.1.
+
+@node Private key storage,Database upgrades,Keys generation,Deployment
+@anchor{taler-exchange-manual private-key-storage}@anchor{2e}
+@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 @emph{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 Database upgrades,,Keys generation,Deployment
-@anchor{taler-exchange-manual database-upgrades}@anchor{26}@anchor{taler-exchange-manual id14}@anchor{27}
+@node Database upgrades,,Private key storage,Deployment
+@anchor{taler-exchange-manual database-upgrades}@anchor{2f}@anchor{taler-exchange-manual id13}@anchor{30}
 @section Database upgrades
 
 
@@ -1044,173 +1445,176 @@ being lost, which may result in significant financial liabilities as the
 exchange can then not detect double-spending. Hence this operation must
 not be performed in a production system.
 
-@node Diagnostics,,Deployment,Top
-@anchor{taler-exchange-manual diagnostics}@anchor{28}@anchor{taler-exchange-manual id15}@anchor{29}
+@menu
+* Revocations:: 
+
+@end menu
+
+@node Revocations,,,Database upgrades
+@anchor{taler-exchange-manual id14}@anchor{31}@anchor{taler-exchange-manual revocations}@anchor{32}
+@subsection Revocations
+
+
+When an exchange goes out of business or detects that the private key of
+a denomination key pair has been compromised, it may revoke some or all
+of its denomination keys. At this point, the hashes of the revoked keys
+must be returned as part of the @code{/keys} response under “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 @emph{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 Diagnostics,Benchmarking,Deployment,Top
+@anchor{taler-exchange-manual diagnostics}@anchor{33}@anchor{taler-exchange-manual id15}@anchor{34}
 @chapter Diagnostics
 
 
-This chapter includes various (very unpolished) sections on specific
-topics that might be helpful to understand how the exchange operates,
-which files should be backed up. The information may also be helpful for
-diagnostics.
+This chapter includes various sections on specific topics that might be
+helpful to understand how the exchange operates. The information may also be
+helpful for diagnostics.
 
 @menu
-* Reserve management:: 
+* Internal audits:: 
 * Database Scheme:: 
-* Signing key storage:: 
-* Denomination key storage:: 
-* Auditor signature storage:: 
 
 @end menu
 
-@node Reserve management,Database Scheme,,Diagnostics
-@anchor{taler-exchange-manual id16}@anchor{2a}@anchor{taler-exchange-manual reserve-management}@anchor{2b}
-@section Reserve management
-
-
-Incoming transactions to the exchange’s provider result in the creation
-or update of reserves, identified by their reserve key. The command line
-tool taler-exchange-reservemod allows create and add money to reserves
-in the exchange’s database.
-
-@node Database Scheme,Signing key storage,Reserve management,Diagnostics
-@anchor{taler-exchange-manual database-scheme}@anchor{2c}@anchor{taler-exchange-manual id17}@anchor{2d}
+@node Internal audits,Database Scheme,,Diagnostics
+@anchor{taler-exchange-manual internal-audit}@anchor{35}@anchor{taler-exchange-manual internal-audits}@anchor{36}
+@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 opeator 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 @strong{-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,,Internal audits,Diagnostics
+@anchor{taler-exchange-manual database-scheme}@anchor{37}@anchor{taler-exchange-manual id16}@anchor{38}
 @section Database Scheme
 
 
-The exchange database must be initialized using taler-exchange-dbinit.
+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,
-taler-exchange-dbinit has a function to garbage collect a database,
+@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 look as follows:
+The database scheme used by the exchange looks as follows:
 
 @image{taler-exchange-figures/exchange-db,,,,png}
 
-@node Signing key storage,Denomination key storage,Database Scheme,Diagnostics
-@anchor{taler-exchange-manual id18}@anchor{2e}@anchor{taler-exchange-manual signing-key-storage}@anchor{2f}
-@section Signing key storage
-
-
-The private online signing keys of the exchange are stored in a
-subdirectory “signkeys/” of the “KEYDIR” which is an option in the
-“[exchange]” section of the configuration file. The filename is the
-starting time at which the signing key can be used in microseconds since
-the Epoch. The file format is defined by the struct
-TALER_EXCHANGEDB_PrivateSigningKeyInformationP:
+@node Benchmarking,Index,Diagnostics,Top
+@anchor{taler-exchange-manual benchmarking}@anchor{39}@anchor{taler-exchange-manual exchangebenchmarking}@anchor{3a}
+@chapter Benchmarking
+
+
+This chapter describes how to run the Taler exchange benchmark.  The 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 auditor.  For the bank, both a “fakebank” (@code{-f}) and a
+“Pythonbank” deployment are currently supported.  The
+@code{taler-exchange-benchmark} program can launch all required services and
+clients, or only launch the parallel clients (@code{-m}), for example for
+distributed testing over a network.
+
+For each @emph{parallel} (@code{-p}) client, a number of @emph{reserves} (@code{-r}) is first established by
+@strong{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 @strong{withdraw} a @emph{number of coins} (@code{-n}) from the reserve and
+@strong{deposit} them. Additionally, a @emph{fraction} (@code{-R}) of the dirty coins will then be
+subject to @strong{refreshing}.  For some deposits, the auditor will receive
+@strong{deposit confirmations}.
+
+Operations that are not covered today include closing reserves, refunds and
+recoups.
+
+The existing @code{benchmark.conf} file in @code{src/benchmark/} can be used as a
+starting point for a configuration to run the benchmark. The existing
+configuration file only requires that the @code{talercheck} database already
+exists and will launch all required services locally as needed.
+
+You can run a first simple benchmark using:
+
+@cartouche
+@quotation Note 
+FIXME-TTN/CG: these instructions are incomplete and untested for the
+current iteration of the code…
+@end quotation
+@end cartouche
 
 @example
-struct TALER_EXCHANGEDB_PrivateSigningKeyInformationP @{
-   struct TALER_ExchangePrivateKeyP signkey_priv;
-   struct TALER_ExchangeSigningKeyValidityPS issue;
-@};
+$ createdb talercheck # if it does not yet exist
+$ taler-exchange-dbinit -c benchmark.conf
+$ taler-exchange-httpd -c benchmark.conf &
+$ HTTPD_PID=$!
+$ taler-exchange-offline -c benchmark.conf \
+  download sign \
+  enable-account FIXME-DETAILS-MISING-HERE \
+  wire-fee FIXME-DETAILS-MISING-HERE \
+  upload
+$ kill -TERM $HTTPD_PID
+$ taler-exchange-benchmark -c benchmark.conf -p 4 -r 1 -n 10
 @end example
 
-@node Denomination key storage,Auditor signature storage,Signing key storage,Diagnostics
-@anchor{taler-exchange-manual denomination-key-storage}@anchor{30}@anchor{taler-exchange-manual id19}@anchor{31}
-@section Denomination key storage
-
-
-The private denomination keys of the exchange are store in a
-subdirectory “denomkeys/” of the “KEYDIR” which is an option in the
-“[exchange]” section of the configuration file. “denomkeys/” contains
-further subdirectories, one per denomination. The specific name of the
-subdirectory under “denomkeys/” is ignored by the exchange. However, the
-name is important for the “taler-exchange-keyup” tool that generates the
-keys. The tool combines a human-readable encoding of the denomination
-(i.e. for EUR:1.50 the prefix would be “EUR_1_5-“, or for EUR:0.01 the
-name would be “EUR_0_01-“) with a postfix that is a truncated
-Crockford32 encoded hash of the various attributes of the denomination
-key (relative validity periods, fee structure and key size). Thus, if
-any attributes of a coin change, the name of the subdirectory will also
-change, even if the denomination remains the same.
-
-Within this subdirectory, each file represents a particular denomination
-key. The filename is the starting time at which the signing key can be
-used in microseconds since the Epoch. The format on disk begins with a
-struct TALER_EXCHANGEDB_DenominationKeyInformationP giving the
-attributes of the denomination key and the associated signature with the
-exchange’s long-term offline key:
+This will run 4 parallel clients withdrawing 10 coins from 1 reserve and then
+depositing those coins. The default refresh probability is 10 percent.  Note
+that the tiny run should only take a few seconds, most of it will be spent in
+the setup of the original key material. For meaningful runs, all three values
+should likely be increased.
 
-@example
-struct TALER_EXCHANGEDB_DenominationKeyInformationP @{
-  struct TALER_MasterSignatureP signature;
-  struct TALER_DenominationKeyValidityPS properties;
-@};
-@end example
+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.
 
-This is then followed by the variable-size RSA private key in
-libgcrypt’s S-expression format, which can be decoded using
-GNUNET_CRYPTO_rsa_private_key_decode().
+Naturally, additional instrumentation (including using features of the
+Postgres database itself) may help discover performance issues.
 
-@menu
-* Revocations:: 
+@node Index,,Benchmarking,Top
+@unnumbered Index
 
-@end menu
-
-@node Revocations,,,Denomination key storage
-@anchor{taler-exchange-manual id20}@anchor{32}@anchor{taler-exchange-manual revocations}@anchor{33}
-@subsection Revocations
 
+@printindex ge
 
-When an exchange goes out of business or detects that the private key of
-a denomination key pair has been compromised, it may revoke some or all
-of its denomination keys. At this point, the hashes of the revoked keys
-must be returned as part of the @code{/keys} response under “payback”.
-Wallets detect this, and then return unspent coins of the respective
-denomination key using the @code{/payback} API.
-
-When a denomination key is revoked, a revocation file is placed into the
-respective subdirectory of “denomkeys/”. The file has the same prefix as
-the file that stores the struct
-TALER_EXCHANGEDB_DenominationKeyInformationP information, but is
-followed by the “.rev” suffix. It contains a 64-byte EdDSA signature
-made with the master key of the exchange with purpose
-@code{TALER_SIGNATURE_MASTER_DENOMINATION_KEY_REVOKED}. If such a file is
-present, the exchange must check the signature and if it is valid treat
-the respective denomination key as revoked.
-
-Revocation files can be generated using the @code{taler-exchange-keyup}
-command-line tool using the @code{-r} option. The Taler auditor will
-instruct operators to generate revocations if it detects a key
-compromise (which is possible more coins of a particular denomination
-were deposited than issued).
-
-It should be noted that denomination key revocations should only happen
-under highly unusual (“emergency”) conditions and not under normal
-conditions.
-
-@node Auditor signature storage,,Denomination key storage,Diagnostics
-@anchor{taler-exchange-manual auditor-signature-storage}@anchor{34}@anchor{taler-exchange-manual id21}@anchor{35}
-@section Auditor signature storage
-
-
-Signatures from auditors are stored in the directory specified in the
-exchange configuration section “exchangedb” under the option
-“AUDITOR_BASE_DIR”. The exchange does not care about the specific names
-of the files in this directory.
-
-Each file must contain a header with the public key information of the
-auditor, the master public key of the exchange, and the number of signed
-denomination keys:
-
-@example
-struct AuditorFileHeaderP @{
-  struct TALER_AuditorPublicKeyP apub;
-  struct TALER_MasterPublicKeyP mpub;
-  uint32_t dki_len;
-@};
-@end example
-
-This is then followed by dki_len signatures of the auditor of type
-struct TALER_AuditorSignatureP, which are then followed by another
-dki_len blocks of type struct TALER_DenominationKeyValidityPS. The
-auditor’s signatures must be signatures over the information of the
-corresponding denomination key validity structures embedded in a struct
-TALER_ExchangeKeyValidityPS structure using the
-TALER_SIGNATURE_AUDITOR_EXCHANGE_KEYS purpose.
 
 @c %**end of body
 @bye
diff --git a/texinfo/taler-merchant-api-tutorial-figures/auditor-db.png b/texinfo/taler-merchant-api-tutorial-figures/auditor-db.png
new file mode 100644
index 00000000..3f10f3ab
--- /dev/null
+++ b/texinfo/taler-merchant-api-tutorial-figures/auditor-db.png
diff --git a/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png b/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png
index b088da04..f99e2664 100644
--- a/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png
+++ b/texinfo/taler-merchant-api-tutorial-figures/exchange-db.png
diff --git a/texinfo/taler-merchant-api-tutorial-figures/merchant-db.png b/texinfo/taler-merchant-api-tutorial-figures/merchant-db.png
new file mode 100644
index 00000000..cd5f7bd6
--- /dev/null
+++ b/texinfo/taler-merchant-api-tutorial-figures/merchant-db.png
diff --git a/texinfo/taler-merchant-api-tutorial-figures/replication.png b/texinfo/taler-merchant-api-tutorial-figures/replication.png
new file mode 100644
index 00000000..855237fc
--- /dev/null
+++ b/texinfo/taler-merchant-api-tutorial-figures/replication.png
diff --git a/texinfo/taler-merchant-api-tutorial.texi b/texinfo/taler-merchant-api-tutorial.texi
index b5db7024..fe17b35d 100644
--- a/texinfo/taler-merchant-api-tutorial.texi
+++ b/texinfo/taler-merchant-api-tutorial.texi
@@ -3,7 +3,7 @@
 @setfilename taler-merchant-api-tutorial.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 2.2.0.@*
+@*Generated by Sphinx 3.4.3.@*
 @end ifinfo
 @settitle Taler Merchant API Tutorial
 @defindex ge
@@ -21,11 +21,11 @@
 
 @copying
 @quotation
-GNU Taler 0.6.0pre1, Dec 20, 2019
+GNU Taler 0.8.0pre0, Jan 21, 2021
 
 GNU Taler team
 
-Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @end quotation
 
 @end copying
@@ -48,12 +48,32 @@ Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Hars
 
 @c %**start of body
 @anchor{taler-merchant-api-tutorial doc}@anchor{0}
+@c This file is part of GNU TALER.
+@c Copyright (C) 2014-2020 Taler Systems SA
+@c 
+@c TALER is free software; you can redistribute it and/or modify it under the
+@c terms of the GNU 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 Lesser General Public License for more details.
+@c 
+@c You should have received a copy of the GNU Lesser General Public License along with
+@c TALER; see the file COPYING.  If not, see <http://www.gnu.org/licenses/>
+@c 
+@c @author Marcello Stanisci
+@c @author Florian Dold
+@c @author Christian Grothoff
+
 @menu
 * Introduction:: 
-* Accepting a Simple Payment:: 
+* Merchant Payment Processing:: 
 * Giving Refunds:: 
+* Repurchase detection and fulfillment URLs:: 
 * Giving Customers Tips:: 
 * Advanced topics:: 
+* Index:: 
 
 @detailmenu
  --- The Detailed Node Listing ---
@@ -66,29 +86,22 @@ Introduction
 * Public Sandbox Backend and Authentication:: 
 * Merchant Instances:: 
 
-Accepting a Simple Payment
+Merchant Payment Processing
 
 * Creating an Order for a Payment:: 
 * Checking Payment Status and Prompting for Payment:: 
 
 Advanced topics
 
-* Detecting the Presence of the Taler Wallet:: 
-* Integration with the Back Office:: 
 * Session-Bound Payments:: 
 * Product Identification:: 
 * The Taler Order Format:: 
 
-Detecting the Presence of the Taler Wallet
-
-* Presence detection without JavaScript:: 
-* Detection with JavaScript:: 
-
 @end detailmenu
 @end menu
 
-@node Introduction,Accepting a Simple Payment,Top,Top
-@anchor{taler-merchant-api-tutorial gnu-taler-merchant-api-tutorial}@anchor{1}@anchor{taler-merchant-api-tutorial introduction}@anchor{2}
+@node Introduction,Merchant Payment Processing,Top,Top
+@anchor{taler-merchant-api-tutorial gnu-taler-merchant-api-tutorial}@anchor{1}@anchor{taler-merchant-api-tutorial introduction}@anchor{2}@anchor{taler-merchant-api-tutorial merchant-api-tutorial}@anchor{3}
 @chapter Introduction
 
 
@@ -102,7 +115,7 @@ Detecting the Presence of the Taler Wallet
 @end menu
 
 @node About GNU Taler,About this tutorial,,Introduction
-@anchor{taler-merchant-api-tutorial about-gnu-taler}@anchor{3}
+@anchor{taler-merchant-api-tutorial about-gnu-taler}@anchor{4}
 @section About GNU Taler
 
 
@@ -116,12 +129,16 @@ know-your-customer (KYC) regulation, as well as data protection
 regulation (such as GDPR).
 
 @node About this tutorial,Architecture overview,About GNU Taler,Introduction
-@anchor{taler-merchant-api-tutorial about-this-tutorial}@anchor{4}
+@anchor{taler-merchant-api-tutorial about-this-tutorial}@anchor{5}
 @section About this tutorial
 
 
-This tutorial addresses how to process payments using the GNU Taler
-merchant Backend. This chapter explains some basic concepts. In the
+This tutorial addresses how to process payments using the GNU Taler merchant
+Backend.  The audience for this tutorial are @emph{developers} of merchants (such
+as Web shops) that are working on integrating GNU Taler with the
+customer-facing Frontend and the staff-facing Backoffice.
+
+This chapter explains some basic concepts. In the
 second chapter, you will learn how to do basic payments.
 
 This version of the tutorial has examples for Python3. It uses the
@@ -134,42 +151,53 @@ If you want to look at some simple, running examples, check out these:
 @itemize -
 
 @item 
-The essay merchant@footnote{https://git.taler.net/blog.git/tree/talerblog/blog/blog.py}
+The essay merchant@footnote{https://git.taler.net/taler-merchant-demos.git/tree/talermerchantdemos/blog}
 that sells single chapters of a book.
 
 @item 
-The donation page@footnote{https://git.taler.net/donations.git/tree/talerdonations/donations/donations.py}
+The donation page@footnote{https://git.taler.net/taler-merchant-demos.git/tree/talermerchantdemos/donations}
 that accepts donations for software projects and gives donation
 receipts.
 
 @item 
 The
-survey@footnote{https://git.taler.net/survey.git/tree/talersurvey/survey/survey.py}
+survey@footnote{https://git.taler.net/taler-merchant-demos.git/tree/talermerchantdemos/survey}
 that gives users who answer a question a small reward.
+
+@item 
+The WooCommerce plugin@footnote{https://git.taler.net/gnu-taler-payment-for-woocommerce.git/}
+which is a comprehensive integration into a Web shop including the refund business
+process.
 @end itemize
 
 @node Architecture overview,Public Sandbox Backend and Authentication,About this tutorial,Introduction
-@anchor{taler-merchant-api-tutorial architecture-overview}@anchor{5}
+@anchor{taler-merchant-api-tutorial architecture-overview}@anchor{6}
 @section Architecture overview
 
 
 The Taler software stack for a merchant consists of the following main
 components:
 
+@geindex frontend
+
 
 @itemize -
 
 @item 
-frontend
 A frontend which interacts with the customer’s browser. The frontend
 enables the customer to build a shopping cart and place an order.
 Upon payment, it triggers the respective business logic to satisfy
 the order. This component is not included with Taler, but rather
 assumed to exist at the merchant. This tutorial describes how to
 develop a Taler frontend.
+@end itemize
+
+@geindex backend
+
+
+@itemize -
 
 @item 
-backend
 A Taler-specific payment backend which makes it easy for the frontend
 to process financial transactions with Taler. For this tutorial, you
 will use a public sandbox backend. For production use, you must
@@ -180,9 +208,7 @@ you.
 The following image illustrates the various interactions of these key
 components:
 
-
-@image{taler-merchant-api-tutorial-figures/arch-api,,,image0,png}
-
+@image{taler-merchant-api-tutorial-figures/arch-api,,,,png}
 
 The backend provides the cryptographic protocol support, stores
 Taler-specific financial information and communicates with the GNU Taler
@@ -192,19 +218,22 @@ with the exchange, and also does not deal with sensitive data. In
 particular, the merchant’s signing keys and bank account information are
 encapsulated within the Taler backend.
 
-Some functionality of the backend (the “public interface“) is also
-exposed to the customer’s browser directly. In the HTTP API, all public
-endpoints are prefixed with @code{/public/}.
+Some functionality of the backend (the “public interface“) is exposed to the
+customer’s browser directly. In the HTTP API, all private endpoints (for the
+Backoffice) are prefixed with @code{/private/}.  This tutorial focuses on the
+@code{/private/} endpoints. The public interface is directly used by the wallet
+and not relevant for the merchant (other than that the API must be exposed).
+
+@geindex sandbox
+@geindex authorization
 
 @node Public Sandbox Backend and Authentication,Merchant Instances,Architecture overview,Introduction
-@anchor{taler-merchant-api-tutorial public-sandbox-backend-and-authentication}@anchor{6}
+@anchor{taler-merchant-api-tutorial public-sandbox-backend-and-authentication}@anchor{7}
 @section Public Sandbox Backend and Authentication
 
 
-sandbox
-authorization
 How the frontend authenticates to the Taler backend depends on the
-configuration. See Taler Merchant Operating Manual.
+configuration. See taler-merchant-manual.
 
 The public sandbox backend @indicateurl{https://backend.demo.taler.net/} uses an API
 key in the @code{Authorization} header. The value of this header must be
@@ -225,12 +254,13 @@ The sandbox backend @indicateurl{https://backend.demo.taler.net/} uses @code{KUD
 imaginary currency. Coins denominated in @code{KUDOS} can be withdrawn from
 @indicateurl{https://bank.demo.taler.net/}.
 
+@geindex instance
+
 @node Merchant Instances,,Public Sandbox Backend and Authentication,Introduction
-@anchor{taler-merchant-api-tutorial merchant-instances}@anchor{7}
+@anchor{taler-merchant-api-tutorial merchant-instances}@anchor{8}
 @section Merchant Instances
 
 
-instance
 The same Taler merchant backend server can be used by multiple separate
 merchants that are separate business entities. Each of these separate
 business entities is called a @emph{merchant instance}, and is identified by
@@ -244,45 +274,58 @@ The following merchant instances are configured on
 @itemize -
 
 @item 
-@code{GNUnet} (The GNUnet project)
+@code{GNUnet} (The GNUnet project), reachable at @indicateurl{https://backend.demo.taler.net/instances/gnunet/}
 
 @item 
-@code{FSF} (The Free Software Foundation)
+@code{FSF} (The Free Software Foundation), reachable at @indicateurl{https://backend.demo.taler.net/instances/fsf/}
 
 @item 
-@code{Tor} (The Tor Project)
+@code{Tor} (The Tor Project), reachable at @indicateurl{https://backend.demo.taler.net/instances/tor/}
 
 @item 
-@code{default} (Kudos Inc.)
+@code{default} (Kudos Inc.), reachable at @indicateurl{https://backend.demo.taler.net/}
 @end itemize
 
-Note that these are fictional merchants used for our demonstrators and
+@cartouche
+@quotation Note 
+These are fictional merchants used for our demonstrators and
 not affiliated with or officially approved by the respective projects.
+@end quotation
+@end cartouche
+
+All endpoints for instances offer the same API. Thus, which instance is
+to be used is simply included in the base URL of the merchant backend.
 
-@node Accepting a Simple Payment,Giving Refunds,Introduction,Top
-@anchor{taler-merchant-api-tutorial accepting-a-simple-payment}@anchor{8}@anchor{taler-merchant-api-tutorial id1}@anchor{9}
-@chapter Accepting a Simple Payment
+@node Merchant Payment Processing,Giving Refunds,Introduction,Top
+@anchor{taler-merchant-api-tutorial id1}@anchor{9}@anchor{taler-merchant-api-tutorial merchant-payment-processing}@anchor{a}
+@chapter Merchant Payment Processing
 
 
+@geindex order
+
 @menu
 * Creating an Order for a Payment:: 
 * Checking Payment Status and Prompting for Payment:: 
 
 @end menu
 
-@node Creating an Order for a Payment,Checking Payment Status and Prompting for Payment,,Accepting a Simple Payment
-@anchor{taler-merchant-api-tutorial creating-an-order-for-a-payment}@anchor{a}
+@node Creating an Order for a Payment,Checking Payment Status and Prompting for Payment,,Merchant Payment Processing
+@anchor{taler-merchant-api-tutorial creating-an-order-for-a-payment}@anchor{b}
 @section Creating an Order for a Payment
 
 
-order
 Payments in Taler revolve around an @emph{order}, which is a machine-readable
 description of the business transaction for which the payment is to be
 made. Before accepting a Taler payment as a merchant you must create
 such an order.
 
-This is done by posting a JSON object to the backend’s @code{/order} API
-endpoint. At least the following fields must be given:
+This is done by POSTing a JSON object to the backend’s @code{/private/orders} API
+endpoint. At least the following fields must be given inside the @code{order}
+field:
+
+@geindex summary
+
+@geindex fulfillment URL
 
 
 @itemize -
@@ -305,60 +348,94 @@ automatically appends the @code{order_id} as a query parameter, as well
 as the @code{session_sig} for session-bound payments (discussed later).
 @end itemize
 
-Orders can have many more fields, see @ref{b,,The Taler Order Format}.
+Orders can have many more fields, see @ref{c,,The Taler Order Format}.  When POSTing an order,
+you can also specify additional details such as an override
+for the refund duration and instructions for inventory
+management. These are rarely needed and not covered in this
+tutorial; please read the core/api-merchant reference
+manual for details.
 
-After successfully @code{POST}ing to @code{/order}, an @code{order_id} will be
-returned. Together with the merchant @code{instance}, the order id uniquely
-identifies the order within a merchant backend.
+A minimal Python snippet for creating an order would look like this:
 
 @example
 >>> import requests
->>> order = dict(order=dict(amount="KUDOS:10",
-...                         summary="Donation",
-...                         fulfillment_url="https://example.com/thanks.html"))
->>> order_resp = requests.post("https://backend.demo.taler.net/order", json=order,
+>>> body = dict(order=dict(amount="KUDOS:10",
+...                        summary="Donation",
+...                        fulfillment_url="https://example.com/thanks.html"),
+...             create_token=false)
+>>> response = requests.post("https://backend.demo.taler.net/private/order",
+...               json=body,
 ...               headers=@{"Authorization": "ApiKey sandbox"@})
 <Response [200]>
 @end example
 
+@geindex claim token
+
 The backend will fill in some details missing in the order, such as the
 address of the merchant instance. The full details are called the
-@emph{contract terms}. contract terms
+@emph{contract terms}.
+
+@geindex contract terms
+
+@cartouche
+@quotation Note 
+The above request disables the use of claim tokens by setting the
+@code{create_token} option to @code{false}.  If you need claim tokens,
+you must adjust the code to construct the @code{taler://pay/} URI
+given below to include the claim token.
+@end quotation
+@end cartouche
 
-@node Checking Payment Status and Prompting for Payment,,Creating an Order for a Payment,Accepting a Simple Payment
-@anchor{taler-merchant-api-tutorial checking-payment-status-and-prompting-for-payment}@anchor{c}
+After successfully @code{POST}ing to @code{/private/orders}, an @code{order_id} will be
+returned. Together with the merchant @code{instance}, the order id uniquely
+identifies the order within a merchant backend.  Using the order ID, you
+can trivially construct the respective @code{taler://pay/} URI that must
+be provided to the wallet.  Let @code{example.com} be the domain name where
+the public endpoints of the instance are reachable. The Taler pay URI is
+then simply @code{taler://pay/example.com/$ORDER_ID/} where @code{$ORDER_ID}
+must be replaced with the ID of the order that was returned.
+
+You can put the @code{taler://} URI as the target of a link to open the Taler
+wallet via the @code{taler://} schema, or put it into a QR code.  However, for a
+Web shop, the easiest way is to simply redirect the browser to
+@code{https://example.com/orders/$ORDER_ID/}.  That page will then trigger the
+Taler wallet. Here the backend generates the right logic to trigger the
+wallet, supporting the various types of Taler wallets in existence.  Instead
+of constructing the above URL by hand, it is best to obtain it by checking for
+the payment status as described in the next section.
+
+@node Checking Payment Status and Prompting for Payment,,Creating an Order for a Payment,Merchant Payment Processing
+@anchor{taler-merchant-api-tutorial checking-payment-status-and-prompting-for-payment}@anchor{d}
 @section Checking Payment Status and Prompting for Payment
 
 
-The status of a payment can be checked with the @code{/check-payment}
-endpoint. If the payment is yet to be completed by the customer,
-@code{/check-payment} will give the frontend a URL (the
-payment_redirect_url) that will trigger the customer’s wallet to execute
-the payment.
+Given the order ID, the status of a payment can be checked with the
+@code{/private/orders/$ORDER_ID/} endpoint. If the payment is yet to be completed
+by the customer, @code{/private/orders/$ORDER_ID} will give the frontend a URL
+(under the name @code{payment_redirect_url}) that will trigger the customer’s
+wallet to execute the payment. This is basically the
+@code{https://example.com/orders/$ORDER_ID/} URL we discussed above.
 
-Note that the only way to obtain the payment_redirect_url is to check
-the status of the payment, even if you know that the user did not pay
-yet.
+Note that the best way to obtain the @code{payment_redirect_url} is to check the
+status of the payment, even if you know that the user did not pay yet.  There
+are a few corner cases to consider when constructing this URL, so asking the
+backend to do it is the safest method.
 
 @example
 >>> import requests
->>> r = requests.get("https://backend.demo.taler.net/check-payment",
-...                  params=dict(order_id=order_resp.json()["order_id"]),
+>>> r = requests.get("https://backend.demo.taler.net/private/orders/" + order_id,
 ...                  headers=@{"Authorization": "ApiKey sandbox"@})
 >>> print(r.json())
 @end example
 
-If the paid field in the response is @code{true}, the other fields in the
-response will be different. Once the payment was completed by the user,
-the response will contain the following fields:
+If the @code{order_status} field in the response is @code{paid}, you will not
+get a @code{payment_redirect_url} and instead information about the
+payment status, including:
 
 
 @itemize -
 
 @item 
-paid: Set to true.
-
-@item 
 contract_terms: The full contract terms of the order.
 
 @item 
@@ -367,22 +444,29 @@ this purchase.
 
 @item 
 refunded_amount: Amount that was refunded
-
-@item 
-last_session_id: Last session ID used by the customer’s wallet. See
-@ref{d,,Session-Bound Payments}.
 @end itemize
 
 Once the frontend has confirmed that the payment was successful, it
 usually needs to trigger the business logic for the merchant to fulfill
 the merchant’s obligations under the contract.
 
-@node Giving Refunds,Giving Customers Tips,Accepting a Simple Payment,Top
-@anchor{taler-merchant-api-tutorial giving-refunds}@anchor{e}@anchor{taler-merchant-api-tutorial id2}@anchor{f}
+@cartouche
+@quotation Note 
+You do not need to keep querying to notice changes
+to the order’s transaction status.  The endpoint
+support long polling, simply specify a @code{timeout_ms}
+query parameter with how long you want to wait at most
+for the order status to change to @code{paid}.
+@end quotation
+@end cartouche
+@anchor{taler-merchant-api-tutorial giving-refunds}@anchor{e}
+@geindex refunds
+
+@node Giving Refunds,Repurchase detection and fulfillment URLs,Merchant Payment Processing,Top
+@anchor{taler-merchant-api-tutorial id2}@anchor{f}
 @chapter Giving Refunds
 
 
-refunds
 A refund in GNU Taler is a way to “undo” a payment. It needs to be
 authorized by the merchant. Refunds can be for any fraction of the
 original amount paid, but they cannot exceed the original payment.
@@ -393,20 +477,14 @@ order. The default value for this refund deadline is specified in the
 configuration of the merchant’s backend.
 
 The frontend can instruct the merchant backend to authorize a refund by
-@code{POST}ing to the @code{/refund} endpoint.
+@code{POST}ing to the @code{/private/orders/$ORDER_ID/refund} endpoint.
 
-The refund request JSON object has the following fields:
+The refund request JSON object has only two fields:
 
 
 @itemize -
 
 @item 
-order_id: Identifies for which order a customer should be refunded.
-
-@item 
-instance: Merchant instance to use.
-
-@item 
 refund: Amount to be refunded. If a previous refund was authorized
 for the same order, the new amount must be higher, otherwise the
 operation has no effect. The value indicates the total amount to be
@@ -418,7 +496,7 @@ only used by the Back Office and is not exposed to the customer.
 @end itemize
 
 If the request is successful (indicated by HTTP status code 200), the
-response includes a @code{refund_redirect_url}. The frontend must redirect
+response includes a @code{taler_refund_uri}. The frontend must redirect
 the customer’s browser to that URL to allow the refund to be processed
 by the wallet.
 
@@ -426,21 +504,79 @@ This code snipped illustrates giving a refund:
 
 @example
 >>> import requests
->>> refund_req = dict(order_id="2018.058.21.46.06-024C85K189H8P",
-...                   refund="KUDOS:10",
-...                   instance="default",
+>>> refund_req = dict(refund="KUDOS:10",
 ...                   reason="Customer did not like the product")
->>> requests.post("https://backend.demo.taler.net/refund", json=refund_req,
-...              headers=@{"Authorization": "ApiKey sandbox"@})
+>>> requests.post("https://backend.demo.taler.net/private/orders/"
+...               + order_id + "/refund", json=refund_req,
+...               headers=@{"Authorization": "ApiKey sandbox"@})
 <Response [200]>
 @end example
 
-@node Giving Customers Tips,Advanced topics,Giving Refunds,Top
-@anchor{taler-merchant-api-tutorial giving-customers-tips}@anchor{10}@anchor{taler-merchant-api-tutorial id3}@anchor{11}
+@cartouche
+@quotation Note 
+After granting a refund, the public
+@code{https://example.com/orders/$ORDER_ID/} endpoint will
+change its wallet interaction from requesting payment to
+offering a refund.  Thus, frontends may again redirect
+browsers to this endpoint.  However, to do so, a
+@code{h_contract} field must be appended
+(@code{?h_contract=$H_CONTRACT}) as the public endpoint requires
+it to authenticate the client.  The required
+@code{$H_CONTRACT} value is returned in the refund response
+under the @code{h_contract} field.
+@end quotation
+@end cartouche
+
+@geindex repurchase
+
+@node Repurchase detection and fulfillment URLs,Giving Customers Tips,Giving Refunds,Top
+@anchor{taler-merchant-api-tutorial repurchase}@anchor{10}@anchor{taler-merchant-api-tutorial repurchase-detection-and-fulfillment-urls}@anchor{11}
+@chapter Repurchase detection and fulfillment URLs
+
+
+A possible problem for merchants selling access to digital articles
+is that a customer may have paid for an article on one device, but
+may then want to read it on a different device, possibly one that
+does not even have a Taler wallet installed.
+
+Naturally, at this point the customer would at first still be prompted to pay
+for the article again. If the customer then opens the @code{taler://} link in the
+wallet that did previously pay for the article (for example by scanning the QR
+code on the desktop with the Android App), the wallet will claim the contract,
+detect that the fulfillment URL is identical to one that it already has made a
+payment for in the past, and initiate @strong{repurchase redirection}: Here, the
+wallet will contact the merchant and replay the previous payment, except this
+time using the (current) session ID of the browser (it learns the session ID
+from the QR code).
+
+The merchant backend then updates the session ID of the existing order to
+the current session ID of the browser.  When the payment status for the
+“new” unpaid order is checked (or already in long-polling), the backend
+detects that for the browser’s @emph{session ID} and @emph{fulfillment URL} there is an
+existing paid contract. It then tells the browser to immediately redirect to
+the fulfillment URL where the already paid article is available.
+
+To ensure this mechanism works as designed, merchants must make sure to not
+use the same fulfillment URL for different products or for physical products
+where customers may be expected to buy the article repeatedly.  Similarly,
+it is crucial that merchants consistently use the same fulfillment URL for
+the same digital product where repurchase detection is desired.
+
+Note that changing the session ID to a different device requires the
+involvement of the wallet that made the payment, thus reasonably limiting the
+possibility of broadly sharing the digital purchases.  Repurchase detection is
+also @emph{only} done for HTTP(S) fulfillment URLs. In particular, this means
+fulfillment URIs like “taler://fulfillment-success/$MESSAGE” are not
+considered to identify a resource you can pay for and thus do not have to be
+unique.
+@anchor{taler-merchant-api-tutorial giving-customers-tips}@anchor{12}
+@geindex tips
+
+@node Giving Customers Tips,Advanced topics,Repurchase detection and fulfillment URLs,Top
+@anchor{taler-merchant-api-tutorial id4}@anchor{13}
 @chapter Giving Customers Tips
 
 
-tips
 GNU Taler allows Web sites to grant small amounts directly to the
 visitor. The idea is that some sites may want incentivize actions such
 as filling out a survey or trying a new feature. It is important to note
@@ -475,7 +611,7 @@ amount: Amount that should be given to the visitor as a tip.
 
 @item 
 instance: Merchant instance that grants the tip (each instance may
-have its own independend tipping funds configured).
+have its own independent tipping funds configured).
 
 @item 
 justification: Description of why the tip was granted. Human-readable
@@ -503,158 +639,32 @@ This code snipped illustrates giving a tip:
 <Response [200]>
 @end example
 
-@node Advanced topics,,Giving Customers Tips,Top
-@anchor{taler-merchant-api-tutorial advanced-topics}@anchor{12}@anchor{taler-merchant-api-tutorial id4}@anchor{13}
+@node Advanced topics,Index,Giving Customers Tips,Top
+@anchor{taler-merchant-api-tutorial advanced-topics}@anchor{14}@anchor{taler-merchant-api-tutorial id6}@anchor{15}
 @chapter Advanced topics
 
 
 @menu
-* Detecting the Presence of the Taler Wallet:: 
-* Integration with the Back Office:: 
 * Session-Bound Payments:: 
 * Product Identification:: 
 * The Taler Order Format:: 
 
 @end menu
 
-@node Detecting the Presence of the Taler Wallet,Integration with the Back Office,,Advanced topics
-@anchor{taler-merchant-api-tutorial detecting-the-presence-of-the-taler-wallet}@anchor{14}@anchor{taler-merchant-api-tutorial id5}@anchor{15}
-@section Detecting the Presence of the Taler Wallet
-
-
-Taler offers ways to detect whether a user has the wallet installed in
-their browser. This allows Web sites to adapt accordingly. Note that not
-all platforms can do presence detection reliably. Some platforms might
-have a Taler wallet installed as a separate App instead of using a Web
-extension. In these cases, presence detection will fail. Thus, sites may
-want to allow users to request Taler payments even if a wallet could not
-be detected, especially for visitors using mobiles.
-
-@menu
-* Presence detection without JavaScript:: 
-* Detection with JavaScript:: 
-
-@end menu
-
-@node Presence detection without JavaScript,Detection with JavaScript,,Detecting the Presence of the Taler Wallet
-@anchor{taler-merchant-api-tutorial presence-detection-without-javascript}@anchor{16}
-@subsection Presence detection without JavaScript
-
-
-Presence detection without JavaScript is based on CSS classes. You can
-hide or show elements selectively depending on whether the wallet is
-detected or not.
-
-In order to work correctly, a special fallback stylesheet must be
-included that will be used when the wallet is not present. The
-stylesheet can be put into any file, but must be included via a @code{link}
-tag with the @code{id} attribute set to @code{taler-presence-stylesheet}. If a
-wallet is present, it will “hijack” this stylesheet to change how
-elements with the following classes are rendered:
-
-The following CSS classes can be used:
-
-
-@table @asis
-
-@item @code{taler-installed-hide}
-
-A CSS rule will set the @code{display} property for this class to
-@code{none} once the Taler wallet is installed and enabled. If the
-wallet is not installed, @code{display} will be @code{inherit}.
-
-@item @code{taler-installed-show}
-
-A CSS rule will set the @code{display} property for this class to
-@code{inherit} once the Taler wallet is installed and enabled. If the
-wallet is not installed, @code{display} will be @code{none}.
-@end table
-
-The following is a complete example:
-
-@example
-<!DOCTYPE html>
-<html data-taler-nojs="true">
-  <head>
-    <title>Tutorial</title>
-    <link rel="stylesheet"
-          type="text/css"
-          href="/web-common/taler-fallback.css"
-          id="taler-presence-stylesheet" />
-  </head>
-  <body>
-    <p class="taler-installed-hide">
-      No wallet found.
-    </p>
-    <p class="taler-installed-show">
-      Wallet found!
-    </p>
-  </body>
-</html>
-@end example
-
-The @code{taler-fallback.css} is part of the Taler’s @emph{web-common}
-repository, available at
-@indicateurl{https://git.taler.net/web-common.git/tree/taler-fallback.css}. You may
-have to adjust the @code{href} attribute in the HTML code above to point to
-the correct location of the @code{taler-fallback.css} file on your Web
-site.
-
-@node Detection with JavaScript,,Presence detection without JavaScript,Detecting the Presence of the Taler Wallet
-@anchor{taler-merchant-api-tutorial detection-with-javascript}@anchor{17}
-@subsection Detection with JavaScript
-
-
-The following functions are defined in the @code{taler} namespace of the
-@code{taler-wallet-lib} helper library available at
-@indicateurl{https://git.taler.net/web-common.git/tree/taler-wallet-lib.js}.
-
-
-@table @asis
-
-@item @code{onPresent(callback: () => void)}
-
-Adds a callback to be called when support for Taler payments is
-detected.
-
-@item @code{onAbsent(callback: () => void)}
-
-Adds a callback to be called when support for Taler payments is
-disabled.
-@end table
-
-Note that the registered callbacks may be called more than once. This
-may happen if a user disables or enables the wallet in the browser’s
-extension settings while a shop’s frontend page is open.
-
-@node Integration with the Back Office,Session-Bound Payments,Detecting the Presence of the Taler Wallet,Advanced topics
-@anchor{taler-merchant-api-tutorial id6}@anchor{18}@anchor{taler-merchant-api-tutorial integration-with-the-back-office}@anchor{19}
-@section Integration with the Back Office
-
-
-Taler ships a Back Office application as a stand-alone Web application.
-The Back Office has its own documentation at
-@indicateurl{https://docs.taler.net/backoffice/html/manual.html}.
-
-Developers wishing to tightly integrate back office support for
-Taler-based payments into an existing back office application should
-focus on the wire transfer tracking and transaction history sections of
-the Taler Backend API specification at
-@indicateurl{https://docs.taler.net/api/api-merchant.html}
-
-@node Session-Bound Payments,Product Identification,Integration with the Back Office,Advanced topics
-@anchor{taler-merchant-api-tutorial session-002dbound-payments}@anchor{1a}@anchor{taler-merchant-api-tutorial session-bound-payments}@anchor{1b}
+@node Session-Bound Payments,Product Identification,,Advanced topics
+@anchor{taler-merchant-api-tutorial session-002dbound-payments}@anchor{16}@anchor{taler-merchant-api-tutorial session-bound-payments}@anchor{17}
 @section Session-Bound Payments
 
 
-session
+@geindex session
+
 Sometimes checking if an order has been paid for is not enough. For
 example, when selling access to online media, the publisher may want to
 be paid for exactly the same product by each customer. Taler supports
 this model by allowing the mechant to check whether the “payment
 receipt” is available on the user’s current device. This prevents users
 from easily sharing media access by transmitting a link to the
-fulfillment page. Of course sophisticated users could share payment
+fulfillment page. Of course, sophisticated users could share payment
 receipts as well, but this is not as easy as sharing a link, and in this
 case they are more likely to just share the media directly.
 
@@ -663,25 +673,28 @@ browser an ephemeral @code{session_id}, usually via a session cookie. When
 executing or re-playing a payment, the wallet will receive an additional
 signature (@code{session_sig}). This signature certifies that the wallet
 showed a payment receipt for the respective order in the current
-session. cookie
+session.
+
+@geindex cookie
 
-Session-bound payments are triggerd by passing the @code{session_id}
+Session-bound payments are triggered by passing the @code{session_id}
 parameter to the @code{/check-payment} endpoint. The wallet will then
 redirect to the fulfillment page, but include an additional
 @code{session_sig} parameter. The frontend can query @code{/check-payment}
 with both the @code{session_id} and the @code{session_sig} to verify that the
 signature is correct.
 
-The last session ID that was successfuly used to prove that the payment
+The last session ID that was successfully used to prove that the payment
 receipt is in the user’s wallet is also available as @code{last_session_id}
 in the response to @code{/check-payment}.
 
 @node Product Identification,The Taler Order Format,Session-Bound Payments,Advanced topics
-@anchor{taler-merchant-api-tutorial id7}@anchor{1c}@anchor{taler-merchant-api-tutorial product-identification}@anchor{1d}
+@anchor{taler-merchant-api-tutorial id8}@anchor{18}@anchor{taler-merchant-api-tutorial product-identification}@anchor{19}
 @section Product Identification
 
 
-resource url
+@geindex resource url
+
 In some situations the user may have paid for some digital good, but the
 frontend does not know the exact order ID, and thus cannot instruct the
 wallet to reveil the existing payment receipt. This is common for simple
@@ -697,7 +710,7 @@ contract with the same @code{resource_url} before, and if so replay the
 previous payment.
 
 @node The Taler Order Format,,Product Identification,Advanced topics
-@anchor{taler-merchant-api-tutorial id8}@anchor{1e}@anchor{taler-merchant-api-tutorial the-taler-order-format}@anchor{1f}
+@anchor{taler-merchant-api-tutorial id9}@anchor{1a}@anchor{taler-merchant-api-tutorial the-taler-order-format}@anchor{1b}
 @section The Taler Order Format
 
 
@@ -707,68 +720,107 @@ describes each of the fields in depth.
 Financial amounts are always specified as a string in the format
 @code{"CURRENCY:DECIMAL_VALUE"}.
 
+@geindex amount
+
 
 @table @asis
 
 @item amount
 
-amount
 Specifies the total amount to be paid to the merchant by the
 customer.
+@end table
+
+@geindex fees
+
+@geindex maximum deposit fee
+
+
+@table @asis
 
 @item max_fee
 
-fees
-maximum deposit fee
 This is the maximum total amount of deposit fees that the merchant is
 willing to pay. If the deposit fees for the coins exceed this amount,
 the customer has to include it in the payment total. The fee is
-specified using the same triplet used for amount.
+specified using the same triplet used for @code{amount}.
+@end table
+
+@geindex fees
+
+@geindex maximum wire fee
+
+
+@table @asis
 
 @item max_wire_fee
 
-fees
-maximum wire fee
 Maximum wire fee accepted by the merchant (customer share to be
-divided by the ’wire_fee_amortization’ factor, and further reduced if
-deposit fees are below ’max_fee’). Default if missing is zero.
+divided by the @code{wire_fee_amortization} factor, and further reduced if
+deposit fees are below @code{max_fee}). Default if missing is zero.
+@end table
+
+@geindex fees
+
+@geindex maximum fee amortization
+
+
+@table @asis
 
 @item wire_fee_amortization
 
-fees
-maximum fee amortization
 Over how many customer transactions does the merchant expect to
 amortize wire fees on average? If the exchange’s wire fee is above
-’max_wire_fee’, the difference is divided by this number to compute
+@code{max_wire_fee}, the difference is divided by this number to compute
 the expected customer’s contribution to the wire fee. The customer’s
 contribution may further be reduced by the difference between the
-’max_fee’ and the sum of the actual deposit fees. Optional, default
-value if missing is 1. 0 and negative values are invalid and also
+@code{max_fee} and the sum of the actual deposit fees. Optional, default
+value if missing is 1. Zero and negative values are invalid and also
 interpreted as 1.
+@end table
+
+@geindex pay_url
+
+
+@table @asis
 
 @item pay_url
 
-pay_url
 Which URL accepts payments. This is the URL where the wallet will
 POST coins.
+@end table
+
+@geindex fulfillment URL
+
+
+@table @asis
 
 @item fulfillment_url
 
-fulfillment URL
 Which URL should the wallet go to for obtaining the fulfillment, for
 example the HTML or PDF of an article that was bought, or an order
 tracking system for shipments, or a simple human-readable Web page
 indicating the status of the contract.
+@end table
+
+@geindex order ID
+
+
+@table @asis
 
 @item order_id
 
-order ID
 Alphanumeric identifier, freely definable by the merchant. Used by
 the merchant to uniquely identify the transaction.
+@end table
+
+@geindex summary
+
+
+@table @asis
 
 @item summary
 
-summary
 Short, human-readable summary of the contract. To be used when
 displaying the contract in just one line, for example in the
 transaction history of the customer.
@@ -776,31 +828,46 @@ transaction history of the customer.
 @item timestamp
 
 Time at which the offer was generated.
+@end table
+
+@geindex payment deadline
+
+
+@table @asis
 
 @item pay_deadline
 
-payment deadline
 Timestamp of the time by which the merchant wants the exchange to
 definitively wire the money due from this contract. Once this
 deadline expires, the exchange will aggregate all deposits where the
-contracts are past the refund_deadline and execute one large wire
+contracts are past the @code{refund_deadline} and execute one large wire
 payment for them. Amounts will be rounded down to the wire transfer
 unit; if the total amount is still below the wire transfer unit, it
 will not be disbursed.
+@end table
+
+@geindex refund deadline
+
+
+@table @asis
 
 @item refund_deadline
 
-refund deadline
 Timestamp until which the merchant willing (and able) to give refunds
 for the contract using Taler. Note that the Taler exchange will hold
 the payment in escrow at least until this deadline. Until this time,
 the merchant will be able to sign a message to trigger a refund to
 the customer. After this time, it will no longer be possible to
-refund the customer. Must be smaller than the pay_deadline.
+refund the customer. Must be smaller than the @code{pay_deadline}.
+@end table
+
+@geindex product description
+
+
+@table @asis
 
 @item products
 
-product description
 Array of products that are being sold to the customer. Each entry
 contains a tuple with the following values:
 
@@ -813,13 +880,13 @@ Description of the product.
 
 @item quantity
 
-Quantity of the items to be shipped. May specify a unit (@code{1 kg})
+Quantity of the items to be shipped. May specify a unit (e.g. @code{1 kg})
 or just the count.
 
 @item price
 
 Price for quantity units of this product shipped to the given
-delivery_location. Note that usually the sum of all of the prices
+@code{delivery_location}. Note that usually the sum of all of the prices
 should add up to the total amount of the contract, but it may be
 different due to discounts or because individual prices are
 unavailable.
@@ -865,7 +932,7 @@ fulfillment URI, there is no delivery location.
 
 @item address
 
-This should give a label in the locations map, specifying where
+This should give a label in the @code{locations} map, specifying where
 the merchant is located.
 
 @item name
@@ -875,13 +942,18 @@ business.
 
 @item jurisdiction
 
-This should give a label in the locations map, specifying the
+This should give a label in the @code{locations} map, specifying the
 jurisdiction under which this contract is to be arbitrated.
 @end table
+@end table
+
+@geindex location
+
+
+@table @asis
 
 @item locations
 
-location
 Associative map of locations used in the contract. Labels for
 locations in this map can be freely chosen and used whenever a
 location is required in other parts of the contract. This way, if the
@@ -893,14 +965,18 @@ non-exhaustive list of location attributes is the following:
 
 @table @asis
 
+@item name
+
+Receiver name for delivery, either business or person name.
+
 @item country
 
 Name of the country for delivery, as found on a postal package,
-i.e. “France”.
+e.g. “France”.
 
 @item state
 
-Name of the state for delivery, as found on a postal package, i.e.
+Name of the state for delivery, as found on a postal package, e.g.
 “NY”.
 
 @item region
@@ -915,7 +991,7 @@ Name of the province for delivery, as found on a postal package.
 
 Name of the city for delivery, as found on a postal package.
 
-@item ZIP code
+@item zip_code
 
 ZIP code for delivery, as found on a postal package.
 
@@ -923,23 +999,30 @@ ZIP code for delivery, as found on a postal package.
 
 Street name for delivery, as found on a postal package.
 
-@item street number
+@item street_number
 
 Street number (number of the house) for delivery, as found on a
 postal package.
 @end table
+@end table
 
-name receiver name for delivery, either business or person name.
-
-Note that locations are not required to specify all of these fields,
+@cartouche
+@quotation Note 
+Locations are not required to specify all of these fields,
 and they is also allowed to have additional fields. Contract
 renderers must render at least the fields listed above, and should
 render fields that they do not understand as a key-value list.
-@end table
-@anchor{d}@w{                              }
-@anchor{b}@w{                              }
-@anchor{taler-merchant-api-tutorial Session_002dBound-Payments}@w{                              }
+@end quotation
+@end cartouche
+
+@node Index,,Advanced topics,Top
+@unnumbered Index
+
+
+@printindex ge
+
 @anchor{taler-merchant-api-tutorial The-Taler-Order-Format}@w{                              }
+@anchor{c}@w{                              }
 
 @c %**end of body
 @bye
diff --git a/texinfo/onboarding-figures/arch-api.png b/texinfo/taler-merchant-figures/arch-api.png
index 8004f790..8004f790 100644
--- a/texinfo/onboarding-figures/arch-api.png
+++ b/texinfo/taler-merchant-figures/arch-api.png
diff --git a/texinfo/taler-merchant-figures/auditor-db.png b/texinfo/taler-merchant-figures/auditor-db.png
new file mode 100644
index 00000000..3f10f3ab
--- /dev/null
+++ b/texinfo/taler-merchant-figures/auditor-db.png
diff --git a/texinfo/taler-merchant-figures/exchange-db.png b/texinfo/taler-merchant-figures/exchange-db.png
index b088da04..f99e2664 100644
--- a/texinfo/taler-merchant-figures/exchange-db.png
+++ b/texinfo/taler-merchant-figures/exchange-db.png
diff --git a/texinfo/taler-merchant-figures/merchant-db.png b/texinfo/taler-merchant-figures/merchant-db.png
new file mode 100644
index 00000000..cd5f7bd6
--- /dev/null
+++ b/texinfo/taler-merchant-figures/merchant-db.png
diff --git a/texinfo/taler-merchant-figures/replication.png b/texinfo/taler-merchant-figures/replication.png
new file mode 100644
index 00000000..855237fc
--- /dev/null
+++ b/texinfo/taler-merchant-figures/replication.png
diff --git a/texinfo/taler-merchant.texi b/texinfo/taler-merchant.texi
index 7a484371..90554002 100644
--- a/texinfo/taler-merchant.texi
+++ b/texinfo/taler-merchant.texi
@@ -3,7 +3,7 @@
 @setfilename taler-merchant.info
 @documentencoding UTF-8
 @ifinfo
-@*Generated by Sphinx 2.2.0.@*
+@*Generated by Sphinx 3.4.3.@*
 @end ifinfo
 @settitle Taler Merchant Manual
 @defindex ge
@@ -21,11 +21,11 @@
 
 @copying
 @quotation
-GNU Taler 0.6.0pre1, Dec 20, 2019
+GNU Taler 0.8.0pre0, Jan 21, 2021
 
 GNU Taler team
 
-Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Harsha Totakura, Christian Grothoff, Marcello Stanisci (GPLv3+ or GFDL 1.3+)
+Copyright @copyright{} 2014-2020 Taler Systems SA (GPLv3+ or GFDL 1.3+)
 @end quotation
 
 @end copying
@@ -50,10 +50,18 @@ Copyright @copyright{} 2014, 2015, 2016 Florian Dold, Benedikt Muller, Sree Hars
 @anchor{taler-merchant-manual doc}@anchor{0}
 @menu
 * Introduction:: 
+* Terminology:: 
 * Installation:: 
 * How to configure the merchant’s backend:: 
-* Testing:: 
+* Instance setup:: 
+* Secure setup:: 
+* Customization:: 
+* Upgrade procedure:: 
+* Tipping visitors:: 
 * Advanced topics:: 
+* Advanced experimental features:: 
+* Temporarily Abandoned Features:: 
+* Index:: 
 
 @detailmenu
  --- The Detailed Node Listing ---
@@ -64,46 +72,104 @@ Introduction
 * About this manual:: 
 * Architecture overview:: 
 
+Terminology
+
+* Instances:: 
+* Accounts:: 
+* Inventory:: 
+* Orders and Contracts:: 
+* Transfers:: 
+* Tipping:: 
+* Reserves:: 
+
 Installation
 
-* Installing Taler using Docker:: 
-* Generic instructions:: 
-* Installing Taler on Debian GNU/Linux:: 
+* Generic instructions for installation from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
+* Installing Taler on Debian GNU/Linux from source:: 
 
-Generic instructions
+Generic instructions for installation from source
 
 * Installation of dependencies:: 
-* Installing libgnunetutil:: 
+* Installing GNUnet:: 
 * Installing the GNU Taler exchange:: 
 * Installing the GNU Taler merchant backend:: 
 
 How to configure the merchant’s backend
 
+* Configuration format:: 
+* Using taler-config:: 
 * Backend options:: 
 * Sample backend configuration:: 
 * Launching the backend:: 
 
-Advanced topics
+Backend options
 
-* Configuration format:: 
-* Using taler-config:: 
-* Merchant key management:: 
-* Using the SEPA wire transfer method:: 
-* Tipping visitors:: 
-* Generate payments:: 
+* Service address:: 
+* Currency:: 
+* Database:: 
+* Exchange:: 
+* Auditor:: 
+
+Instance setup
+
+* KUDOS Accounts:: 
+* IBAN Accounts:: 
+* Setup:: 
+
+Secure setup
+
+* Using UNIX domain sockets:: 
+* Reverse proxy configuration:: 
+* Access control:: 
+
+Reverse proxy configuration
+
+* Nginx:: 
+* Apache:: 
+
+Access control
+
+* Nginx: Nginx<2>. 
+* Apache: Apache<2>. 
+
+Customization
+
+* Templates:: 
+* Static files:: 
+* Internationalization:: 
+* Limitations:: 
 
 Tipping visitors
 
-* Configure a reserve and exchange for tipping:: 
 * Fund the reserve:: 
 * Authorize a tip:: 
 * Picking up of the tip:: 
 
+Advanced topics
+
+* Database Scheme:: 
+* Configuration format: Configuration format<2>. 
+
+Configuration format
+
+* Using taler-config: Using taler-config<2>. 
+
+Advanced experimental features
+
+* Benchmarking:: 
+* Benchmark setup:: 
+* Running the benchmark command:: 
+
+Temporarily Abandoned Features
+
+* Installing Taler using Docker:: 
+
 @end detailmenu
 @end menu
 
-@node Introduction,Installation,Top,Top
-@anchor{taler-merchant-manual gnu-taler-merchant-backend-operator-manual}@anchor{1}@anchor{taler-merchant-manual introduction}@anchor{2}
+@node Introduction,Terminology,Top,Top
+@anchor{taler-merchant-manual ffoobar}@anchor{1}@anchor{taler-merchant-manual gnu-taler-merchant-backend-operator-manual}@anchor{2}@anchor{taler-merchant-manual introduction}@anchor{3}
 @chapter Introduction
 
 
@@ -115,7 +181,7 @@ Tipping visitors
 @end menu
 
 @node About GNU Taler,About this manual,,Introduction
-@anchor{taler-merchant-manual about-gnu-taler}@anchor{3}
+@anchor{taler-merchant-manual about-gnu-taler}@anchor{4}
 @section About GNU Taler
 
 
@@ -128,25 +194,25 @@ GNU Taler is compatible with anti-money-laundering (AML) and
 know-your-customer (KYC) regulation, as well as data protection
 regulation (such as GDPR).
 
-GNU Taler is not yet production-ready, after following this manual you
+GNU Taler is not yet production-ready: after following this manual you
 will have a backend that can process payments in “KUDOS”, but not
 regular currencies. This is not so much because of limitations in the
 backend, but because we are not aware of a Taler exchange operator
 offering regular currencies today.
 
 @node About this manual,Architecture overview,About GNU Taler,Introduction
-@anchor{taler-merchant-manual about-this-manual}@anchor{4}@anchor{taler-merchant-manual id1}@anchor{5}
+@anchor{taler-merchant-manual about-this-manual}@anchor{5}@anchor{taler-merchant-manual id1}@anchor{6}
 @section About this manual
 
 
-This tutorial targets system administrators who want to install a GNU
+This manual targets system administrators who want to install a GNU
 Taler merchant @emph{backend}.
 
 We expect some moderate familiarity with the compilation and
-installation of free software packages. An understanding of cryptography
+installation of Free Software packages. An understanding of cryptography
 is not required.
 
-This first chapter of the tutorial will give a brief overview of the
+This first chapter of the manual will give a brief overview of the
 overall Taler architecture, describing the environment in which the
 Taler backend operates. The second chapter then explains how to install
 the software, including key dependencies. The third chapter will explain
@@ -158,12 +224,14 @@ which will be useful for system administrators but are not necessary for
 operating a basic backend.
 
 @node Architecture overview,,About this manual,Introduction
-@anchor{taler-merchant-manual architecture-overview}@anchor{6}@anchor{taler-merchant-manual id2}@anchor{7}
+@anchor{taler-merchant-manual architecture-overview}@anchor{7}@anchor{taler-merchant-manual id2}@anchor{8}
 @section Architecture overview
 
 
-crypto-currency
-KUDOS
+@geindex crypto-currency
+
+@geindex KUDOS
+
 Taler is a pure payment system, not a new crypto-currency. As such, it
 operates in a traditional banking context. In particular, this means
 that in order to receive funds via Taler, the merchant must have a
@@ -171,6 +239,16 @@ regular bank account, and payments can be executed in ordinary
 currencies such as USD or EUR. For testing purposes, Taler uses a
 special currency “KUDOS” and includes its own special bank.
 
+@geindex frontend
+
+@geindex back office
+
+@geindex backend
+
+@geindex DBMS
+
+@geindex Postgres
+
 The Taler software stack for a merchant consists of four main
 components:
 
@@ -178,129 +256,256 @@ components:
 @itemize -
 
 @item 
-frontend
 A frontend which interacts with the customer’s browser. The frontend
 enables the customer to build a shopping cart and place an order.
 Upon payment, it triggers the respective business logic to satisfy
 the order. This component is not included with Taler, but rather
-assumed to exist at the merchant. This manual describes how to
-integrate Taler with Web shop frontends.
+assumed to exist at the merchant.
+The Merchant API Tutorial gives an
+introduction for how to integrate Taler with Web shop frontends.
 
 @item 
-back office
 A back office application that enables the shop operators to view
 customer orders, match them to financial transfers, and possibly
 approve refunds if an order cannot be satisfied. This component is
-again not included with Taler, but rather assumed to exist at the
-merchant. This manual will describe how to integrate such a component
-to handle payments managed by Taler.
+not included with Taler, but rather assumed to exist at the
+merchant. The Merchant Backend API provides
+the API specification that should be reviewed to integrate such a
+back office with the Taler backend.
 
 @item 
-backend
 A Taler-specific payment backend which makes it easy for the frontend
-to process financial transactions with Taler. The next two chapters
-will describe how to install and configure this backend.
+to process financial transactions with Taler. This manual primarily
+describes how to install and configure this backend.
 
 @item 
-DBMS
-Postgres
 A DBMS which stores the transaction history for the Taler backend.
-For now, the GNU Taler reference implemenation only supports
+For now, the GNU Taler reference implementation only supports
 Postgres, but the code could be easily extended to support another
-DBMS.
+DBMS.  Please review the Postgres documentation for details on
+how to configure the database.
 @end itemize
 
 The following image illustrates the various interactions of these key
 components:
 
-@example
-Missing diagram image
-@end example
+@image{taler-merchant-figures/arch-api,,,,png}
 
-RESTful
-Basically, the backend provides the cryptographic protocol support,
-stores Taler-specific financial information in a DBMS and communicates
-with the GNU Taler exchange over the Internet. The frontend accesses the
-backend via a RESTful API. As a result, the frontend never has to
-directly communicate with the exchange, and also does not deal with
-sensitive data. In particular, the merchant’s signing keys and bank
-account information is encapsulated within the Taler backend.
+@geindex RESTful
 
-@node Installation,How to configure the merchant’s backend,Introduction,Top
-@anchor{taler-merchant-manual installation}@anchor{8}
-@chapter Installation
+Basically, the backend provides the cryptographic protocol support, stores
+Taler-specific financial information in a DBMS and communicates with the GNU
+Taler exchange over the Internet. The frontend accesses the backend via a
+RESTful API. As a result, the frontend never has to directly communicate with
+the exchange, and also does not deal with sensitive data. In particular, the
+merchant’s signing keys and bank account information is encapsulated within
+the Taler backend.
 
+A typical deployment will additionally include a full-blown Web server (like
+Apache or Nginx). Such a Web server would be responsible for TLS termination
+and access control to the @code{/private/} API endpoints of the merchant backend.
+Please carefully review the section on @ref{9,,Secure setup} before
+deploying a Taler merchant backend to production.
 
-This chapter describes how to install the GNU Taler merchant backend.
+@node Terminology,Installation,Introduction,Top
+@anchor{taler-merchant-manual terminology}@anchor{a}
+@chapter Terminology
+
+
+This chapter describes some of the key concepts used throughout the manual.
 
 @menu
-* Installing Taler using Docker:: 
-* Generic instructions:: 
-* Installing Taler on Debian GNU/Linux:: 
+* Instances:: 
+* Accounts:: 
+* Inventory:: 
+* Orders and Contracts:: 
+* Transfers:: 
+* Tipping:: 
+* Reserves:: 
 
 @end menu
 
-@node Installing Taler using Docker,Generic instructions,,Installation
-@anchor{taler-merchant-manual installing-taler-using-docker}@anchor{9}
-@section Installing Taler using Docker
+@node Instances,Accounts,,Terminology
+@anchor{taler-merchant-manual instances}@anchor{b}
+@section Instances
 
 
-This section provides instructions for the merchant backend installation
-using ‘Docker‘.
+@geindex instance
 
-For security reasons, we run Docker against a VirtualBox instance, so
-the @code{docker} command should connect to a @code{docker-machine} instance
-that uses the VirtualBox driver.
+The backend allows the user to run multiple @emph{instances} of shops with distinct
+business entities sharing a single backend. Each instance uses its own bank
+accounts and key for signing contracts. All major accounting functionality is
+separate per instance.  What is shared is the database, HTTP(S) address and
+the main Taler configuration (accepted currency, exchanges and auditors).
 
-Therefore, the needed tools are: “docker“, “docker-machine“, and
-“docker-compose“. Please refer to Docker’s official  @footnote{@w{(1)} 
-@indicateurl{https://docs.docker.com/}
-} documentation
-in order to get those components installed, as that is not in this
-manual’s scope.
+@node Accounts,Inventory,Instances,Terminology
+@anchor{taler-merchant-manual accounts}@anchor{c}
+@section Accounts
 
-Before starting to build the merchant’s image, make sure a
-“docker-machine“ instance is up and running.
 
-Because all of the Docker source file are kept in our “deployment“
-repository, we start by checking out the @code{git://taler.net/deployment}
-codebase:
+@geindex account
 
-@example
-$ git clone git://taler.net/deployment
-@end example
+To receive payments, an instance must have configured one or more bank
+@emph{accounts}.  The backend does not have accounts for users, and instances are
+also not really ‘accounts’. So whenever we use the term @emph{account}, it is about
+a bank account of a merchant.
 
-Now we actually build the merchant’s image. From the same directory as
-above:
+@node Inventory,Orders and Contracts,Accounts,Terminology
+@anchor{taler-merchant-manual inventory}@anchor{d}
+@section Inventory
 
-@example
-$ cd deployment/docker/merchant/
-$ docker-compose build
-@end example
 
-If everything worked as expected, the merchant is ready to be launched.
-From the same directory as the previous step:
+@geindex inventory
 
-@example
-# Recall: the docker-machine should be up and running.
-$ docker-compose up
-@end example
+@geindex product
 
-You should see some live logging from all the involved containers. At
-this stage of development, you should also ignore some (harmless) error
-message from postresql about already existing roles and databases.
+@geindex lock
 
-To test if everything worked as expected, it suffices to issue a simple
-request to the merchant, as:
+@geindex unit
 
-@example
-$ curl http://$(docker-machine ip)/
-# A greeting message should be returned by the merchant.
-@end example
+@geindex order
+
+The Taler backend offers inventory management as an optional function.
+Inventory is tracked per instance and consists of @emph{products} sold in
+@emph{units}. Inventory can be finite or infinite (for digital products).
+Products may include previews (images) to be shown to the user and other
+meta-data. Inventory management allows the frontend to @emph{lock} products,
+reserving them for a particular (unpaid) @emph{order}. The backend can keep
+track of how many units of a product remain in stock and ensure that
+the number of units sold does not exceed the number of units in stock.
+
+Inventory management is optional, and it is possible for the frontend to
+include products in orders that are not in the inventory, or to override
+prices of products in the inventory.
+
+@node Orders and Contracts,Transfers,Inventory,Terminology
+@anchor{taler-merchant-manual orders-and-contracts}@anchor{e}
+@section Orders and Contracts
+
+
+@geindex order
+
+@geindex contract
+
+@geindex claim
+
+@geindex pay
+
+@geindex refund
+
+@geindex wire deadline
+
+@geindex lock
+
+@geindex legal expiration
+
+In Taler, users pay merchants for orders. An order is first created by the
+merchant, where the merchant specifies the specific terms of the order.
+
+After an order is created, it is @emph{claimed} by a wallet. Once an order is
+claimed by a specific wallet, only that wallet will be able to pay for this
+order, to the exclusion of other wallets even if they see the same order URL.
+Sharing order URLs is explicitly allowed: if a user shares and order URL
+with another user, that other user should be given the opportunity to
+purchase the same product.
+
+To prevent unauthorized wallets from claiming an order, merchants can specify
+that claims require authorization in the form of a @emph{claim token}. This is
+useful in case the order ID is predictable (say because an existing order ID
+scheme from the merchant frontend is used) and at the same time malicious
+actors claiming orders is problematic (say because of limited stocks). The use
+of claim tokens is optional, but if a claim token is used, it must be provided
+to the wallet as part of the order URI.
 
-@node Generic instructions,Installing Taler on Debian GNU/Linux,Installing Taler using Docker,Installation
-@anchor{taler-merchant-manual generic-instructions}@anchor{a}@anchor{taler-merchant-manual id4}@anchor{b}
-@section Generic instructions
+A wallet may @emph{pay} for a claimed order, at which point the order turns into
+a (paid) contract.  Orders have an expiration date after which the commercial
+offer expires and any stock of products @emph{locked} by the order is released,
+allowing the stock to be sold in other orders.
+
+Once a contract has been paid, the merchant should fulfill the contract.  It
+is possible for the merchant to @emph{refund} a contract order, for example if the
+contract cannot be fulfilled after all. Refunds are only possible after the
+customer paid and before the exchange has @emph{wired} the payment to the
+merchant. Once the funds have been wired, refunds are no longer allowed by the
+Taler exchange.  The @emph{wire deadline} specifies the latest time by which an
+exchange must wire the funds, while the (earlier) @emph{refund deadline} specifies
+the earliest time when an exchange may wire the funds.
+
+Contract information is kept for legal reasons, typically to provide tax
+records in case of a tax audit.  After the @emph{legal expiration} (by default a
+decade), contract information is deleted.
+
+@node Transfers,Tipping,Orders and Contracts,Terminology
+@anchor{taler-merchant-manual transfers}@anchor{f}
+@section Transfers
+
+
+@geindex transfer
+
+@geindex wire transfer
+
+The Taler backend can be used to verify that the exchange correctly wired all
+of the funds to the merchant. However, the backend does not have access to the
+incoming wire transfers of the merchant’s bank account. Thus, merchants must
+manually provide the backend with wire @emph{transfer} data that specifies the wire
+transfer subject and the amount that was received. Given this information, the
+backend can detect and report any irregularities that might arise.
+
+@node Tipping,Reserves,Transfers,Terminology
+@anchor{taler-merchant-manual tipping}@anchor{10}
+@section Tipping
+
+
+@geindex tip
+
+@geindex grant
+
+@geindex pick up
+
+Taler does not only allow a Website to be paid, but also to make voluntary,
+non-contractual payments to visitors, called @emph{tips}.  Such tips could be
+granted as a reward for filling in surveys or watching advertisements. For
+tips, there is no contract, tips are always voluntary actions by the Web
+site that do not arise from a contractual obligation.  Before a Web site
+can create tips, it must establish a reserve.  Once a reserve has been
+established, the merchant can @emph{grant} tips, allowing wallets to @emph{pick up}
+the tip.
+
+@node Reserves,,Tipping,Terminology
+@anchor{taler-merchant-manual reserves}@anchor{11}
+@section Reserves
+
+
+@geindex reserve
+
+@geindex close
+
+A @emph{reserve} is a pool of electronic cash at an exchange under the control of
+a private key.  Merchants withdraw coins from a reserve when granting
+tips.  A reserve is established by first generating the required key material
+in the merchant backend, and then wiring the desired amount of funds to the
+exchange.
+
+An exchange will automatically @emph{close} a reserve after a fixed period of time
+(typically about a month), wiring any remaining funds back to the merchant.
+
+@node Installation,How to configure the merchant’s backend,Terminology,Top
+@anchor{taler-merchant-manual installation}@anchor{12}
+@chapter Installation
+
+
+This chapter describes how to install the GNU Taler merchant backend.
+
+@menu
+* Generic instructions for installation from source:: 
+* Installing the GNU Taler binary packages on Debian:: 
+* Installing Taler on Debian GNU/Linux from source:: 
+
+@end menu
+
+@node Generic instructions for installation from source,Installing the GNU Taler binary packages on Debian,,Installation
+@anchor{taler-merchant-manual generic-instructions}@anchor{13}@anchor{taler-merchant-manual generic-instructions-for-installation-from-source}@anchor{14}
+@section Generic instructions for installation from source
 
 
 This section provides generic instructions for the merchant backend
@@ -313,14 +518,14 @@ system.
 
 @menu
 * Installation of dependencies:: 
-* Installing libgnunetutil:: 
+* Installing GNUnet:: 
 * Installing the GNU Taler exchange:: 
 * Installing the GNU Taler merchant backend:: 
 
 @end menu
 
-@node Installation of dependencies,Installing libgnunetutil,,Generic instructions
-@anchor{taler-merchant-manual id5}@anchor{c}@anchor{taler-merchant-manual installation-of-dependencies}@anchor{d}
+@node Installation of dependencies,Installing GNUnet,,Generic instructions for installation from source
+@anchor{taler-merchant-manual id3}@anchor{15}@anchor{taler-merchant-manual installation-of-dependencies}@anchor{16}
 @subsection Installation of dependencies
 
 
@@ -331,91 +536,103 @@ backend:
 @itemize -
 
 @item 
-autoconf >= 2.69
-
-@item 
-automake >= 1.14
+libsqlite3 >= 3.16.2
 
 @item 
-libtool >= 2.4
+GNU libunistring >= 0.9.3
 
 @item 
-autopoint >= 0.19
+libcurl >= 7.26 (or libgnurl >= 7.26)
 
 @item 
-libltdl >= 2.4
+libqrencode >= 4.0.0
 
 @item 
-libunistring >= 0.9.3
+GNU libgcrypt >= 1.6
 
 @item 
-libcurl >= 7.26 (or libgnurl >= 7.26)
+libsodium >= 1.0
 
 @item 
-GNU libmicrohttpd >= 0.9.39
+libargon2 >= 20171227
 
 @item 
-GNU libgcrypt >= 1.6
+libjansson >= 2.7
 
 @item 
-libjansson >= 2.7
+Postgres >= 9.6, including libpq
 
 @item 
-Postgres >= 9.4, including libpq
+GNU libmicrohttpd >= 0.9.71
 
 @item 
-libgnunetutil (from Git)
+GNUnet >= 0.14.0 (from source tarball@footnote{http://ftpmirror.gnu.org/gnunet/})
 
 @item 
-GNU Taler exchange (from Git)
+GNU Taler exchange (see release announcement@footnote{https://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=taler&idxname=info-gnu&max=20&result=normal&sort=date:late})
 @end itemize
 
-Except for the last two, these are available in most GNU/Linux
-distributions and should just be installed using the respective package
-manager.
+Except for the last two, these are available in most GNU/Linux distributions
+and should just be installed using the respective package manager. Be careful
+with GNU libmicrohttpd; here, some distributions only include an older version
+that will not work.
+
+While you are in the GNU Taler exchange
+download directory@footnote{http://ftpmirror.gnu.org/taler/},
+you might as well also download the tarball for GNU Taler merchant.
+
+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 0.8.0 is compatible with Taler exchange 0.8.1.
 
 The following sections will provide detailed instructions for installing
-the libgnunetutil and GNU Taler exchange dependencies.
+the @code{libgnunetutil} and GNU Taler exchange dependencies.
+
+@node Installing GNUnet,Installing the GNU Taler exchange,Installation of dependencies,Generic instructions for installation from source
+@anchor{taler-merchant-manual installing-gnunet}@anchor{17}@anchor{taler-merchant-manual installing-libgnunetutil}@anchor{18}
+@subsection Installing GNUnet
 
-@node Installing libgnunetutil,Installing the GNU Taler exchange,Installation of dependencies,Generic instructions
-@anchor{taler-merchant-manual id6}@anchor{e}@anchor{taler-merchant-manual installing-libgnunetutil}@anchor{f}
-@subsection Installing libgnunetutil
 
+@geindex GNUnet
 
-GNUnet
-Before you install libgnunetutil, you must download and install the
-dependencies mentioned in the previous section, otherwise the build may
-succeed but fail to export some of the tooling required by Taler.
+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.
 
-To download and install libgnunetutil, proceed as follows:
+To install GNUnet, unpack the tarball and change
+into the resulting directory, then proceed as follows:
 
 @example
-$ git clone https://gnunet.org/git/gnunet/
-$ cd gnunet/
-$ ./bootstrap
 $ ./configure [--prefix=GNUNETPFX]
 $ # Each dependency can be fetched from non standard locations via
 $ # the '--with-<LIBNAME>' option. See './configure --help'.
 $ make
 # make install
+# 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.
 
-@node Installing the GNU Taler exchange,Installing the GNU Taler merchant backend,Installing libgnunetutil,Generic instructions
-@anchor{taler-merchant-manual id7}@anchor{10}@anchor{taler-merchant-manual installing-the-gnu-taler-exchange}@anchor{11}
+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!
+
+@node Installing the GNU Taler exchange,Installing the GNU Taler merchant backend,Installing GNUnet,Generic instructions for installation from source
+@anchor{taler-merchant-manual id4}@anchor{19}@anchor{taler-merchant-manual installing-the-gnu-taler-exchange}@anchor{1a}
 @subsection Installing the GNU Taler exchange
 
 
-exchange
-After installing GNUnet, you can download and install the exchange as
-follows:
+@geindex exchange
+
+After installing GNUnet, unpack the GNU Taler exchange tarball,
+change into the resulting directory, and proceed as follows:
 
 @example
-$ git clone git://taler.net/exchange
-$ cd exchange
-$ ./bootstrap
 $ ./configure [--prefix=EXCHANGEPFX] \
               [--with-gnunet=GNUNETPFX]
 $ # Each dependency can be fetched from non standard locations via
@@ -424,64 +641,168 @@ $ make
 # make install
 @end example
 
-If you did not specify a prefix, the exchange will install to
-@code{/usr/local}, which requires you to run the last step as @code{root}.
-Note that you have to specify @code{--with-gnunet=/usr/local} if you
-installed GNUnet to @code{/usr/local} in the previous step.
+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.
+
+There is no need to actually run a Taler exchange to use the Taler merchant
+backend – all the merchant needs from the Taler exchange is a few headers and
+libraries!
 
-@node Installing the GNU Taler merchant backend,,Installing the GNU Taler exchange,Generic instructions
-@anchor{taler-merchant-manual id8}@anchor{12}@anchor{taler-merchant-manual installing-the-gnu-taler-merchant-backend}@anchor{13}
+@node Installing the GNU Taler merchant backend,,Installing the GNU Taler exchange,Generic instructions for installation from source
+@anchor{taler-merchant-manual id5}@anchor{1b}@anchor{taler-merchant-manual installing-the-gnu-taler-merchant-backend}@anchor{1c}
 @subsection Installing the GNU Taler merchant backend
 
 
-backend
+@geindex backend
+
+GNU Taler merchant has these additional dependencies:
+
+
+@itemize -
+
+@item 
+libqrencode >= 4.0.0
+@end itemize
+
 The following steps assume all dependencies are installed.
 
-Use the following commands to download and install the merchant backend:
+First, unpack the GNU Taler merchant tarball and change into
+the resulting directory.
+Then, use the following commands to build and install the merchant backend:
 
 @example
-$ git clone git://taler.net/merchant
-$ cd merchant
-$ ./bootstrap
 $ ./configure [--prefix=PFX] \
               [--with-gnunet=GNUNETPFX] \
               [--with-exchange=EXCHANGEPFX]
 $ # Each dependency can be fetched from non standard locations via
 $ # the '--with-<LIBNAME>' option. See './configure --help'.
 $ make
-$ make install
+# make install
 @end example
 
-Note that you have to specify @code{--with-exchange=/usr/local} and/or
-@code{--with-exchange=/usr/local} if you installed the exchange and/or
+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-exchange=/usr/local} and/or
+@code{--with-gnunet=/usr/local} if you installed the exchange and/or
 GNUnet to @code{/usr/local} in the previous steps.
 
-@node Installing Taler on Debian GNU/Linux,,Generic instructions,Installation
-@anchor{taler-merchant-manual installing-taler-on-debian-gnu-002flinux}@anchor{14}@anchor{taler-merchant-manual installing-taler-on-debian-gnu-linux}@anchor{15}
-@section Installing Taler on Debian GNU/Linux
+Depending on the prefixes you specified for the installation and the
+distribution you are using, you may have to edit @code{/etc/ld.so.conf}, adding
+lines for @code{GNUNETPFX/lib/} and @code{EXCHANGEPFX/lib/} and @code{PFX/lib/}
+(replace the prefixes with the actual paths you used). Afterwards, you should
+run @code{ldconfig}. Without this step, it is possible that the linker may not
+find the installed libraries and launching the Taler merchant backend would
+then fail.
+
+@node Installing the GNU Taler binary packages on Debian,Installing Taler on Debian GNU/Linux from source,Generic instructions for installation from source,Installation
+@anchor{taler-merchant-manual installing-the-gnu-taler-binary-packages-on-debian}@anchor{1d}
+@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
+Sid, which means you should use a system which at least includes
+unstable packages in its source list.  We recommend using APT pinning
+to limit unstable packages to those explicitly requested. To do this,
+set your @code{/etc/apt/preferences} as follows:
+
+@example
+Package: *
+Pin: release a=stable
+Pin-Priority: 700
+
+Package: *
+Pin: release a=testing
+Pin-Priority: 650
+
+Package: *
+Pin: release a=unstable
+Pin-Priority: 600
+
+Package: *
+Pin: release l=Debian-Security
+Pin-Priority: 1000
+@end example
+
+A typical @code{/etc/apt/sources.list} file for this setup
+would look like this:
+
+@example
+deb http://ftp.ch.debian.org/debian/ buster main
+deb http://security.debian.org/debian-security buster/updates main
+deb http://ftp.ch.debian.org/debian/ testing main
+deb http://ftp.ch.debian.org/debian/ unstable main
+deb https://deb.taler.net/apt/debian sid main
+@end example
+
+The last line is crucial, as it adds the GNU Taler packages.
+
+Next, you must import the Taler Systems SA public package signing key
+into your keyring and update the package lists:
+
+@example
+# wget -O - https://taler.net/taler-systems.gpg.key | apt-sign add -
+# 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 merchant backend, you can now simply run:
+
+@example
+# apt install taler-merchant
+@end example
+
+Note that the package does not complete the integration of the backend with
+the HTTP reverse proxy (typically with TLS certificates).  A configuration
+fragment for Nginx or Apache will be placed in
+@code{/etc/@{apache,nginx@}/conf-available/taler-merchant.conf}.  You must
+furthermore still configure the instances, and may need to extend the fragment
+with access control restrictions for non-default instances.
+
+@node Installing Taler on Debian GNU/Linux from source,,Installing the GNU Taler binary packages on Debian,Installation
+@anchor{taler-merchant-manual installing-taler-on-debian-gnu-002flinux}@anchor{1e}@anchor{taler-merchant-manual installing-taler-on-debian-gnu-linux-from-source}@anchor{1f}
+@section Installing Taler on Debian GNU/Linux from source
 
 
-Wheezy
-Debian
+@geindex Wheezy
+
+@geindex Jessie
+
+@geindex Stretch
+
+@geindex Debian
+
 Debian wheezy is too old and lacks most of the packages required.
+Debian jessie is better, but still lacks PostgreSQL 9.6.
 
-On Debian jessie, only GNU libmicrohttpd needs to be compiled from
-source. To install dependencies on Debian jesse, run the following
+On Debian stretch, only GNU libmicrohttpd needs to be compiled from
+source. To install dependencies on Debian stretch, run the following
 commands:
 
 @example
 # apt-get install \
-  autoconf \
-  automake \
-  autopoint \
-  libtool \
+  libqrencode-dev \
+  libsqlite3-dev \
   libltdl-dev \
   libunistring-dev \
+  libsodium-dev \
+  libargon2-0-dev \
   libcurl4-gnutls-dev \
   libgcrypt20-dev \
   libjansson-dev \
   libpq-dev \
-  postgresql-9.4
+  postgresql-9.6
 # wget https://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-latest.tar.gz
 # wget https://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-latest.tar.gz.sig
 # gpg -v libmicrohttpd-latest.tar.gz # Should show signed by 939E6BE1E29FC3CC
@@ -495,32 +816,37 @@ For more recent versions of Debian, you should instead run:
 
 @example
 # apt-get install \
-  autoconf \
-  automake \
-  autopoint \
-  libtool \
+  libqrencode-dev \
+  libsqlite3-dev \
   libltdl-dev \
   libunistring-dev \
+  libsodium-dev \
+  libargon2-dev \
   libcurl4-gnutls-dev \
   libgcrypt20-dev \
   libjansson-dev \
   libpq-dev \
-  postgresql-9.5 \
+  postgresql-9.6 \
   libmicrohttpd-dev
 @end example
 
+Note that stretch requires @code{libargon2-0-dev},
+while later versions of Debian require @code{libargon2-dev}.
+
 For the rest of the installation, follow the generic installation
 instructions starting with the installation of libgnunetutil. Note that
-if you used the Debian wheezy instructions above, you need to pass
+if you used the Debian stretch instructions above, you need to pass
 @code{--with-microhttpd=/usr/local/} to all @code{configure} invocations.
 
-@node How to configure the merchant’s backend,Testing,Installation,Top
-@anchor{taler-merchant-manual how-to-configure-the-merchants-backend}@anchor{16}
+@node How to configure the merchant’s backend,Instance setup,Installation,Top
+@anchor{taler-merchant-manual how-to-configure-the-merchants-backend}@anchor{20}
 @chapter How to configure the merchant’s backend
 
 
-taler-config
-taler.conf
+@geindex taler-config
+
+@geindex taler.conf
+
 The installation already provides reasonable defaults for most of the
 configuration options. However, some must be provided, in particular the
 database account and bank account that the backend should use. By
@@ -528,36 +854,191 @@ default, the file @code{$HOME/.config/taler.conf} is where the Web shop
 administrator specifies configuration values that augment or override
 the defaults. The format of the configuration file is the well-known INI
 file format. You can edit the file by hand, or use the @code{taler-config}
-commands given as examples. For more information on @code{taler-config},
-see @ref{17,,Using taler-config}.
+commands given as examples.
 
 @menu
+* Configuration format:: 
+* Using taler-config:: 
 * Backend options:: 
 * Sample backend configuration:: 
 * Launching the backend:: 
 
 @end menu
 
-@node Backend options,Sample backend configuration,,How to configure the merchant’s backend
-@anchor{taler-merchant-manual backend-options}@anchor{18}@anchor{taler-merchant-manual id9}@anchor{19}
+@node Configuration format,Using taler-config,,How to configure the merchant’s backend
+@anchor{taler-merchant-manual configuration-format}@anchor{21}
+@section Configuration format
+
+
+In Taler realm, any component obeys to the same pattern to get
+configuration values. According to this pattern, once the component has
+been installed, the installation deploys default values in
+$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
+these defaults, the user can write a custom .conf file and either pass
+it to the component at execution time, or name it taler.conf and place
+it under $HOME/.config/.
+
+A config file is a text file containing sections, and each section
+contains its values. The right format follows:
+
+@example
+[section1]
+value1 = string
+value2 = 23
+
+[section2]
+value21 = string
+value22 = /path22
+@end example
+
+Throughout any configuration file, it is possible to use @code{$}-prefixed
+variables, like @code{$VAR}, especially when they represent filesystem
+paths. It is also possible to provide defaults values for those
+variables that are unset, by using the following syntax:
+@code{$@{VAR:-default@}}. However, there are two ways a user can set
+@code{$}-prefixable variables:
+
+by defining them under a @code{[paths]} section, see example below,
+
+@example
+[paths]
+TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
+..
+[section-x]
+path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
+@end example
+
+or by setting them in the environment:
+
+@example
+$ export VAR=/x
+@end example
+
+The configuration loader will give precedence to variables set under
+@code{[path]}, though.
+
+The utility @code{taler-config}, which gets installed along with the
+exchange, serves to get and set configuration values without directly
+editing the .conf. The option @code{-f} is particularly useful to resolve
+pathnames, when they use several levels of @code{$}-expanded variables. See
+@code{taler-config --help}.
+
+Note that, in this stage of development, the file
+@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
+component. For example, both an exchange and a bank can read values from
+it.
+
+The repository @code{git://taler.net/deployment} contains examples of
+configuration file used in our demos. See under @code{deployment/config}.
+
+@quotation
+
+@strong{Note}
+
+Expectably, some components will not work just by using default
+values, as their work is often interdependent. For example, a
+merchant needs to know an exchange URL, or a database name.
+@end quotation
+
+@node Using taler-config,Backend options,Configuration format,How to configure the merchant’s backend
+@anchor{taler-merchant-manual using-taler-config}@anchor{22}
+@section Using taler-config
+
+
+The tool @code{taler-config} can be used to extract or manipulate
+configuration values; however, the configuration use the well-known INI
+file format and can also be edited by hand.
+
+Run
+
+@example
+$ taler-config -s $SECTION
+@end example
+
+to list all of the configuration values in section @code{$SECTION}.
+
+Run
+
+@example
+$ taler-config -s $section -o $option
+@end example
+
+to extract the respective configuration value for option @code{$option} in
+section @code{$section}.
+
+Finally, to change a setting, run
+
+@example
+$ taler-config -s $section -o $option -V $value
+@end example
+
+to set the respective configuration value to @code{$value}. Note that you
+have to manually restart the Taler backend after you change the
+configuration to make the new configuration go into effect.
+
+Some default options will use $-variables, such as @code{$DATADIR} within
+their value. To expand the @code{$DATADIR} or other $-variables in the
+configuration, pass the @code{-f} option to @code{taler-config}. For example,
+compare:
+
+@example
+$ taler-config -s ACCOUNT-bank \
+               -o WIRE_RESPONSE
+$ taler-config -f -s ACCOUNT-bank \
+               -o WIRE_RESPONSE
+@end example
+
+While the configuration file is typically located at
+@code{$HOME/.config/taler.conf}, an alternative location can be specified
+to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
+option.
+
+@node Backend options,Sample backend configuration,Using taler-config,How to configure the merchant’s backend
+@anchor{taler-merchant-manual backend-options}@anchor{23}@anchor{taler-merchant-manual id6}@anchor{24}
 @section Backend options
 
 
+@geindex DBMS
+
+@geindex Postgres
+
+@geindex UNIX domain socket
+
+@geindex TCP
+
+@geindex port
+
+@geindex currency
+
+@geindex KUDOS
+
+@geindex exchange
+
+@geindex instance
+
+@geindex wire format
+
 The following table describes the options that commonly need to be
 modified. Here, the notation @code{[$section]/$option} denotes the option
 @code{$option} under the section @code{[$section]} in the configuration file.
 
+@menu
+* Service address:: 
+* Currency:: 
+* Database:: 
+* Exchange:: 
+* Auditor:: 
+
+@end menu
 
-@table @asis
+@node Service address,Currency,,Backend options
+@anchor{taler-merchant-manual service-address}@anchor{25}
+@subsection Service address
 
-@item Service address
 
 The following option sets the transport layer address used by the
 merchant backend:
 
-UNIX domain socket
-TCP
-
 @example
 [MERCHANT]/SERVE = TCP | UNIX
 @end example
@@ -577,12 +1058,11 @@ latter takes the usual permission mask given as a number, e.g. 660
 for user/group read-write access.
 @end itemize
 
-The frontend can then connect to the backend over HTTP using the
-specified address. If frontend and backend run within the same
-operating system, the use of a UNIX domain socket is recommended to
-avoid accidentally exposing the backend to the network.
+The frontend can then connect to the backend over HTTP using the specified
+address. If frontend and backend run within the same operating system, the
+use of a UNIX domain socket is recommended to avoid accidentally exposing
+the backend to the network.
 
-port
 To run the Taler backend on TCP port 8888, use:
 
 @example
@@ -590,14 +1070,14 @@ $ taler-config -s MERCHANT -o SERVE -V TCP
 $ taler-config -s MERCHANT -o PORT -V 8888
 @end example
 
-@item Currency
+@node Currency,Database,Service address,Backend options
+@anchor{taler-merchant-manual currency}@anchor{26}
+@subsection Currency
+
 
 Which currency the Web shop deals in, i.e. “EUR” or “USD”, is
 specified using the option
 
-currency
-KUDOS
-
 @example
 [TALER]/CURRENCY
 @end example
@@ -610,9 +1090,11 @@ will work with the Taler demonstration exchange at
 $ taler-config -s TALER -o CURRENCY -V KUDOS
 @end example
 
-@item Database
+@node Database,Exchange,Currency,Backend options
+@anchor{taler-merchant-manual database}@anchor{27}
+@subsection Database
+
 
-DBMS
 In principle is possible for the backend to support different DBMSs.
 The option
 
@@ -629,10 +1111,9 @@ DBMS-specific options to access the database.
 For postgres, you need to provide:
 
 @example
-[merchantdb-postgres]/config
+[MERCHANTDB-postgres]/CONFIG
 @end example
 
-Postgres
 This option specifies a postgres access path using the format
 @code{postgres:///$DBNAME}, where @code{$DBNAME} is the name of the
 Postgres database you want to use. Suppose @code{$USER} is the name of
@@ -640,7 +1121,7 @@ the user who will run the backend process. Then, you need to first
 run
 
 @example
-$ sudu -u postgres createuser -d $USER
+$ sudo -u postgres createuser -d $USER
 @end example
 
 as the Postgres database administrator (usually @code{postgres}) to
@@ -658,165 +1139,132 @@ To configure the Taler backend to use this database, run:
 
 @example
 $ taler-config -s MERCHANTDB-postgres -o CONFIG \
-  -V postgres:///$DBNAME
+    -V postgres:///$DBNAME
 @end example
 
-@item Exchange
-
-exchange
-To add an exchange to the list of trusted payment service providers,
-you create a section with a name that starts with “exchange-”. In
-that section, the following options need to be configured:
-
-
-@itemize -
-
-@item 
-The “url” option specifies the exchange’s base URL. For example,
-to use the Taler demonstrator use:
+Now you should create the tables and indices. To do this, run as @code{$USER}:
 
 @example
-$ taler-config -s EXCHANGE-demo -o URL \
-  -V https://exchange.demo.taler.net/
+$ taler-merchant-dbinit
 @end example
 
-@item 
-master key
-The “master_key” option specifies the exchange’s master public key
-in base32 encoding. For the Taler demonstrator, use:
+You can improve your security posture if you now REVOKE the rights to CREATE,
+DROP or ALTER tables from @code{$USER}. However, if you do so, please be aware
+that you may have to temporarily GRANT those rights again when you update the
+merchant backend.  For details on how to REVOKE or GRANT these rights, consult
+the Postgres documentation.
 
-@example
-$ taler-config -s EXCHANGE-demo -o master_key \
-  -V CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00
-@end example
+Commands, like @code{taler-merchant-dbinit}, that support the @code{-l LOGFILE}
+command-line option, send logging output to standard error by default.
 
-Note that multiple exchanges can be added to the system by using
-different tokens in place of @code{demo} in the example above. Note
-that all of the exchanges must use the same currency. If you need
-to support multiple currencies, you need to configure a backend
-per currency.
-@end itemize
+@c index: MASTER_KEY
+
+@node Exchange,Auditor,Database,Backend options
+@anchor{taler-merchant-manual exchange}@anchor{28}
+@subsection Exchange
 
-@item Instances
 
-instance
-The backend allows the user to run multiple instances of shops with
-distinct business entities against a single backend. Each instance
-uses its own bank accounts and key for signing contracts. It is
-mandatory to configure a “default” instance.
+To add an exchange to the list of trusted payment service providers, you
+create a section with a name that starts with “MERCHANT-EXCHANGE-”. In that
+section, the following options need to be configured:
 
 
 @itemize -
 
 @item 
-The “KEYFILE” option specifies the file containing the instance’s
-private signing key. For example, use:
+The “EXCHANGE_BASE_URL” option specifies the exchange’s base URL. For example,
+to use the Taler demonstrator, specify:
 
 @example
-$ taler-config -s INSTANCE-default -o KEYFILE \
-  -V '$@{TALER_CONFIG_HOME@}/merchant/instace/default.key'
+$ taler-config -s MERCHANT-EXCHANGE-demo \
+    -o EXCHANGE_BASE_URL \
+    -V https://exchange.demo.taler.net/
 @end example
 
 @item 
-The “NAME” option specifies a human-readable name for the
-instance. For example, use:
+The “MASTER_KEY” option specifies the exchange’s master public key
+in base32 encoding. For the Taler demonstrator, use:
 
 @example
-$ taler-config -s INSTANCE-default -o NAME \
-  -V 'Kudos Inc.'
+$ taler-config -s MERCHANT-EXCHANGE-demo \
+    -o MASTER_KEY \
+    -V CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00
 @end example
 
 @item 
-The optional “TIP_EXCHANGE” and “TIP_EXCHANGE_PRIV_FILENAME”
-options are discussed in Tipping visitors
+The “CURRENCY” option specifies the exchange’s currency.
+For the Taler demonstrator, use:
+
+@example
+$ taler-config -s MERCHANT-EXCHANGE-demo \
+    -o CURRENCY \
+    -V KUDOS
+@end example
 @end itemize
 
-@item Accounts
+Note that multiple exchanges can be added to the system by using different
+tokens in place of @code{demo} in the example above. Note that all of the
+exchanges must use the same currency: If the currency does not match the main
+currency from the “TALER” section, the exchange is ignored. If you need to
+support multiple currencies, you need to configure a backend per currency.
 
-wire format
-In order to receive payments, the merchant backend needs to
-communicate bank account details to the exchange. For this, the
-configuration must include one or more sections named “ACCOUNT-name”
-where @code{name} can be replaced by some human-readable word
-identifying the account. For each section, the following options
-should be provided:
+@node Auditor,,Exchange,Backend options
+@anchor{taler-merchant-manual auditor}@anchor{29}
+@subsection Auditor
 
 
-@itemize -
+To add an auditor to the list of trusted auditors (which implies
+that all exchanges audited by this auditor will be trusted!)
+you create a section with a name that starts with “MERCHANT-AUDITOR-”. In
+that section, the following options need to be configured:
 
-@item 
-The “URL” option specifies a @code{payto://}-URL for the account of
-the merchant. For example, use:
 
-@example
-$ taler-config -s ACCOUNT-bank -o NAME \
-  -V 'payto://x-taler-bank/bank.demo.taler.net/4'
-@end example
+@itemize -
 
 @item 
-The “WIRE_RESPONSE” option specifies where Taler should store the
-(salted) JSON encoding of the wire account. The file given will be
-created if it does not exist. For example, use:
+The “AUDITOR_BASE_URL” option specifies the auditor’s base URL. For example,
+to use the Taler demonstrator’s auditor, specify:
 
 @example
-$ taler-config -s ACCOUNT-bank -o WIRE_RESPONSE \
-  -V '@{$TALER_CONFIG_HOME@}/merchant/bank.json'
+$ taler-config -s MERCHANT-AUDITOR-demo \
+    -o AUDITOR_BASE_URL \
+    -V https://exchange.demo.taler.net/
 @end example
 
 @item 
-The “PLUGIN” option specifies which wire plugin should be used for
-this account. The plugin must support the wire method used by the
-URL. For example, use:
+The “AUDITOR_KEY” option specifies the auditor’s public key
+in base32 encoding. For the Taler demonstrator, use:
 
 @example
-$ taler-config -s ACCOUNT-bank -o PLUGIN \
-  -V taler_bank
+$ taler-config -s MERCHANT-AUDITOR-demo \
+    -o AUDITOR_KEY \
+    -V FIXMEBADVALUENEEDTOGETTHERIGHTVALUEHEREEVENTUALLY000
 @end example
 
 @item 
-For each @code{instance} that should use this account, you should set
-@code{HONOR_instance} and @code{ACTIVE_instance} to YES. The first
-option will cause the instance to accept payments to the account
-(for existing contracts), while the second will cause the backend
-to include the account as a possible option for new contracts.
-
-For example, use:
+The “CURRENCY” option specifies the auditor’s currency.
+For the Taler demonstrator, use:
 
 @example
-$ taler-config -s ACCOUNT-bank -o HONOR_default \
-  -V YES
-$ taler-config -s ACCOUNT-bank -o ACTIVE_default \
-  -V YES
+$ taler-config -s MERCHANT-AUDITOR-demo \
+    -o CURRENCY \
+    -V KUDOS
 @end example
-
-to use “account-bank” for the “default” instance.
 @end itemize
 
-Depending on which PLUGIN you configured, you may additionally
-specfiy authentication options to enable the plugin to use the
-account.
-
-For example, with @code{taler_bank} plugin, use:
-
-@example
-$ taler-config -s ACCOUNT-bank -o TALER_BANK_AUTH_METHOD \
-  -V basic
-$ taler-config -s ACCOUNT-bank -o USERNAME \
-  -V user42
-$ taler-config -s ACCOUNT-bank -o PASSWORD \
-  -V pass42
-@end example
-
-Note that additional instances can be specified using different
-tokens in the section name instead of @code{default}.
-@end table
+Note that multiple auditors can be added to the system by using different
+tokens in place of @code{demo} in the example above. Note that all of the
+auditors must use the same currency: If the currency does not match the main
+currency from the “TALER” section, the auditor is ignored.  If you need to
+support multiple currencies, you need to configure a backend per currency.
 
 @node Sample backend configuration,Launching the backend,Backend options,How to configure the merchant’s backend
-@anchor{taler-merchant-manual id10}@anchor{1a}@anchor{taler-merchant-manual sample-backend-configuration}@anchor{1b}
+@anchor{taler-merchant-manual id7}@anchor{2a}@anchor{taler-merchant-manual sample-backend-configuration}@anchor{2b}
 @section Sample backend configuration
 
 
-configuration
+@geindex configuration
+
 The following is an example for a complete backend configuration:
 
 @example
@@ -831,23 +1279,18 @@ DATABASE = postgres
 [MERCHANTDB-postgres]
 CONFIG = postgres:///donations
 
-[INSTANCE-default]
-KEYFILE = $DATADIR/key.priv
-NAME = "Kudos Inc."
-
-[ACCOUNT-bank]
-URL = payto://x-taler-bank/bank.demo.taler.net/4
-WIRE_RESPONSE = $DATADIR/bank.json
-PLUGIN = taler_bank
-HONOR_default = YES
-ACTIVE_default = YES
-TALER_BANK_AUTH_METHOD = basic
-USERNAME = my_user
-PASSWORD = 1234pass
-
-[EXCHANGE-trusted]
-URL = https://exchange.demo.taler.net/
-MASTER_KEY = CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00
+[merchant-exchange-NAME]
+EXCHANGE_BASE_URL = https://exchange.demo.taler.net/
+MASTER_KEY = FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0
+# If currency does not match [TALER] section, the exchange
+# will be ignored!
+CURRENCY = KUDOS
+
+[merchant-auditor-NAME]
+AUDITOR_BASE_URL = https://auditor.demo.taler.net/
+AUDITOR_KEY = DSDASDXAMDAARMNAD53ZA4AFAHA2QADAMAHHASWDAWXN84SDAA11
+# If currency does not match [TALER] section, the auditor
+# will be ignored!
 CURRENCY = KUDOS
 @end example
 
@@ -856,29 +1299,34 @@ Given the above configuration, the backend will use a database named
 
 The backend will deposit the coins it receives to the exchange at
 @indicateurl{https://exchange.demo.taler.net/}, which has the master key
-“CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00”.
+“FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0”.
 
 Please note that @code{doc/config.sh} will walk you through all
 configuration steps, showing how to invoke @code{taler-config} for each of
 them.
 
 @node Launching the backend,,Sample backend configuration,How to configure the merchant’s backend
-@anchor{taler-merchant-manual id11}@anchor{1c}@anchor{taler-merchant-manual launching-the-backend}@anchor{1d}
+@anchor{taler-merchant-manual id8}@anchor{2c}@anchor{taler-merchant-manual launching-the-backend}@anchor{2d}
 @section Launching the backend
 
 
-backend
-taler-merchant-httpd
+@geindex backend
+
+@geindex taler-merchant-httpd
+
 Assuming you have configured everything correctly, you can launch the
-merchant backend using:
+merchant backend as @code{$USER} using
 
 @example
 $ taler-merchant-httpd
 @end example
 
-When launched for the first time, this command will print a message
-about generating your private key. If everything worked as expected, the
-command
+To ensure the process runs always in the background and also after rebooting,
+you should use systemd, cron or some other init system of your operating
+system to launch the process. Consult the documentation of your operating
+system for how to start and stop daemons.
+
+If everything worked as expected, the command
 
 @example
 $ curl http://localhost:8888/
@@ -892,441 +1340,539 @@ Hello, I'm a merchant's Taler backend. This HTTP server is not for humans.
 
 Please note that your backend is right now likely globally reachable.
 Production systems should be configured to bind to a UNIX domain socket
-or properly restrict access to the port.
+and use TLS for improved network privacy, see @ref{9,,Secure setup}.
 
-@node Testing,Advanced topics,How to configure the merchant’s backend,Top
-@anchor{taler-merchant-manual id12}@anchor{1e}@anchor{taler-merchant-manual testing}@anchor{1f}
-@chapter Testing
+@geindex instance
 
+@node Instance setup,Secure setup,How to configure the merchant’s backend,Top
+@anchor{taler-merchant-manual id9}@anchor{2e}@anchor{taler-merchant-manual instance-setup}@anchor{2f}
+@chapter Instance setup
 
-The tool @code{taler-merchant-generate-payments} can be used to test the
-merchant backend installation. It implements all the payment’s steps in
-a programmatically way, relying on the backend you give it as input.
-Note that this tool gets installed along all the merchant backend’s
-binaries.
 
-This tool gets configured by a config file, that must have the following
-layout:
+Before using the backend, you must at least configure the “default” instance.
 
-@example
-[PAYMENTS-GENERATOR]
+@menu
+* KUDOS Accounts:: 
+* IBAN Accounts:: 
+* Setup:: 
 
-# The exchange used during the test: make sure the merchant backend
-# being tested accpets this exchange.
-# If the sysadmin wants, she can also install a local exchange
-# and test against it.
-EXCHANGE = https://exchange.demo.taler.net/
+@end menu
 
-# This value must indicate some URL where the backend
-# to be tested is listening; it doesn't have to be the
-# "official" one, though.
-MERCHANT = http://localbackend/
+@node KUDOS Accounts,IBAN Accounts,,Instance setup
+@anchor{taler-merchant-manual kudos-accounts}@anchor{30}
+@section KUDOS Accounts
 
-# This value is used when the tool tries to withdraw coins,
-# and must match the bank used by the exchange. If the test is
-# done against the exchange at https://exchange.demo.taler.net/,
-# then this value can be "https://bank.demo.taler.net/".
-BANK = https://bank.demo.taler.net/
 
-# The merchant instance in charge of serving the payment.
-# Make sure this instance has a bank account at the same bank
-# indicated by the 'bank' option above.
-INSTANCE = default
+The main configuration data that must be provided for each instance
+is the bank account information.
 
-# The currency used during the test. Must match the one used
-# by merchant backend and exchange.
-CURRENCY = KUDOS
-@end example
+In order to receive payments, the merchant backend needs to
+communicate bank account details to the exchange.
 
-Run the test in the following way:
+The bank account information is provided in the form of a @code{payto://}-URI.
+See RFC 8905 for the format of @code{payto://}-URIs.
 
-@example
-$ taler-merchant-generate-payments [-c config] [-e EURL] [-m MURL]
-@end example
+For first tests, you should sign up for a KUDOS bank
+account at @indicateurl{https://bank.demo.taler.net/}.
+In this case, the payto://-URI will be of the form
+“payto://x-taler-bank/bank.demo.taler.net/$USERNAME” where “$USERNAME”
+must be replaced with the name of the account that was established
+at @indicateurl{https://bank.demo.taler.net/}.
+
+@node IBAN Accounts,Setup,KUDOS Accounts,Instance setup
+@anchor{taler-merchant-manual iban-accounts}@anchor{31}
+@section IBAN Accounts
 
-The argument @code{config} given to @code{-c} points to the configuration file
-and is optional – @code{~/.config/taler.conf} will be checked by default.
-By default, the tool forks two processes: one for the merchant backend,
-and one for the exchange. The option @code{-e} (@code{-m}) avoids any exchange
-(merchant backend) fork, and just runs the generator against the
-exchange (merchant backend) running at @code{EURL} (@code{MURL}).
 
-Please NOTE that the generator contains @emph{hardcoded} values, as for
-deposit fees of the coins it uses. In order to work against the used
-exchange, those values MUST match the ones used by the exchange.
+When deploying Taler with the real banking system, you primarily need to
+change the currency of the configuration from KUDOS to the actual currency
+(such as EUR, USD, CHF) and provide a payto://-URI of your real bank
+account. In Europe, this will involve knowing your IBAN number. If you have an
+IBAN, the corresponding payto://-URI is simply “payto://iban/$IBAN” where
+“$IBAN” must be replaced with the actual IBAN number.
 
-The following example shows how the generator “sets” a deposit fee of
-EUR:0.01 for the 5 EURO coin.
+@node Setup,,IBAN Accounts,Instance setup
+@anchor{taler-merchant-manual setup}@anchor{32}
+@section Setup
+
+
+With the knowledge of the payto://-URI, instances can be configured by POSTing
+a request to @code{POST /private/instances}.  To create a first instance,
+create a file @code{instance.json} with an InstanceConfigurationMessage
 
 @example
-// from <merchant_repository>/src/sample/generate_payments.c
-@{ .oc = OC_PAY,
-  .label = "deposit-simple",
-  .expected_response_code = MHD_HTTP_OK,
-  .details.pay.contract_ref = "create-proposal-1",
-  .details.pay.coin_ref = "withdraw-coin-1",
-  .details.pay.amount_with_fee = concat_amount (currency, "5"),
-  .details.pay.amount_without_fee = concat_amount (currency, "4.99") @},
+@{
+  "payto_uris" : [ "$PAYTO_URI" ],
+  "id" : "default",
+  "name": "example.com",
+  "address": @{ "country" : "zz" @},
+  "jurisdiction": @{ "country" : "zz" @},
+  "default_max_wire_fee": "KUDOS:1",
+  "default_wire_fee_amortization": 100,
+  "default_max_deposit_fee": "KUDOS:1",
+  "default_wire_transfer_delay": @{ "d_ms" : 1209600000 @},
+  "default_pay_delay": @{ "d_ms" : 1209600000 @}
+@}
 @end example
 
-The logic calculates the deposit fee according to the subtraction:
-@code{amount_with_fee - amount_without_fee}.
+In the text above, you must replace “$PAYTO_URI” with your actual
+payto://-URI. Also, be sure to replace KUDOS with the fiat currency if the
+setup is for an actual bank. The “name” field will be shown as the name of
+your shop. The “address” field is expected to contain your shop’s physical
+address. The various defaults specify defaults for transaction fees your shop
+is willing to cover, how long offers made to the customer are valid, and how
+long the exchange has before it must wire the funds to your bank
+account. Those defaults can be modified for individual orders.
+For details, see the contract terms specification.
 
-The following example shows a 5 EURO coin configuration - needed by the
-used exchange - which is compatible with the hardcoded example above.
+You can then create the instance using:
 
 @example
-[COIN_eur_5]
-value = EUR:5
-duration_overlap = 5 minutes
-duration_withdraw = 7 days
-duration_spend = 2 years
-duration_legal = 3 years
-fee_withdraw = EUR:0.00
-fee_deposit = EUR:0.01 # important bit
-fee_refresh = EUR:0.00
-fee_refund = EUR:0.00
-rsa_keysize = 1024
+$ wget --post-file=instance.json http://localhost:8888/private/instances
 @end example
 
-If the command terminates with no errors, then the merchant backend is
-correctly installed.
+The base URL for the instance will then be
+@code{http://localhost:8888/instances/default}.  You can create additional
+instances by changing the “id” value to identifies other than “default”.
+
+Endpoints to modify (reconfigure), permanently disable (while keeping the data)
+or purge (deleting all associated data) instances exist as well and are documented
+in the Merchant Backend API documentation.
 
-After this operation is done, the merchant database will have some dummy
-data in it, so it may be convenient to clean all the tables; to this
-purpose, issue the following command:
+@node Secure setup,Customization,Instance setup,Top
+@anchor{taler-merchant-manual id11}@anchor{33}@anchor{taler-merchant-manual secure-setup}@anchor{9}
+@chapter Secure setup
+
+
+@geindex security
+
+@geindex TLS
+
+The Taler backend does not include even the most basic forms of
+access control or transport layer security.  Thus, production
+setups @strong{must} deploy the Taler backend behind an HTTP(S) server
+that acts as a @emph{reverse proxy}, performs TLS termination and
+authentication and then forwards requests to the backend.
+
+@menu
+* Using UNIX domain sockets:: 
+* Reverse proxy configuration:: 
+* Access control:: 
+
+@end menu
+
+@node Using UNIX domain sockets,Reverse proxy configuration,,Secure setup
+@anchor{taler-merchant-manual using-unix-domain-sockets}@anchor{34}
+@section Using UNIX domain sockets
+
+
+To ensure that the merchant backend is not exposed directly to the network,
+you @emph{should} bind the backend to a UNIX domain socket:
 
 @example
-$ taler-merchant-dbinit -r
+$ taler-config -s MERCHANT -o SERVE -V UNIX
+$ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock
 @end example
 
-@node Advanced topics,,Testing,Top
-@anchor{taler-merchant-manual advanced-topics}@anchor{20}
-@chapter Advanced topics
+Do not use a UNIX domain socket path in “/tmp”: systemd (or other init
+systems) may give Web servers a private “/tmp” thereby hiding UNIX domain
+sockets created by other users/processes in “/tmp”.
+
+If UNIX domain sockets are for some reason not possible, you @emph{may} use a
+host-based firewall to block access to the TCP port of the merchant backend,
+but this is @emph{not recommended}.  Relying on NAT or network firewalls for access
+control is gross negligence.
+
+@node Reverse proxy configuration,Access control,Using UNIX domain sockets,Secure setup
+@anchor{taler-merchant-manual reverse-proxy-configuration}@anchor{35}
+@section Reverse proxy configuration
 
 
 @menu
-* Configuration format:: 
-* Using taler-config:: 
-* Merchant key management:: 
-* Using the SEPA wire transfer method:: 
-* Tipping visitors:: 
-* Generate payments:: 
+* Nginx:: 
+* Apache:: 
 
 @end menu
 
-@node Configuration format,Using taler-config,,Advanced topics
-@anchor{taler-merchant-manual configuration-format}@anchor{21}
-@section Configuration format
+@node Nginx,Apache,,Reverse proxy configuration
+@anchor{taler-merchant-manual nginx}@anchor{36}
+@subsection Nginx
 
 
-configuration
-In Taler realm, any component obeys to the same pattern to get
-configuration values. According to this pattern, once the component has
-been installed, the installation deploys default values in
-$@{prefix@}/share/taler/config.d/, in .conf files. In order to override
-these defaults, the user can write a custom .conf file and either pass
-it to the component at execution time, or name it taler.conf and place
-it under $HOME/.config/.
-
-A config file is a text file containing sections, and each section
-contains its values. The right format follows:
+For Nginx, a possible basic reverse proxy configuration would be:
 
 @example
-[section1]
-value1 = string
-value2 = 23
-
-[section2]
-value21 = string
-value22 = /path22
+proxy_pass http://unix:/some/path/here.sock;
+proxy_redirect off;
+proxy_set_header Host $host;
+proxy_set_header X-Forwarded-Host "example.com";
+proxy_set_header X-Forwarded-Proto "https";
 @end example
 
-Throughout any configuration file, it is possible to use @code{$}-prefixed
-variables, like @code{$VAR}, especially when they represent filesystem
-paths. It is also possible to provide defaults values for those
-variables that are unset, by using the following syntax:
-@code{$@{VAR:-default@}}. However, there are two ways a user can set
-@code{$}-prefixable variables:
+Note that the above assumes your domain name is @code{example.com} and that you
+have TLS configured.  Leave out the last line if your Nginx reverse proxy does
+not have HTTPS enabled.  Make sure to restart the @code{taler-merchant-httpd}
+process after changing the @code{SERVE} configuration.
 
-by defining them under a @code{[paths]} section, see example below,
+@node Apache,,Nginx,Reverse proxy configuration
+@anchor{taler-merchant-manual apache}@anchor{37}
+@subsection Apache
+
+
+In Apache, make sure you have “mod_proxy”, “mod_proxy_http” and
+“mod_headers” enabled:
 
 @example
-[paths]
-TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
-..
-[section-x]
-path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
+$ a2enmod proxy
+$ a2enmod proxy_http
+$ a2enmod headers
 @end example
 
-or by setting them in the environment:
+Then configure your Apache reverse proxy like this (you may change the
+endpoint):
 
 @example
-$ export VAR=/x
+<Location "/">
+ProxyPass "unix:/some/path/here.sock|http://example.com/"
+RequestHeader add "X-Forwarded-Proto" "https"
+</Location>
 @end example
 
-The configuration loader will give precedence to variables set under
-@code{[path]}, though.
+Note that the above again assumes your domain name is @code{example.com} and that
+you have TLS configured.  Note that you must add the “https” header unless
+your site is not available via TLS.
 
-The utility @code{taler-config}, which gets installed along with the
-exchange, serves to get and set configuration values without directly
-editing the .conf. The option @code{-f} is particularly useful to resolve
-pathnames, when they use several levels of @code{$}-expanded variables. See
-@code{taler-config --help}.
+The above configuration(s) are both incomplete. You must still additionally
+setup access control!
 
-Note that, in this stage of development, the file
-@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
-component. For example, both an exchange and a bank can read values from
-it.
+@node Access control,,Reverse proxy configuration,Secure setup
+@anchor{taler-merchant-manual access-control}@anchor{38}
+@section Access control
 
-The repository @code{git://taler.net/deployment} contains examples of
-configuration file used in our demos. See under @code{deployment/config}.
 
-@quotation
+All endpoints with @code{/private/} in the URL must be restricted to authorized users
+of the respective instance.  Specifically, the HTTP server must be configured
+to only allow access to @code{$BASE_URL/private/} to the authorized users of the
+default instance, and to @code{$BASE_URL/instances/$ID/private/} to the
+authorized users of the instance @code{$ID}.
 
-@strong{Note}
+How access control is done (TLS client authentication, HTTP basic or digest
+authentication, etc.) is completely up to the merchant and does not matter to
+the Taler merchant backend.
 
-Expectably, some components will not work just by using default
-values, as their work is often interdependent. For example, a
-merchant needs to know an exchange URL, or a database name.
-@end quotation
+Note that all of the other endpoints (without @code{/private/}) are expected to be
+fully exposed to the Internet, and wallets may have to interact with those
+endpoints directly without client authentication.
 
-@node Using taler-config,Merchant key management,Configuration format,Advanced topics
-@anchor{taler-merchant-manual using-taler-002dconfig}@anchor{22}@anchor{taler-merchant-manual using-taler-config}@anchor{23}
-@section Using taler-config
+@menu
+* Nginx: Nginx<2>. 
+* Apache: Apache<2>. 
 
+@end menu
 
-taler-config
-The tool @code{taler-config} can be used to extract or manipulate
-configuration values; however, the configuration use the well-known INI
-file format and can also be edited by hand.
+@node Nginx<2>,Apache<2>,,Access control
+@anchor{taler-merchant-manual id12}@anchor{39}
+@subsection Nginx
 
-Run
+
+For Nginx, you can implement token-based merchant backend authentication as
+follows:
 
 @example
-$ taler-config -s $SECTION
+location ~ /private/ @{
+    if ($http_authorization !~ "(?i)ApiKey SECURITYTOKEN") @{
+       return 401;
+    @}
+    proxy_pass ...; // as above
+@}
 @end example
 
-to list all of the configuration values in section @code{$SECTION}.
+Here, “SECURITYTOKEN” should be replaced with the actual shared secret.  Note
+that the “~” ensures that the above matches all endpoints that include the
+string “/private/”.  If you only run a single instance, you could simply
+specify “/private/” without the “~” to only configure the access policy for
+the default instance.
 
-Run
+If you are running different instances on the same backend, you
+likely will want to specify different access control tokens for
+each instance:
 
 @example
-$ taler-config -s $section -o $option
+location ~ ^/instances/foo/private/ @{
+    if ($http_authorization !~ "(?i)ApiKey FOOTOKEN") @{
+       return 401;
+    @}
+    proxy_pass ...; // as above
+@}
+location ~ ^/instances/bar/private/ @{
+    if ($http_authorization !~ "(?i)ApiKey BARTOKEN") @{
+       return 401;
+    @}
+    proxy_pass ...; // as above
+@}
+location /private/ @{
+    if ($http_authorization !~ "(?i)ApiKey MASTERTOKEN") @{
+       return 401;
+    @}
+    proxy_pass ...; // as above
+@}
+location ~ /private/ @{
+    return 401; // access to instances not explicitly configured is forbidden
+@}
 @end example
 
-to extract the respective configuration value for option @code{$option} in
-section @code{$section}.
+@node Apache<2>,,Nginx<2>,Access control
+@anchor{taler-merchant-manual id13}@anchor{3a}
+@subsection Apache
 
-Finally, to change a setting, run
+
+For Apache, you should first enable “mod_rewrite”:
 
 @example
-$ taler-config -s $section -o $option -V $value
+$ a2enmod rewrite
 @end example
 
-to set the respective configuration value to @code{$value}. Note that you
-have to manually restart the Taler backend after you change the
-configuration to make the new configuration go into effect.
+Then, you can restrict to an access control token using:
 
-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
+<Location "/">
+RewriteEngine On
+RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=SECURITYTOKEN"
+RewriteRule "(.+)/private/" "-" [F]
+
+ProxyPass "unix:/some/path/here.sock|http://example.com/"
+</Location>
+@end example
+
+Here, “SECURITYTOKEN” should be replaced with the actual shared secret.  Note
+that the “(.+)” ensures that the above matches all endpoints that include the
+string “/private/”.  If you only run a single instance, you could simply
+specify “/private/” without the “~” to only configure the access policy for
+the default instance.
+
+If you are running different instances on the same backend, you
+likely will want to specify different access control tokens for
+each instance:
 
 @example
-$ taler-config -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
-$ taler-config -f -s ACCOUNT-bank \
-               -o WIRE_RESPONSE
+<Location "/instances/foo/">
+RewriteEngine On
+RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=FOOTOKEN"
+RewriteRule "/instances/foo/private/" "-" [F]
+
+ProxyPass ... # as above
+</Location>
+
+<Location "/instances/bar/">
+RewriteEngine On
+RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=BARTOKEN"
+RewriteRule "/instances/bar/private/" "-" [F]
+
+ProxyPass ... # as above
+</Location>
+
+<Location "/">
+RewriteEngine On
+RewriteCond "%@{HTTP:AUTHORIZATION@}" "!=MASTERTOKEN"
+RewriteRule "/private/" "-" [F]
+RewriteRule "(.+)/private/" "-" [F] # reject all others
+
+ProxyPass ... # as above
+</Location>
 @end example
 
-While the configuration file is typically located at
-@code{$HOME/.config/taler.conf}, an alternative location can be specified
-to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
-option.
+Please note that these are simply examples of how one could use Nginx or
+Apache2 for access control. Both HTTP servers support many other forms of
+authentication, including TLS client certificates, HTTP basic and digest
+authentication and others, which can all be used (possibly in combination) to
+restrict access to the internal API to authorized clients.
 
-@node Merchant key management,Using the SEPA wire transfer method,Using taler-config,Advanced topics
-@anchor{taler-merchant-manual id13}@anchor{24}@anchor{taler-merchant-manual merchant-key-management}@anchor{25}
-@section Merchant key management
+System admininistrators are strongly advised to test their access control
+setup before going into production!
 
+@node Customization,Upgrade procedure,Secure setup,Top
+@anchor{taler-merchant-manual customization}@anchor{3b}
+@chapter Customization
 
-merchant key
-KEYFILE
-The option “KEYFILE” in the section “INSTANCE-default” specifies the
-path to the instance’s private key. You do not need to create a key
-manually, the backend will generate it automatically if it is missing.
-While generally unnecessary, it is possible to display the corresponding
-public key using the @code{gnunet-ecc} command-line tool:
 
-@example
-$ gnunet-ecc -p                                  \
-  $(taler-config -f -s INSTANCE-default \
-                 -o KEYFILE)
-@end example
+@menu
+* Templates:: 
+* Static files:: 
+* Internationalization:: 
+* Limitations:: 
 
-@node Using the SEPA wire transfer method,Tipping visitors,Merchant key management,Advanced topics
-@anchor{taler-merchant-manual sepa-configuration}@anchor{26}@anchor{taler-merchant-manual using-the-sepa-wire-transfer-method}@anchor{27}
-@section Using the SEPA wire transfer method
+@end menu
 
+@node Templates,Static files,,Customization
+@anchor{taler-merchant-manual templates}@anchor{3c}
+@section Templates
 
-SEPA
-EBICS
-The following is a sample configuration for the SEPA wire transfer
-method: @footnote{@w{(2)} 
-Supporting SEPA is still work in progress; the backend will accept
-this configuration, but the exchange will not work with SEPA today.
-}.
 
-Then, to configure the EBICS backend for SEPA payments in EUR, the
-following configuration options need to be set:
+The installation process will install various HTML templates to be served
+to trigger the wallet interaction. You may change those templates to your
+own design. The templating language used is Mustach, and the templates
+are in the @code{share/taler/merchant/templates/} directory.
 
-@example
-$ taler-config -s TALER -o CURRENCY -V EUR
-$ taler-config -s ACCOUNT-e -o PLUGIN -V ebics
-$ taler-config -s ACCOUNT-e -o URL \
- -V payto://sepa/XY00111122223333444455556666
-$ taler-config -s ACCOUNT-e -o WIRE_RESPONSE
- -V '$@{DATADIR@}/b.json'
-@end example
+@node Static files,Internationalization,Templates,Customization
+@anchor{taler-merchant-manual static-files}@anchor{3d}
+@section Static files
 
-Please note that you will also have to configure an exchange and/or
-auditors that support SEPA. However, we cannot explain how to do this
-yet as such entities do not yet exist. Once such entities do exist, we
-expect future versions of the Taler backend to ship with pre-configured
-exchanges and auditors for common denominations.
 
-@node Tipping visitors,Generate payments,Using the SEPA wire transfer method,Advanced topics
-@anchor{taler-merchant-manual id15}@anchor{28}@anchor{taler-merchant-manual tipping-visitors}@anchor{29}
-@section Tipping visitors
+The merchant backend also has the ability to serve small static files
+under the @code{/static/@{FILENAME@}} endpoint.  This is used by the templating
+logic to load a CSS file, but you can also put other resources such as
+images or JavaScript.
 
+@node Internationalization,Limitations,Static files,Customization
+@anchor{taler-merchant-manual internationalization}@anchor{3e}
+@section Internationalization
 
-tipping
-Taler can also be used to tip Web site visitors. For example, you may be
-running an online survey, and you want to reward those people that have
-dutifully completed the survey. If they have installed a Taler wallet,
-you can provide them with a tip for their deeds. This section describes
-how to setup the Taler merchant backend for tipping.
 
-There are four basic steps that must happen to tip a visitor.
+Both templates and static files can be internationalized.  This is done
+by having the language of the resource be a part of the filename.
+For templates the format is @code{@{BASENAME@}.@{LANGUAGE@}.must}.  The
+language is mandatory for templates, the default language is English (en).
 
-@menu
-* Configure a reserve and exchange for tipping:: 
-* Fund the reserve:: 
-* Authorize a tip:: 
-* Picking up of the tip:: 
+For static files, the format is @code{@{BASENAME@}.@{LANGUAGE@}.@{EXT@}} for
+internationalized files, and @code{@{BASENAME@}.@{EXT@}} for resources that do not
+support internationalization.  The HTTP client will always request
+@code{/static/@{BASENAME@}.@{EXT@}}. If @code{@{BASENAME@}.@{EXT@}} exists, that resource is
+returned. Otherwise, an internationalized file based on the language
+preferences indicated by the browser is returned.
 
-@end menu
+@node Limitations,,Internationalization,Customization
+@anchor{taler-merchant-manual limitations}@anchor{3f}
+@section Limitations
 
-@node Configure a reserve and exchange for tipping,Fund the reserve,,Tipping visitors
-@anchor{taler-merchant-manual configure-a-reserve-and-exchange-for-tipping}@anchor{2a}@anchor{taler-merchant-manual id16}@anchor{2b}
-@subsection Configure a reserve and exchange for tipping
 
+All of the static files must fit into memory and it must be possible for the
+process to hold open file handles for all of these files.  You may want
+to increase the “ulimit” of the @code{taler-merchant-httpd} process if you have
+templates for many languages.
 
-gnunet-ecc
-reserve key
-To tip users, you first need to create a reserve. A reserve is a pool of
-money held in escrow at the Taler exchange. This is the source of the
-funds for the tips. Tipping will fail (resulting in disappointed
-visitors) if you do not have enough funds in your reserve!
+The backend determines the MIME type based on the file’s extension. The list
+of supported extensions is hard-coded and includes common text and image
+formats.
 
-First, we configure the backend. You need to enable tipping for each
-instance separately, or you can use an instance only for tipping. To
-configure the “default” instance for tipping, use the following
-configuration:
+The current backend only provides a limited set of variables for the Mustach
+template expansion, and does not make use of scopes and other Mustach
+features.
 
-@example
-[INSTANCE-default]
-# this is NOT the tip.priv
-KEYFILE = signing_key.priv
-# replace the URL with the URL of the exchange you will use
-TIP_EXCHANGE = https://exchange:443/
-# here put the path to the file created with "gnunet-ecc -g1 tip.priv"
-TIP_RESERVE_PRIV_FILENAME = tip.priv
-@end example
+@node Upgrade procedure,Tipping visitors,Customization,Top
+@anchor{taler-merchant-manual upgrade-procedure}@anchor{40}
+@chapter Upgrade procedure
+
+
+This is the general upgrade procedure.  Please see the release notes
+for your specific version to check if a particular release has special
+upgrade requirements.
 
-Note that the KEYFILE option should have already been present for the
-instance. It has nothing to do with the “tip.priv” file we created
-above, and you should probably use a different file here.
+Please note that upgrades are ONLY supported for released version of the
+merchant. Attempting to upgrade from or to a version in Git is not supported
+and may result in subtle data loss.
 
-Instead of manually editing the configuration, you could also run:
+To safely upgrade the merchant, you should first stop the existing
+@code{taler-merchant-httpd} process, backup your merchant database (see Postgres
+manual), and then install the latest version of the code.
+
+If you REVOKED database permissions, ensure that the rights to CREATE,
+DROP, and ALTER tables are GRANTed to @code{$USER} again.  Then, run:
 
 @example
-$ taler-config -s INSTANCE-default \
-    -o TIP_RESERVE_PRIV_FILENAME \
-    -V tip.priv
-$ taler-config -s INSTANCE-default \
-    -o TIP_EXCHANGE \
-    -V https://exchange:443/
+$ taler-merchant-dbinit
 @end example
 
-Next, to create the @code{TIP_RESERVE_PRIV_FILENAME} file, use:
+to upgrade the database to the latest schema.  After that, you may again
+REVOKE the database permissions. Finally, restart the HTTP service, either via
+your systemd or init system, or directly using:
 
 @example
-$ gnunet-ecc -g 1   \
-  $(taler-config -f -s INSTANCE-default \
-      -o TIP-RESERVE_PRIV_FILENAME)
+$ taler-merchant-httpd
 @end example
 
-This will create a file with the private key that will be used to
-identify the reserve. You need to do this once for each instance that is
-configured to tip.
+@node Tipping visitors,Advanced topics,Upgrade procedure,Top
+@anchor{taler-merchant-manual id14}@anchor{41}@anchor{taler-merchant-manual tipping-visitors}@anchor{42}
+@chapter Tipping visitors
+
+
+@geindex tipping
+
+Taler can also be used to tip Web site visitors. For example, you may be
+running an online survey, and you want to reward those people that have
+dutifully completed the survey. If they have installed a Taler wallet,
+you can provide them with a tip for their deeds. This section describes
+how to setup the Taler merchant backend for tipping.
+
+There are three basic steps that must happen to tip a visitor.
+
+@menu
+* Fund the reserve:: 
+* Authorize a tip:: 
+* Picking up of the tip:: 
+
+@end menu
 
-Now you can (re)start the backend with the new configuration.
+@node Fund the reserve,Authorize a tip,,Tipping visitors
+@anchor{taler-merchant-manual fund-the-reserve}@anchor{43}@anchor{taler-merchant-manual id15}@anchor{44}
+@section Fund the reserve
 
-@node Fund the reserve,Authorize a tip,Configure a reserve and exchange for tipping,Tipping visitors
-@anchor{taler-merchant-manual fund-the-reserve}@anchor{2c}@anchor{taler-merchant-manual id17}@anchor{2d}
-@subsection Fund the reserve
 
+@geindex reserve
 
-reserve
-close
-To fund the reserve, you must first extract the public key from
-“tip.priv”:
+First, the reserve must be setup in the merchant backend. A reserve
+is always tied to a particular instance. To create a reserve with
+10 KUDOS at instance “default” using the demo exchange, use:
 
 @example
-$ gnunet-ecc --print-public-key \
-  $(taler-config -f -s INSTANCE-default \
-      -o TIP-RESERVE_PRIV_FILENAME)
+$ taler-merchant-setup-reserve \
+    -a KUDOS:10 \
+    -e https://exchange.demo.taler.net/ \
+    -m http://localhost:8888/instances/default
 @end example
 
-In our example, the output for the public key is:
+The above command assumes that the merchant runs on localhost on
+port 8888. The current implementation of the tool does not yet support
+transmission of authentication information to the backend
+(see bug 6418@footnote{https://bugs.gnunet.org/view.php?id=6418}).
+
+The command will output a payto:// URI which specifies where to
+wire the funds and which wire transfer subject to use.
+
+FIXME: add full example output.
+
+In our example, the output for the wire transfer subject is:
 
 @example
 QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG
 @end example
 
 You now need to make a wire transfer to the exchange’s bank account
-using the public key as the wire transfer subject. The exchange’s bank
-account details can be found in JSON format at
-“@indicateurl{https://exchange:443//wire/METHOD}” where METHOD is the respective wire
-method (i.e. “sepa”). Depending on the exchange’s operator, you may also
-be able to find the bank details in a human-readable format on the main
-page of the exchange.
+using the given wire transfer subject.
 
 Make your wire transfer and (optionally) check at
-“@indicateurl{https://exchange:443/reserve/status/reserve_pub=QPE24X}…” whether your
-transfer has arrived at the exchange.
+“@indicateurl{https://exchange/reserves/QPE24X}…” whether your transfer has arrived at the
+exchange.
 
 Once the funds have arrived, you can start to use the reserve for
 tipping.
 
-Note that an exchange will typically close a reserve after four weeks,
-wiring all remaining funds back to the sender’s account. Thus, you
-should plan to wire funds corresponding to a campaign of about two weeks
-to the exchange initially. If your campaign runs longer, you should wire
-further funds to the reserve every other week to prevent it from
-expiring.
+Note that an exchange will typically close a reserve after four weeks, wiring
+all remaining funds back to the sender’s account. Thus, you should plan to
+wire funds corresponding to a campaign of about two weeks to the exchange
+initially. If your campaign runs longer, you should setup another reserve
+every other week to ensure one is always ready.
 
 @node Authorize a tip,Picking up of the tip,Fund the reserve,Tipping visitors
-@anchor{taler-merchant-manual authorize-a-tip}@anchor{2e}@anchor{taler-merchant-manual id18}@anchor{2f}
-@subsection Authorize a tip
+@anchor{taler-merchant-manual authorize-a-tip}@anchor{45}@anchor{taler-merchant-manual id16}@anchor{46}
+@section Authorize a tip
 
 
-When your frontend has reached the point where a client is supposed to
-receive a tip, it needs to first authorize the tip. For this, the
-frontend must use the “/tip-authorize” API of the backend. To authorize
-a tip, the frontend has to provide the following information in the body
-of the POST request:
+When your frontend has reached the point where a client is supposed to receive
+a tip, it needs to first authorize the tip. For this, the frontend must use
+the @code{POST /private/reserves/$RESERVE_PUB/authorize-tip}
+API of the backend. To authorize a
+tip, the frontend has to provide the following information in the body of the
+POST request:
 
 
 @itemize -
@@ -1354,57 +1900,406 @@ in a special “402 Payment Required” response inside the @code{X-Taler-Tip}
 header.
 
 The frontend should handle errors returned by the backend, such as
-missconfigured instances or a lack of remaining funds for tipping.
+misconfigured instances or a lack of remaining funds for tipping.
 
 @node Picking up of the tip,,Authorize a tip,Tipping visitors
-@anchor{taler-merchant-manual id19}@anchor{30}@anchor{taler-merchant-manual picking-up-of-the-tip}@anchor{31}
-@subsection Picking up of the tip
+@anchor{taler-merchant-manual id17}@anchor{47}@anchor{taler-merchant-manual picking-up-of-the-tip}@anchor{48}
+@section Picking up of the tip
 
 
-The wallet will POST a JSON object to the shop’s “/tip-pickup” handler.
+The wallet will POST a JSON object to the shop’s
+@code{POST /tips/$TIP_ID/pickup} handler.
 The frontend must then forward this request to the backend. The response
 generated by the backend can then be forwarded directly to the wallet.
 
-@node Generate payments,,Tipping visitors,Advanced topics
-@anchor{taler-merchant-manual generate-payments}@anchor{32}@anchor{taler-merchant-manual id20}@anchor{33}
-@section Generate payments
+@node Advanced topics,Advanced experimental features,Tipping visitors,Top
+@anchor{taler-merchant-manual advanced-topics}@anchor{49}
+@chapter Advanced topics
+
+
+@menu
+* Database Scheme:: 
+* Configuration format: Configuration format<2>. 
+
+@end menu
+
+@node Database Scheme,Configuration format<2>,,Advanced topics
+@anchor{taler-merchant-manual database-scheme}@anchor{4a}@anchor{taler-merchant-manual merchantdatabasescheme}@anchor{4b}
+@section Database Scheme
+
+
+The merchant database must be initialized using @code{taler-merchant-dbinit}.
+This tool creates the tables required by the Taler merchant to operate.
+The tool also allows you to reset the Taler merchant database, which is
+useful for test cases but should never be used in production. Finally,
+@code{taler-merchant-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 merchant looks as follows:
+
+@image{taler-merchant-figures/merchant-db,,,,png}
+
+@node Configuration format<2>,,Database Scheme,Advanced topics
+@anchor{taler-merchant-manual id18}@anchor{4c}
+@section Configuration format
+
+
+@geindex configuration
+
+In Taler realm, any component obeys to the same pattern to get
+configuration values. According to this pattern, once the component has
+been installed, the installation deploys default values in
+@code{$@{prefix@}/share/taler/config.d/}, in @code{.conf} files. In order to override
+these defaults, the user can write a custom .conf file and either pass
+it to the component at execution time, or name it @code{taler.conf} and place
+it under @code{$HOME/.config/}.
+
+A config file is a text file containing sections, and each section
+contains its values. The right format follows:
+
+@example
+[section1]
+value1 = string
+value2 = 23
+
+[section2]
+value21 = string
+value22 = /path22
+@end example
+
+Throughout any configuration file, it is possible to use @code{$}-prefixed
+variables, like @code{$VAR}, especially when they represent filesystem
+paths. It is also possible to provide defaults values for those
+variables that are unset, by using the following syntax:
+@code{$@{VAR:-default@}}. However, there are two ways a user can set
+@code{$}-prefixable variables:
+
+by defining them under a @code{[paths]} section, see example below,
+
+@example
+[paths]
+TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
+...
+[section-x]
+path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
+@end example
+
+or by setting them in the environment:
+
+@example
+$ export VAR=/x
+@end example
+
+The configuration loader will give precedence to variables set under
+@code{[path]}, though.
+
+The utility @code{taler-config}, which gets installed along with the
+exchange, serves to get and set configuration values without directly
+editing the @code{.conf}. The option @code{-f} is particularly useful to resolve
+pathnames, when they use several levels of @code{$}-expanded variables. See
+@code{taler-config --help}.
+
+Note that, in this stage of development, the file
+@code{$HOME/.config/taler.conf} can contain sections for @emph{all} the
+components. For example, both an exchange and a bank can read values from
+it.
+
+The deployment repository@footnote{https://git.taler.net/deployment} contains examples of
+configuration file used in our demos. See under @code{deployment/config}.
+
+@quotation
+
+@strong{Note}
+
+Expectably, some components will not work just by using default
+values, as their work is often interdependent. For example, a
+merchant needs to know an exchange URL, or a database name.
+@end quotation
+
+@menu
+* Using taler-config: Using taler-config<2>. 
+
+@end menu
+
+@node Using taler-config<2>,,,Configuration format<2>
+@anchor{taler-merchant-manual id19}@anchor{4d}@anchor{taler-merchant-manual using-taler-002dconfig}@anchor{4e}
+@subsection Using taler-config
+
+
+@geindex taler-config
+
+The tool @code{taler-config} can be used to extract or manipulate
+configuration values; however, the configuration use the well-known INI
+file format and can also be edited by hand.
+
+Run
+
+@example
+$ taler-config -s $SECTION
+@end example
+
+to list all of the configuration values in section @code{$SECTION}.
+
+Run
+
+@example
+$ taler-config -s $section -o $option
+@end example
+
+to extract the respective configuration value for option @code{$option} in
+section @code{$section}.
+
+Finally, to change a setting, run
+
+@example
+$ taler-config -s $section -o $option -V $value
+@end example
+
+to set the respective configuration value to @code{$value}. Note that you
+have to manually restart the Taler backend after you change the
+configuration to make the new configuration go into effect.
+
+Some default options will use @code{$}-variables, such as @code{$DATADIR} within
+their value. To expand the @code{$DATADIR} or other @code{$}-variables in the
+configuration, pass the @code{-f} option to @code{taler-config}. For example,
+compare:
+
+@example
+$ taler-config -s PATHS \
+               -o TALER_DATA_HOME
+$ taler-config -f -s PATHS \
+               -o TALER_DATA_HOME
+@end example
+
+While the configuration file is typically located at
+@code{$HOME/.config/taler.conf}, an alternative location can be specified
+to @code{taler-merchant-httpd} and @code{taler-config} using the @code{-c}
+option.
+
+@node Advanced experimental features,Temporarily Abandoned Features,Advanced topics,Top
+@anchor{taler-merchant-manual advanced-experimental-features}@anchor{4f}
+@chapter Advanced experimental features
+
+
+This section describes features that most merchants will not
+need, or will not need initially.
+
+@menu
+* Benchmarking:: 
+* Benchmark setup:: 
+* Running the benchmark command:: 
+
+@end menu
+
+@node Benchmarking,Benchmark setup,,Advanced experimental features
+@anchor{taler-merchant-manual benchmarking}@anchor{50}@anchor{taler-merchant-manual merchantbenchmarking}@anchor{51}
+@section Benchmarking
 
 
-testing database
 The merchant codebase offers the @code{taler-merchant-benchmark} tool to
 populate the database with fake payments. This tool is in charge of
 starting a merchant, exchange, and bank processes, and provide them all
 the input to accomplish payments. Note that each component will use its
 own configuration (as they would do in production).
 
-The tool takes all of the values it needs from the command line, with
-some of them being mandatory. Among those, we have:
+The main goal of the benchmarking tool is to serve as a starting point (!) for
+merchants that are interested in developing stress tests to see how far their
+infrastructure can scale.
+
+The current tool has already a few options, but we expect that to deliver
+@emph{relevant} results it will need to be customized to better reflect the
+workload of a particular merchant.  This customization would at this point
+likely involve writing (C) code.  We welcome contributions to make it easier
+to customize the benchmark and/or to cover more realistic workloads from the
+start.
+
+@node Benchmark setup,Running the benchmark command,Benchmarking,Advanced experimental features
+@anchor{taler-merchant-manual benchmark-setup}@anchor{52}
+@section Benchmark setup
+
+
+The @code{taler-merchant-benchmark} tool will automatically launch and configure the
+exchange, (Python) bank and other tools required for the benchmark. However,
+the configuration file must be provided and have consistent options set.  The
+options that require special care include the exchange’s public key (which
+must match the private key in the file specified by the configuration), the
+currency (which must be consistent across the file), the denomination
+structure (which must enable payments in the range of 100ths of the unit
+currency (often called cents)). Furthermore, the benchmark will set the
+Exchange bank account password to be “x”, so the configuration must also
+specify “x” for the passphrase.  Finally, the bank must be configured to allow
+for substantial debt least the transactions by the benchmark run out of
+digital cash.
+
+A relatively minimal configuration could look like this:
+
+@example
+[PATHS]
+# Persistent data storage for the benchmark
+TALER_TEST_HOME = benchmark_home/
+
+[taler]
+# If you change the currency here, you MUST change it
+# throughout the file.
+CURRENCY = EUR
+CURRENCY_ROUND_UNIT = EUR:0.01
+
+[merchant]
+SERVE = tcp
+PORT = 8080
+DB = postgres
+
+[merchantdb-postgres]
+CONFIG = postgres:///talercheck
+
+[exchange]
+DB = postgres
+SERVE = tcp
+PORT = 8081
+BASE_URL = http://localhost:8081/
+MASTER_PUBLIC_KEY = T1VVFQZZARQ1CMF4BN58EE7SKTW5AV2BS18S87ZEGYS4S29J6DNG
+
+[exchangedb-postgres]
+CONFIG = postgres:///talercheck
+
+[auditor]
+DB = postgres
+SERVE = tcp
+PORT = 8083
+BASE_URL = http://the.auditor/
+
+[auditordb-postgres]
+CONFIG = postgres:///talercheck
+
+[bank]
+DATABASE = postgres:///talerbank
+SERVE = http
+HTTP_PORT = 8082
+MAX_DEBT = EUR:5000.0
+MAX_DEBT_BANK = EUR:0.0
+
+[merchant-exchange-test]
+MASTER_KEY = T1VVFQZZARQ1CMF4BN58EE7SKTW5AV2BS18S87ZEGYS4S29J6DNG
+EXCHANGE_BASE_URL = http://localhost:8081/
+CURRENCY = EUR
+
+[exchange-account-exchange]
+# The account name MUST be 'Exchange'
+PAYTO_URI = payto://x-taler-bank/localhost/Exchange
+WIRE_RESPONSE = $@{TALER_CONFIG_HOME@}/exchange/account.json
+WIRE_GATEWAY_URL = http://localhost:8082/taler-wire-gateway/Exchange/
+WIRE_GATEWAY_AUTH_METHOD = basic
+USERNAME = Exchange
+# The password MUST be 'x'
+PASSWORD = x
+ENABLE_DEBIT = YES
+ENABLE_CREDIT = YES
+
+[fees-x-taler-bank]
+WIRE-FEE-2020 = EUR:0.01
+WIRE-FEE-2021 = EUR:0.01
+WIRE-FEE-2022 = EUR:0.01
+WIRE-FEE-2023 = EUR:0.01
+WIRE-FEE-2024 = EUR:0.01
+WIRE-FEE-2025 = EUR:0.01
+WIRE-FEE-2026 = EUR:0.01
+WIRE-FEE-2027 = EUR:0.01
+CLOSING-FEE-2020 = EUR:0.01
+CLOSING-FEE-2021 = EUR:0.01
+CLOSING-FEE-2022 = EUR:0.01
+CLOSING-FEE-2023 = EUR:0.01
+CLOSING-FEE-2024 = EUR:0.01
+CLOSING-FEE-2025 = EUR:0.01
+CLOSING-FEE-2026 = EUR:0.01
+CLOSING-FEE-2027 = EUR:0.01
+
+[coin_eur_ct_1]
+value = EUR:0.01
+duration_withdraw = 7 days
+duration_spend = 2 years
+duration_legal = 3 years
+fee_withdraw = EUR:0.00
+fee_deposit = EUR:0.00
+fee_refresh = EUR:0.01
+fee_refund = EUR:0.01
+rsa_keysize = 1024
 
+[coin_eur_ct_10]
+value = EUR:0.10
+duration_withdraw = 7 days
+duration_spend = 2 years
+duration_legal = 3 years
+fee_withdraw = EUR:0.01
+fee_deposit = EUR:0.01
+fee_refresh = EUR:0.03
+fee_refund = EUR:0.01
+rsa_keysize = 1024
 
-@itemize -
+[coin_eur_1]
+value = EUR:1
+duration_withdraw = 7 days
+duration_spend = 2 years
+duration_legal = 3 years
+fee_withdraw = EUR:0.01
+fee_deposit = EUR:0.01
+fee_refresh = EUR:0.03
+fee_refund = EUR:0.01
+rsa_keysize = 1024
 
-@item 
-@code{--currency=K} Use currency @emph{K}, for example to craft coins to
-withdraw.
+[coin_eur_5]
+value = EUR:5
+duration_withdraw = 7 days
+duration_spend = 2 years
+duration_legal = 3 years
+fee_withdraw = EUR:0.01
+fee_deposit = EUR:0.01
+fee_refresh = EUR:0.03
+fee_refund = EUR:0.01
+rsa_keysize = 1024
+
+@end example
+
+Note that the public key must match the exchange’s
+private key and that the Postgres database must
+exist before launching the benchmark.  You also
+will need to ensure that the Exchange’s
+details are setup, usually by running
+
+@example
+$ taler-exchange-wire -c $CONFIG_FILE
+$ taler-exchange-keyup -c $CONFIG_FILE
+@end example
+
+where “$CONFIG_FILE” should be replaced by
+the configuration file that is to be used.
+
+@node Running the benchmark command,,Benchmark setup,Advanced experimental features
+@anchor{taler-merchant-manual running-the-benchmark-command}@anchor{53}
+@section Running the benchmark command
 
-@item 
-@code{--bank-url=URL} Assume that the bank is serving under the base URL
-@emph{URL}. This option is only actually used by the tool to check if the
-bank was well launched.
+
+The tool takes all of the values it needs from the command line, with
+one of them being mandatory:
+
+
+@itemize -
 
 @item 
-@code{--merchant-url=URL} Reach the merchant through @emph{URL}, for
-downloading contracts and sending payments.
+@code{--exchange-account=SECTION} Specifies which configuration
+section specifies the bank account for the exchange that
+should be used for the benchmark. For the example
+configuration above, the SECTION value provided must be
+“exchange-account-exchange”.
 @end itemize
 
-The tool then comes with two operation modes: @emph{ordinary}, and @emph{corner}.
+The tool comes with two operation modes: @emph{ordinary}, and @emph{corner}.
 The first just executes normal payments, meaning that it uses the
 default instance and make sure that all payments get aggregated. The
 second gives the chance to leave some payments unaggregated, and also to
 use merchant instances other than the default (which is, actually, the
 one used by default by the tool).
 
-Note: the abilty of driving the aggregation policy is useful for testing
+Note: the ability of driving the aggregation policy is useful for testing
 the backoffice facility.
 
 Any subcommand is also equipped with the canonical @code{--help} option, so
@@ -1429,11 +2324,6 @@ spent per payment.
 @item 
 @code{--unaggregated-number=UN} This option instructs the tool to
 perform @emph{UN} (one coin) payments that will be left unaggregated.
-
-@item 
-@code{--alt-instance=AI} This option instructs the tool to perform
-payments using the merchant instance @emph{AI} (instead of the @emph{default}
-instance)
 @end itemize
 
 As for the @code{ordinary} subcommand, it is worth explaining the following
@@ -1452,10 +2342,83 @@ times @emph{TN}, since “one” tracking operation accounts for
 @code{/track/transaction} and @code{/track/transfer}. This command should
 only be used to see if the operation ends without problems, as no
 actual measurement of performance is provided (despite of the
-’benchmark’ work used in the tool’s name).
+’benchmark’ word used in the tool’s name).
 @end itemize
-@anchor{taler-merchant-manual Using-taler_002dconfig}@w{                              }
-@anchor{17}@w{                              }
+
+@node Temporarily Abandoned Features,Index,Advanced experimental features,Top
+@anchor{taler-merchant-manual temporarily-abandoned-features}@anchor{54}
+@chapter Temporarily Abandoned Features
+
+
+@menu
+* Installing Taler using Docker:: 
+
+@end menu
+
+@node Installing Taler using Docker,,,Temporarily Abandoned Features
+@anchor{taler-merchant-manual installing-taler-using-docker}@anchor{55}
+@section Installing Taler using Docker
+
+
+This section provides instructions for the merchant backend installation
+using ‘Docker‘.
+
+For security reasons, we run Docker against a VirtualBox instance, so
+the @code{docker} command should connect to a @code{docker-machine} instance
+that uses the VirtualBox driver.
+
+Therefore, the needed tools are: “docker“, “docker-machine“, and
+“docker-compose“. Please refer to Docker’s official  @footnote{@w{(1)} 
+@indicateurl{https://docs.docker.com/}
+} documentation
+in order to get those components installed, as that is not in this
+manual’s scope.
+
+Before starting to build the merchant’s image, make sure a
+“docker-machine“ instance is up and running.
+
+Because all of the Docker source file are kept in our “deployment“
+repository, we start by checking out the @code{git://git.taler.net/deployment}
+codebase:
+
+@example
+$ git clone git://git.taler.net/deployment
+@end example
+
+Now we actually build the merchant’s image. From the same directory as
+above:
+
+@example
+$ cd deployment/docker/merchant/
+$ docker-compose build
+@end example
+
+If everything worked as expected, the merchant is ready to be launched.
+From the same directory as the previous step:
+
+@example
+# Recall: the docker-machine should be up and running.
+$ docker-compose up
+@end example
+
+You should see some live logging from all the involved containers. At
+this stage of development, you should also ignore some (harmless) error
+message from postresql about already existing roles and databases.
+
+To test if everything worked as expected, it suffices to issue a simple
+request to the merchant, as:
+
+@example
+$ curl http://$(docker-machine ip)/
+# A greeting message should be returned by the merchant.
+@end example
+
+@node Index,,Temporarily Abandoned Features,Top
+@unnumbered Index
+
+
+@printindex ge
+
 
 @c %**end of body
 @bye