commit fd883855acf43fc659b35985d263627d4efd2dfd
parent 8242284b994f6f22779fecb50b31f6382a2dc2a1
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 4 May 2021 16:07:20 +0200
draft
Diffstat:
3 files changed, 459 insertions(+), 0 deletions(-)
diff --git a/illiterate/illiterate.tex b/illiterate/illiterate.tex
@@ -0,0 +1,459 @@
+\documentclass{article} % {article} % {acmart}
+
+\usepackage{url}
+\usepackage{eurosym}
+\usepackage[T1]{fontenc}
+% \usepackage{lmodern}
+% \usepackage{verbatim}
+\usepackage[utf8]{inputenc}
+\usepackage{graphicx}
+\usepackage[a4paper,left=25mm,right=25mm, top=25mm, bottom=25mm]{geometry}
+\usepackage{enumerate}
+
+\begin{document}
+\pagestyle{plain}
+% \thispagestyle{empty}
+
+\newcommand\logo{\includegraphics[width=0.07\textwidth]{../presentations/comprehensive/taler-big-accent.pdf}}
+
+\begin{center}
+{\huge Centrally Banked Digital Currency \\ for Illiterate and Low-literate People }
+\end{center}
+
+\begin{center}
+\includegraphics[width=3cm]{taler-logo-2021-plain.pdf}
+\hskip1cm
+\includegraphics[width=5cm]{myoralvillage.png}
+\end{center}
+
+
+\def\red{} % FIXME
+
+\begin{abstract}
+ Taler is a cryptographic protocol with a Free Software reference
+ implementation for a value-based transaction system. Taler payments are
+ executed in fiat currency with privacy and regulatory compliance, which
+ makes Taler suitable for a Central Bank Digital Currency (CBDC).
+
+ My Oral Village has been developing user interfaces for electronic
+ payment systems that can be used by illiterate and innumerate groups,
+ with field experience from Kenya and Pakistan where substantial
+ portions of the population cannot read or comprehend multi-digit
+ numbers.
+
+ We propose to integrate the user interface work of My Oral Village
+ with the Taler payment system to create an inclusive payment solution
+ that minimizes the digital divide.
+\end{abstract}
+
+
+\section{Introduction to GNU Taler}
+
+Taler Systems SA is developing an online payment system called Taler, that
+broadly fits the requirements of CBDCs. The major parts
+of the system have already been built. Taler's unique focus is
+on regulatory compliance, efficiency and data minimization. Cryptography is
+employed for security. While Taler includes privacy features, it can still
+guarantee that cash flows to merchants/retailers are transparent for anti-%
+money-laundering (AML) and know-your-customer (KYC) auditing requirements.
+Transactions with Taler execute in one network round-trip time. Taler is
+economically viable for micro-payments (payments of 1 cent) as its design
+minimizes requirements in terms of CPU time (typically less than 1 M cycles
+per transaction), bandwidth (typically 1-10 KB/transaction), and storage
+(again a few KB/transaction, with the ability to delete old data once legal
+data retention periods have expired).
+
+\subsection{Unique sales propositions}
+
+The unique sales propositions of Taler as it exists today are:
+
+\begin{itemize}
+\item All operations are cryptographically secured, with mathematically sound
+ proofs for courts and auditors
+\item Customer payments are privacy-preserving, like cash
+\item Merchants are identifiable in each payment they receive
+\item Payments are in existing currencies
+\item Payment fraud is eliminated, short of catastrophic failure in cryptographic primitives
+\item Linear scalability ensures Taler can handle transaction volumes seen in global payment systems today
+\item Suitable for micro-payments due to very low transaction costs
+\item The patent-free, open standard protocol and the free reference implementation provide
+ long-term sustainability and technological independence from foreign providers
+%\item Can be used for smart contracts
+\item Ease of use (one-click, instant, no authentication during payment, again like cash)
+\end{itemize}
+
+The last point is crucial for the proposed CBDC implementation: because
+payments with Taler only require authorization and not authentication, we
+believe the payment process with Taler is easy enough to be made accessible to
+illiterate or innumerate people. The proposed work will extend this list
+by making Taler {\bf suitable for illiterate and innumerate adults}. We also
+have plans to make Taler suitable for (numerate) children.
+
+\subsection{Taler architecture}
+
+The Taler architecture includes a register-based system of bank accounts
+for customers and merchants with an escrow-account for the exchange. The
+exchange signs electronic coins into existence, customers use them to sign
+contracts and merchants deposit them in return for a credit to the register.
+The exchange collects cryptographic proofs that it operates correctly, which
+are then checked by an auditor (auditor not shown):
+
+\begin{center}
+\includegraphics[width=\textwidth]{../presentations/comprehensive/operations.png}
+\end{center}
+
+Thus, the following components form the core of the system:
+
+\begin{enumerate}
+ \item An \emph{Electronic wallet} software stores cryptographic
+ tokens of value (called digital coins), implemented via blind
+ signatures. Wallets are typically managed by the end user; a
+ \emph{wallet provider} can manage storage of cryptographic
+ material for the user, providing backup, synchronization and
+ recovery.
+
+ \item The \emph{Exchange} issues digital coins to wallets, after
+ receiving fiat money in an escrow account, or based on a
+ central bank creating the digital coins as a central bank liability.
+ The authorized electronic
+ wallet is identified using an ephemeral \emph{reserve public key}
+ encoded in the wire payment instructions. As blind signatures are
+ used, the exchange knows that it issued coins of a certain
+ monetary value, but not to which wallet. Digital coins are always
+ denominated in a fiat currency (e.g. Euro).
+
+ \item The \emph{Merchant} proposes contracts to customers and
+ receives payment in the form of contracts signed using digital
+ coins. The merchant must then immediately clear these
+ \emph{deposit permissions} with the exchange. The exchange checks
+ against double-spending, and if everything is in order provides
+ the merchant with an instant \emph{deposit confirmation}. After
+ possibly aggregating many micro-transactions, the exchange sends
+ money from the escrow account to the merchant's bank account.
+
+ \item \emph{Auditors} are entities that certify which Exchanges can
+ be trusted as legitimate. They are not strictly needed in a CBDC
+ setting, but can be used by the central bank to verify that its
+ own operations have not been compromised.
+\end{enumerate}
+
+The implementation of all core components is licensed as free and open
+source software (FOSS).
+
+
+\subsection{Vision}
+
+Our vision is close to the electronic cash system ``DigiCash'' proposed by
+David Chaum in the 1990s, except that Taler's design and implementation
+supports key features such as giving change, providing refunds, securely
+handling aborts and various other practical issues previous technical
+solutions lacked.
+
+In summary, the overall system roughly operates as follows: The Taler wallet
+is filled via wire-transfer to the Taler exchange's escrow account, where the
+subject identifies the Taler wallet eligible to withdraw the CBDC. Regulators
+can limit the amount an entity is entitled to exchange from rand into CBDC,
+like ATM withdrawal limits. When withdrawing electronic coins, they are
+blindly signed by the Taler exchange and stored in the consumer's wallet,
+which is value-based. The consumer can then spend its coins at merchants
+using cryptographic signatures over electronic contracts. Merchants must
+immediately deposit the coins at the exchange, which performs an online check
+for double-spending. The exchange will then credit the merchant's
+register-based accounts using aggregated wire-transfers.
+
+
+\subsection{Company Profile: My Oral Village}
+
+My Oral Village is a not-for-profit social enterprise incorporated in
+Canada. Engaged in human-centred design and field research at the oral-digital
+frontier, we build trusted, usable financial-interface solutions for the
+world's billion functionally illiterate and innumerate adults to support their
+transition into financial inclusion.
+
+Our suite of ``oral information management'' (OIM) tools and solutions enable
+poorly schooled individuals to safely and confidently engage in formal
+financial transactions. We are currently designing a mixed (digital and
+paper-based) solution for entrepreneurial pastoralists in northern Kenya, and
+our testing our ``cash calculator'' for Android in Pakistan. We recently
+designed a passbook for new credit union members in Sierra Leone. With
+MicroSave, we wireframed a full 'concept-level' mobile money app for northern
+India. Our solution for savings groups in the Solomon Islands has been adopted
+by the Ministry of Women two local NGOs.
+
+\subsection{Company profile: Taler Systems SA}
+
+Taler Systems SA was established in 2016 and is headquartered in Luxembourg,
+but also has developers in Argentina, Brazil, Germany, Switzerland and the
+United States of America. Taler Systems SA was founded as a startup by with
+support from INRIA, the French national institute for research in computer
+security (\url{https://www.inria.fr/}) and the Free Software community
+(\url{https://www.gnu.org/}). % The company is privately owned and debt-free.
+
+Taler Systems SA business model is to provide technical support for users of
+the Taler payment system, and to possibly dual-license the Free Software for
+users that have specific licensing requirements. Taler Systems is in the
+unique position of not having technological business secrets to protect, as
+all of our code and documentation is freely available. Thus, we can easily
+find and train local partners in our technology and focus on providing
+second-level support.
+
+We have been involved in consultations with the Swiss National Bank, the
+European Central Bank, and the Swedish Riksbank, as all three were interested
+in Taler in their respective CBDC initiatives. However, none of them is yet
+at the point where the respective central banks have made any commitments for
+any particular direction or technical solution.
+
+\section*{Contact}
+
+\begin{tabular}{l l}
+ Dr. C. Grothoff & grothoff@taler.net \\
+ Dr. F. Dold & dold@taler.net \\
+ L. Schumacher & schumacher@taler.net \\
+ B. Matthews & brett@myoralvillage.org \\
+\end{tabular}
+
+\vfill
+
+\includegraphics[width=0.05\textwidth]{../presentations/investors/partner-logos/ashoka.png}
+\hfill
+\includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/inria.png}
+\hfill
+\includegraphics[width=0.1\textwidth]{../presentations/comprehensive/bfh.png}
+\hfill
+\includegraphics[width=0.025\textwidth]{../presentations/investors/partner-logos/tum.png}
+\hfill
+\includegraphics[width=0.025\textwidth]{../presentations/investors/partner-logos/gnu.jpeg}
+
+\end{document}
+
+
+
+\subsection*{What would a solution for a register-based CBDC look like?}
+
+
+\subsection*{What would a solution for a value-based CBDC look like?}
+
+
+\section*{What is your vision for an CBDC?}
+% Are there other possible solutions than register-based and value-based that you consider to be more appropriate?}
+
+
+
+
+\section*{What challenges and opportunities do you envisage?}
+
+Taler provides the advantages of cash while supporting taxation and
+limiting criminal abuse, as recipients of payments are identifiable.
+Furthermore, Taler transactions are faster, easier and more secure
+than cash or credit card transactions.
+
+The main challenge is the integration of the Taler merchant backend
+into the diverse POS systems that exist today. While integrating
+Taler can be done with a few hundred lines of code, NFC-enabled POS
+systems would require at least a firmware update. Convincing vendors
+to upgrade their systems will thus require a major up-front
+investment.
+
+Taler also requires further development to ensure that wallets are
+available on all relevant platforms. However, consumer systems are
+much less diverse and hence this effort is significantly smaller.
+
+Deploying Taler at scale should have no major impact on monetary
+policy because the issued CBDC would be 1:1 backed by rand
+in the escrow account at the SARB. However, if there is a
+significant shift from the use of credit-cards to CBDC, there might
+be a reduction in M2 from fractional reserve banking as CBDC is
+debit-based while credit-cards are credit-based. Thus, instead of
+commercial bank money being created from debts, consumers may
+effectively hold CBDC claims against the escrow account at the
+central bank. The resulting reduction in M2, and the loss of revenue
+at banks from credit-card interest payments, may require adjustments
+in monetary policies.
+
+
+\section*{What is missing in our concept?}
+
+
+A key requirement for governments considering electronic payment
+systems is the preservation of the Commons. Cash is a Commons as all
+market participants have equal liberties in handling cash. If cash is
+replaced by proprietary solutions such as Visa's credit card system or
+ApplePay, these companies have exclusive control over critical
+infrastructure, which often leads to high fees. Worse, such payment
+service providers may discriminate against individuals or certain
+businesses and can refuse service to individuals or businesses without
+judicial oversight.
+
+In contrast, Taler is implemented as Free Software distributed under
+the GNU General Public License, and without patent encumbrances. This
+ensures that any government retains sovereignty after deploying Taler,
+as it can liberally inspect, use and modify the software. In
+particular, no foreign government or company can impose their own
+restrictions or regulatory regime. Governments can foster competition
+between multiple Taler exchange operators, or run a Taler exchange as
+a government monopoly equivalent to a government mint for coins.
+
+
+
+\section{Addressing CBDC Requirements}
+
+We now sketch how the Taler components map to a Centrally Banked Digital
+Currency system run by the ECB or national central banks (NCBs), according to
+the draft requirements. Taler is a value-based payment system (as opposed to
+an account-based system), and thus we will address the common requirements
+C1-C8 and requirements V1-V4 specific to the value-based model.
+
+\paragraph{C1. Tokenization:} \emph{Units of digital currency (CBDC units) are only created against money
+blocked on a transit account, which will be held by ECB/NCBs}.
+
+The ECB/NCBs would simultaneously take the role of the Taler Exchange
+and Taler Auditor (or could outsource operations to qualified third parties).
+
+\paragraph{C2. Issuance:} \emph{A central authority creates new CBDC units on
+the reception of the transfer of an equivalent EUR amount from the
+participating bank to the transit account. The same logic applies to the
+destruction of existing CBDC units, where the central authority destroys CBDC
+and releases EUR that were previously held by the ECB/NCBs in the transit
+account.}
+
+The ECB/NCBs create new CBDC units by issuing Taler digital coins,
+and destroy CBDC units by accepting digital coin deposits from merchants, subsequently releasing
+funds blocked in the escrow account and sending them to the merchant's bank account.
+
+\paragraph{C4. 1-on-1 parity rule:} \emph{The parity rule applies when CBDC units are newly created or destroyed,
+meaning that for each EUR blocked in (released from) the transit account there will be exactly
+one CBDC created (destroyed). The parity rule also applies when CBDC are exchanged for
+commercial bank deposits or physical cash, and vice versa.}
+
+Digital coins in GNU Taler correspond 1-on-1 to a
+value in a fiat currency such as the Euro.
+
+\paragraph{C4. Two-tier structure:} \emph{The central authority issues CBDC only to entities entitled to deposit funds
+in the transit account held at ECB/NCBs in exchange for newly issued CBDC units. Also, end-
+users’ access to the CBDC payment system is intermediated via other entitled entities, acting as
+gateways. All these entities, hereafter “tier-2 entities”, could be commercial banks or non-banks
+(for example, payment service providers (PSPs), wallet providers etc.).}
+
+
+With Taler, national banks could serve as
+the primary Tier-2 entity, establish customer's identities (KYC) during bank
+account setup, and facilitate the transfer from a customer's bank
+account to the exchange's escrow account. A secondary Tier-2 entity are the wallet providers.
+Banks can serve as wallet providers, but other third party businesses could offer
+a wallet backup/sync/restore services as well. Customers are also given the option to be
+responsible for the security of their wallet on their own, and manage private keys directly
+and on their own device.
+
+
+\paragraph{C5. Compliance with AML regulation:} \emph{Transactions with amounts above a certain threshold must be
+disclosed to relevant parties as required by the AML regulation. In general, the system must be
+designed in a way that discourages end-users from using it for anonymous large-value
+transactions.}
+
+Strict withdrawal limits can
+be placed on customers' bank accounts. Merchants can be required to collect
+customer data for critical transactions. Due to the technical measures
+that provide transparency of cash flows to merchants, the compliance of
+merchants is easy to verify.
+
+\paragraph{C6. Fees:} \emph{The system should enable fee collection. The issuance of CBDC to banks and the
+destruction of returned CBDC are free of charge for the entitled tier-2 entities (i.e. banks). Tier-2
+entities can, however, charge fees to end-users for services they provide, such as their
+involvement in the transfers of CBDC and/or the exchange of EUR into CBDC and vice versa.}
+
+Taler has a flexible fee structure that is easily configured so that Tier-2 banks
+can charge for CBDC creation and other activities.
+
+
+\paragraph{C7. Availability:} \emph{Payments are processed 24 hours a day, 7 days a week, 365 days a year, without
+operational downtimes.}
+
+Taler requires no manual processing and can be made highly
+available with standard software deployment and operations techniques.
+
+
+\paragraph{C8. Throughput, transaction time and micropayments:} \emph{The
+payment system must be able to handle a sufficiently large amount of
+transactions. Each transaction must be processed real-time (to be compliant
+with the SEPA Instant Credit Transfer (SCT Inst) scheme, the transaction time
+would have to be maximum ten seconds). Furthermore, the payment system
+should/could enable micropayments (low value, large volume, low cost, real time
+transactions).}
+
+Transactions
+with Taler are processed in the order of milliseconds. Unlike DLTs, Taler can
+be easily scaled both horizontally (sharding, more processing nodes) and
+vertically (faster machines). Since multiple payments to a merchant can be aggregated into
+one bank transfer, even micropayments with fractions of a cent are possible. All coins
+are issued with expiration dates, ensuring that the exchange may eventually delete ancient
+transactions.
+
+\paragraph{V1. Non-interest-bearing:} \emph{In the value-based model, holdings of CBDC do not bear interest - neither
+positive nor negative.}
+
+In Taler, digital coins do not bear interest; however,
+when coins expire it is possible to charge fees when the electronic wallets trade
+expiring coins for fresh coins. This feature may be used to
+provide a mechanism for negative interest rates (for non-circulating coins).
+
+
+\paragraph{V2. Limitation of bank runs:} \emph{In the value-based model, to avoid a situation, in which end-users
+(suddenly) shift large amounts of their commercial bank deposits to CBDC, daily (potentially also
+weekly or monthly) limits should be imposed on the amount that can be converted from
+commercial bank deposits into CBDC.}
+
+Bank runs are discouraged and limited with Taler: (1) Withdrawal
+limits can be imposed by the Tier-2 banks on the withdrawal of CBDC units; (2) wallet providers may place limits
+on how much money can be stored in online wallets; (3) customers that mange their own wallet are discouraged from
+storing large amounts of CBDC units in their wallets, as they must ensure its safety similar to a physical wallet;
+(4) modest expiration times with modest refresh fees make hoarding coins unattractive.
+
+
+\paragraph{V3. Anonymity and AML:} \emph{The system should allow anonymous low-value transactions (below a
+certain amount used as threshold). Moreover, it should be possible to trace large-value
+transactions and link them to the identities of the participants (through KYC). Furthermore, as
+countermeasure against splitting large-value transactions into multiple low-value anonymous
+transactions, it should be possible to identify multiple low-value transactions which are
+processed within a certain period of time and which sum up to an amount greater than the
+chosen threshold.}
+
+The exchange does not know which customer owns which coin
+due to the use of blind signatures during the withdrawal process.
+AML measures are based on the \emph{income transparency} feature,
+where cash flows to merchants are visible to the exchanges (and
+thus ECB/NCBs). As the merchant redeems CBDC units with a transaction to their bank account, the KYC process
+already happened when the merchant opened their SEPA bank account. Furthermore, the
+deposit permissions are linked to the contract with the customer, allowing authorities
+to validate the plausiblity of the transaction during tax audits.
+With Taler, ownership of digital coins between mutually distrusting parties can only be securely transferred with a digital coin deposit via the exchange.
+This discourages ``invisible'' payments by sharing digital coins between wallets
+without involving the exchange.
+
+\paragraph{V4. Ownership and spending rights of CBDC:} \emph{In the value-based model, units of CBDC are held by
+end-users themselves. Each end-user has cryptographic information (e.g. private keys, other
+secrets) without which CBDC units associated with that particular cryptographic information
+material cannot be spent. Spending rights are defined by technology (e.g. if you have private
+keys you can spend).}
+
+Technically literate
+users have the option to manage their own wallets and private keys, whereas
+other users can use wallet backup/sync/restore providers.
+
+\section*{Contrast and Relationship to DLT-based Systems}
+
+The Taler payment system is independent from Distributed Leder
+Technology (DLT) systems. In particular, Taler payments are not
+necessarily backed by any blockchain or cryptocurrency. Even though
+Taler uses cryptographically secured payment tokens, it is distinct
+from ``cryptocurrencies'': Taler is a very efficient electronic
+payment system with certain characteristics like cash, but it is not a
+currency. Taler is designed to serve as a payment instrument for
+retail commerce, in contrast to DLTs which are generally used more as
+a long-term stores-of-value or as speculative assets.
+
+Some technological advancements made by DLTs could potentially benefit Taler.
+For example, public cryptographic key material and data relevant for auditing
+could be further secured by a distributed ledger. Yet a distributed ledger is
+not mandatory to operate Taler, as payments are facilitated by a federation of
+trusted entities, with oversight from each other and/or a central institution,
+not too dissimilar from how traditional banking systems work.
diff --git a/illiterate/myoralvillage.png b/illiterate/myoralvillage.png
Binary files differ.
diff --git a/illiterate/taler-logo-2021-plain.pdf b/illiterate/taler-logo-2021-plain.pdf
Binary files differ.
