diff options
| -rw-r--r-- | design-documents/011-auditor-db-sync.rst | 4 | ||||
| -rw-r--r-- | taler-exchange-manual.rst | 13 |
2 files changed, 12 insertions, 5 deletions
diff --git a/design-documents/011-auditor-db-sync.rst b/design-documents/011-auditor-db-sync.rst index aba7b503..34432985 100644 --- a/design-documents/011-auditor-db-sync.rst +++ b/design-documents/011-auditor-db-sync.rst @@ -78,7 +78,7 @@ Proposed Solution tables from other data *if* we need to recover from backup. * On schema migration, halt exchange, once auditor DB has synchronized, update all DB schema (the "ingress" DB schema - may be update automatically when the exchange DB schema is + may be updated automatically when the exchange DB schema is migrated, but the "trusted" DB of the auditor must most likely be manually migrated), then finally resume "ingress" to "trusted" helper-based DB synchronization and restart the exchange. @@ -159,7 +159,7 @@ Drawbacks is the answer, to be investigated what performs better. * A malicious exchange could theoretically send expensive transactions to the auditor via the replication mechanism (possibly ones that - it did not even execute locally itself) to DoS the "ingres" + it did not even execute locally itself) to DoS the "ingress" database. This would be noticed primarily by load monitoring or even the auditor lagging unusually far behind the exchange's transaction history. We believe this is acceptable, diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index 2973d1a1..2d476711 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -81,6 +81,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 *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 *reserve* based on the subject of the wire transfer. The wallet which @@ -136,7 +143,7 @@ components: The ``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 REST API to execute + 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 ``KUDOS``) and by LibEuFin. LibEuFin is an adapter which maps the Taler Wire @@ -146,7 +153,7 @@ components: The ``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 REST API to observe such + 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. @@ -360,7 +367,7 @@ merchant). Key options include: -- ``[exchange/MASTER_PRIV_FILE]``: Path to the exchange’s master private file. Only needs to be provided on the offline system where the ``taler-exchange-offline`` command is used. +- ``[exchange-offline/MASTER_PRIV_FILE]``: Path to the exchange’s master private file. Only needs to be provided on the offline system where the ``taler-exchange-offline`` command is used. - ``[exchange/MASTER_PUBLIC_KEY]``: Must specify the exchange’s master public key. Needed for the exchange to verify information signed by the offline system. |