[taler-marketing] branch master updated: more text

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new 4e0d4d9  more text
4e0d4d9 is described below

commit 4e0d4d9a3af1f6358567cc99590224503ff94e52
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Dec 11 11:42:41 2022 +0100

    more text
---
 depolymerization/en.tex | 149 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 144 insertions(+), 5 deletions(-)

diff --git a/depolymerization/en.tex b/depolymerization/en.tex
index 0df7c89..2704271 100644
--- a/depolymerization/en.tex
+++ b/depolymerization/en.tex
@@ -370,13 +370,128 @@ transfer is reversed.
 
 \section{Paying Taler-enabled merchants}
 
+The GNU Taler merchant backend makes it easy to accept GNU Taler payments as
+part of an e-commerce site or at a point-of-sale.  In contrast to the
+peer-to-peer payments described above, accepting payments with the merchant
+backend always results in the money being transfer to the merchant using the
+real-time gross settlement (RTGS) layer underpinning transactions in the
+currency. In case of Bitcoin, this means that the merchant will always receive
+the money on-chain in their Bitcoin wallet as a UTXO.
+
+\subsection{Payment aggregation}
+
+As on-chain (or even traditional banking RTGS) transactions are expensive,
+the GNU Taler exchange does not trigger such a transfer for each GNU Taler
+transaction, but only at a frequency determined by the merchant backend.
+Three settings primarily affect when such a transfer will happen:
+\begin{itemize}
+\item The wire transfer fee set by the exchange. As the transfer is expensive,
+  the exchange charges a fee, but will not execute transfers if the fee is
+  larger than the amount to be transferred.
+\item The refund deadline. GNU Taler allows a merchant to give a customer a
+  refund until the refund deadline, which is part of the contract between
+  customer and merchant.  As refunds are not possible after the exchange
+  has send the money to the merchant, any transfers to the merchant happen
+  {\bf after the refund deadline} set by the merchant in the contract.
+\item The wire deadline. The wire deadline must be after the refund deadline
+  and specifies the latest time by which the merchant wants to receive the
+  funds. Thus, the exchange will execute the transfer {\bf before the wire 
deadline}.
+\end{itemize}
+
+When any outstanding payment hits the wire deadline, the exchange will
+sum up all other payments to the same merchant that are past the refund
+deadline and wire the total amount (minus the wire fee) to the merchant.
+
+
 \subsection{Configuring the merchant backend}
 
-% configure currency
-% configure exchange trust
-% setup instance:
-% - add wire method
-% - configure acceptable fees
+To setup a merchant backend, you first need to install the {\tt
+  taler-merchant-httpd} backend. This is described for various platforms in
+the GNU Taler merchant
+manual.\footnote{\url{https://docs.taler.net/taler-merchant-manual.html}}
+To configure the system for Bitcoin, you need to set the currency:
+\begin{verbatim}
+$ taler-config -s TALER -o CURRENCY -V BITCOINBTC
+\end{verbatim}
+Furthermore, you need to tell the backend to trust the respective
+exchange:
+\begin{verbatim}
+$ taler-config -s merchant-exchange-benoist \
+  -o CURRENCY -V BITCOINBTC
+$ taler-config -s merchant-exchange-benoist \
+  -o EXCHANGE_BASE_URL -V https://bitcoin.ice.bfh.ch/
+$ taler-config -s merchant-exchange-benoist \
+  -o MASTER_KEY -V YCWD4QXP607YDZ47NF40MZ6BNMKNFKPECD6JYMTTMTAANZ6C7W00
+\end{verbatim}
+
+It is possible to support multiple exchanges in the same currency by varying
+the section name, as long as the section prefix is ``merchant-exchange-''.
+
+\begin{figure}[h!]
+\begin{center}
+%\includegraphics[width=0.6\textwidth]{}
+\end{center}
+\caption{The Taler Backoffice application with the page to configure
+  the key settings for an e-commerce site or point-of-sale.}
+\label{fig:spa:settings}
+\end{figure}
+
+Assuming everything else was setup correctly, the rest of the configuration
+can be done with the browser (Figure~\ref{fig:spa:settings}).  Configuring the
+instance under ``Settings'' should be largely straightforward.  The only
+special setting is that under ``Bank account'' you need to specify ``bitcoin''
+as the ``Target type'' and enter your Bitcoin wallet address under
+``Address''. The ``Name'' should be set to a human-readable identifier of the
+owner of the wallet; however, it is not checked or used in the on-chain
+transfer.
+
+The ``Default max deposit fee'' refers to the exchange's per-coin deposit
+fees.  The merchant backend will agree to pay up to this amount in fees for
+any transaction. This is, however, merely a default: the frontend can override
+the deposit fee the merchant is willing to cover each time it creates an
+order. If the actual deposit fees are higher, the customer will be asked to
+cover the excess deposit fees.
+
+The ``Default max wire fee'' is not a hard cap on the wire fee to be paid to
+the exchange. Instead, if the wire fee charged by the exchange is higher, the
+merchant backend will ask the customer to cover a fraction of the excess fee,
+as determined by the ``Default wire fee amortization'' setting.
+
+The ``Default wire transfer delay'' corresponds to the ``Wire deadline''
+mentioned above. If a specific contract from the frontend does not include a
+``Wire deadline'' the ``Wire deadline'' will be automatically set to the
+current time plus the ``Default wire transfer delay'' by the merchant backend.
+
+\subsection{Creating an order}
+
+You can setup a new order using the backend Web interface or using the GNU
+Taler merchant REST
+API.\footnote{\url{https://docs.taler.net/core/api-merchant.html}} The GNU
+Taler Merchant API
+tutorial\footnote{\url{https://docs.taler.net/taler-merchant-api-tutorial.html}}
+provides a tutorial for using the REST API. Here we will just use the backend
+Web interface. Select the ``Orders'' tab to get a list of the current set of
+orders for this merchant. Clicking on the blue ``+'' icon launches the dialog
+for setting up a new order (Figure~\ref{fig:spa:order}).
+
+\begin{figure}[h!]
+\begin{center}
+%\includegraphics[width=0.6\textwidth]{}
+\end{center}
+\caption{The Taler Backoffice application with the page to configure
+  the key settings for an e-commerce site or point-of-sale.}
+\label{fig:spa:order}
+\end{figure}
+
+Only the order price and a human-readable summary to be shown to the buyer are
+required. Once an order has been created it will appear in the order
+list. Clicking on it will show the order details. To get a customer to pay for
+it, you can either redirect the user to the ``Order status URL'' given on that
+page, or pass the ``Payment URL'' to the wallet (e.g. via clipboard, NFC or QR
+code).  Naturally, in practice, the e-commerce frontend or point-of-sale
+system would use the REST API to automatically setup an order and hand the
+resulting URL to the customer's wallet.
+
 
 \subsection{Making the payment}
 
@@ -415,8 +530,32 @@ exchanges.  This would likely address open challenges for 
Lightening in terms
 of scalability and availability.  The main work required here is to add
 support for federation to the GNU Taler payment system.
 
+\section{Future work}
+
+As described, the current system requires trust in the Taler exchange
+operator. In banking, this trust is usually established by the operator being
+a regulated entity.  However, the existing system is NOT supervised by any
+regulator and there is no depost insurance.\footnote{More specifically, the
+deployment is a research prototype and all funds sent to the exchange are
+considered to be a donation to the research group. The research group may use
+the funds to make payments to third parties as specified above, or terminate
+the system at any time for any reason. Specifically, holders of the respective
+coins do not have a legal rights to any funds held by the research group.}
+
+While possible with GNU Taler, the existing system does not perform any kind
+of KYC or AML checks. As pointed out in our paper~\cite{depo2022}, the
+non-fungible nature of Bitcoin creates challenges for any regulated operator.
+Future business and legal work is required to overcome these challenges if
+this type of system were to be operated commercially.
+
 \section{Conclusion}
 
+We have described how GNU Taler can be used as a layer-2 solution on top of
+Bitcoin to facilitate inexpensive and virtually instant transactions, both
+between GNU Taler wallets and between customer wallets and merchants. The
+system supports the use of cryptographically secured microtransactions
+off-chain with large transactions on-chain when withdrawing or paying out to
+merchants.
 
 
 \bibliographystyle{alpha}

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.