starting point

1 files changed, 519 insertions, 0 deletions

diff --git a/sa/sa.tex b/sa/sa.tex
new file mode 100644
index 0000000..ae2ae41
--- /dev/null
+++ b/sa/sa.tex
@@ -0,0 +1,519 @@
+\documentclass{memoir} % {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}
+
+\makeevenhead{plain}{}{}{\logo}
+\makeoddhead{plain}{}{}{\logo}
+%\makeevenfoot{plain}{}{}{}
+%\makeoddfoot{plain}{}{}{}
+
+\begin{document}
+\pagestyle{plain}
+% \thispagestyle{empty}
+
+\newcommand\logo{\includegraphics[width=0.07\textwidth]{../presentations/comprehensive/taler-big-accent.pdf}}
+
+\begin{center}
+{\huge Taler as the Foundation for a \\ Centrally Banked Digital Currency}
+
+\medskip
+
+% \begin{tabular}{l l}
+% Project Acronym 	& LAC - Latent Anonymous Commons  (LAKE) \\
+% Principal Investigator	& Jeffrey Burdges \\
+% Host Institution	& University of Luxembourg \\
+% Main Partner     	& pEp SA \\
+% \end{tabular}
+\end{center}
+
+\def\red{}  % FIXME
+
+
+\section*{Introduction}
+
+Taler Systems SA is developing an online payment system called Taler,
+that could easily fit the requirements of SARB's CBDC project.
+
+Taler is an open source system based on a consumer wallet, merchant
+backend and a central exchange for payment processing. It provides
+instant one-click payments, implements privacy-by-design and assures
+receiver transparency for tax purposes using modern cryptography.  It
+is fast and efficient, and can hence also cover micro-payments
+(payments of 1 cent) economically.
+
+The USPs of Taler are:
+
+\begin{itemize}
+\item All operations provide cryptographically secured, with mathematical
+      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 handles transaction volumes of widely used systems
+\item Suitable for micro-payments due to very low transaction costs
+\item Ease of use (one-click, instant, no authentication during payment, again like cash)
+\item Open standard protocol without patents, with free reference implementation
+\end{itemize}
+
+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{minipage}{13cm}
+\includegraphics[width=\textwidth]{taler-arch-full.pdf}
+\end{minipage}
+\begin{minipage}{3cm}
+  {\Huge \}} register-based
+\vspace{3cm}
+  
+{\Huge \}} value-based 
+\end{minipage}
+
+
+
+This note elaborates on how the open source payment system GNU Taler fits into
+the requirements of a Centrally Banked Digital Currencency (CBDC) intended for
+use in the European retail market.  It was created as a response to an
+unpublished draft note by an internal expert group of the European Central Bank's
+InnovationLab.
+
+\emph{Neither the original list of requirement nor this response reflects the
+opinion of the ECB.  The ECB's official stance can be found in official
+documents such as
+\url{https://www.ecb.europa.eu/press/key/date/2017/html/sp170116.en.html}.}
+
+\section*{Overview}
+Taler Systems is developing GNU Taler, the software
+infrastructure for an electronic payment system with focus on security,
+efficiency and data minimization.  Cryptography is employed for security,
+privacy by design and data minimization, but can at the same time guarantee that cash flows
+to merchants/retailers are transparent for AML and other financial auditing
+features.
+
+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 money in a escrow account. 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.  Auditors must be configured in the
+    electronic wallets and the merchants' infrastructure before these
+    users accept digital coins of the respective exchanges.  Auditors
+    include a software component used to conduct ongoing automated
+    checks of the Exchanges' wire transaction history to detect if
+    they deviate from their expected operation.  For this, auditors
+    must be provided a replica of the exchange's database and read-only
+    access to the escrow account.
+\end{enumerate}
+
+The implementation of all core components is licensed as free and open
+source software (FOSS).
+
+\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.
+
+
+
+
+\section*{What would a solution for a register-based e-Krona look like?}
+
+Taler's focus is on a cryptographic protocol for a value-based
+transaction system.  However, Taler requires integration with
+some register-based accounting system, equivalent to traditional
+bank accounts.  For this, it would be possible to use a permissioned
+block chain.  Taler aggregates many small transactions from different
+customers to the same merchant, thereby reducing the transaction
+rate in the register-based solution.
+
+\section*{What would a solution for a value-based e-Krona look like?}
+
+Taler issues electronic coins based on deposits into an escrow
+account.  Citizens could use their wallets to withdraw e-Krona
+from their traditional bank accounts, or they could be provided
+e-Krona directly (for example via social security) if they lack
+a bank account.  Electronic coins are blindly signed
+by the issuing exchange, which is obliged to exchange e-Krona
+back into Krona when they are deposited by merchants.  An auditor
+supervises the operation of the exchange.
+
+Our vision is thus very 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.
+
+\section*{What is your vision for an e-Krona?}
+% Are there other possible solutions than register-based and value-based that you consider to be more appropriate?}
+
+We imagine a realistic e-Krona solution based on the Taler system to
+be effectively a hybrid solution, with a register-based component and
+a value based component, in order to fulfill the maximum requirements
+outlined in ``The Riksbank’s e-Krona project'' report.
+
+The e-Krona Taler wallet can exist on smartphones, in browsers, on
+smartcards or secure USB sticks. It is filled via wire-transfer to the
+Taler exchange's escrow account, where the subject identifies the
+Taler wallet eligible to withdraw the e-Krona.   Regulators could
+limit the amount an entity is entitled to exchange from Krona into
+e-Krona, like ATM 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.
+
+Thus, the Taler system combines value-based and register-based
+accounting, providing anti-money laundering capabilities by making
+income transparent, identifying the users of the system (upon
+withdrawal and deposit), but also providing privacy for citizens by
+not requiring identification of the buyer for ordinary transactions.
+Thus, Taler is a hybrid system combining the advantages of value-based
+and register-based solutions.
+
+Specifically, Taler addresses the following requirements outlined in
+the report:
+
+\begin{description}
+\item[Specified in Swedish Krona]
+  Taler is designed to work for all currencies for which
+  a register-based accounting system exists.
+\item[Payment size]
+  Taler is designed to handle micropayments as well as arbitrarily large payments between consumers, companies and authorities.
+  Regulation may impose limits on withdrawals and maximum amounts transacted.
+\item[Direct claim on Riksbank]
+  The Taler design involves the exchange owning an escrow account
+  (for example, with the Riksbank) to keep the funds to back the issued electronic coins.
+  The contractual obligations of the system are supposed to entitle the holder of
+  e-Krona to exchange them anytime into other representations of Krona.
+\item[Accessible in real-time]
+  Customers and merchants always have access to their full account
+  histories and their balances on their local computer.  Backups and
+  cross-device synchronization will also be supported.
+\item[Payments in real-time]
+  Payments typically clear in one network RTT.  
+  The system is designed for 24/7 operations.
+\item[Offline payments]
+  For Taler transactions, either the payer or the merchant must be online and able to
+  communicate with the exchange.  Otherwise the merchant cannot be sure that the payer
+  did not double-spend and risks being defrauded.
+\item[Anonymous payments]
+  Taler is designed for payers to remain anonymous when buying goods, unless regulation
+  requires disclosure (i.e. for particular sensitive purchases).
+  However, the merchant is never anonymous.
+\item[e-Krona account]
+  A register-based account is required for merchants to receive transactions.
+  The exchange also must have an escrow account.
+\item[Riksbank functions]
+  The Riksbank would primarily hold the escrow account.  It could also either
+  (1) run the operations of the exchange and guarantee the exchange of e-Krona
+  in Swedish Krona directly, or (2) else audit privately operated exchanges
+  similar to its regulatory oversight of conventional banks and payment processors.
+\item[No bank account necessary]
+  Taler can enable distribution of funds (i.e. from social security) directly to
+  wallets.  Thus, citizens having a Taler wallet could be given remittances without
+  the need for a bank account.  However, merchants must have a register-based
+  bank account to receive payments.
+\item[Interest payments]
+  Taler could theoretically support interest on e-Krona by varying the exchange
+  rate between e-Krona and Krona.  Taler can also theoretically support {\em negative}
+  interest on coins held long-term in wallets.
+\item[Connection to existing payment systems]
+  With proper system integration, wire transfers, debit and credit cards or even
+  NFC-enabled ATMs could all be used to fund the e-Krona wallet.
+\end{description}
+
+Taler effectively provides electronic cash and thus solves the problem
+of gaining access to risk-free assets.  As the Riksbank supervises the
+e-Krona escrow funds (either directly or by auditing the private
+operator), the government can assure citizens that they can always
+exchange e-Kronas back to cash.  Thus, in Taler's design, the government
+acts as a trust anchor.
+
+Taler removes inefficiencies the current system creates through fraud
+risks inherent in register-based systems.  In Taler, citizens only
+ever authenticate to their bank (or social services).  By avoiding
+disclosing personally identifying information or even performing
+credit card-style authentication via third parties, Taler improves
+usability and eliminates most vectors of authentication token
+compromise. 
+
+
+\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 e-Krona would be 1:1 backed by Swedish Krona
+in the escrow account at the Riksbank.  However, if there is a
+significant shift from the use of credit-cards to e-Krona, there might
+be a reduction in M2 from fractional reserve banking as e-Krona is
+debit-based while credit-cards are credit-based.  Thus, instead of
+commercial bank money being created from debts, consumers may
+effectively hold e-Krona 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*{Contact}
+
+\renewcommand\logo{}
+
+\begin{center}
+  \includegraphics[width=0.5\textwidth]{../presentations/comprehensive/taler-big-accent.pdf}
+  \vfill  
+  {\Large  \url{https://taler.net/}}
+  \vfill
+
+\begin{tabular}{l l}
+  Prof. Dr. C. Grothoff	&	grothoff@taler.net	\\
+  Dr. F. Dold           &   dold@taler.net \\
+  L. Schumacher	        &	schumacher@taler.net	\\
+  M. Widmer         	&	widmer@taler.net	\\
+\end{tabular}
+\end{center}
+
+\vfill
+
+\includegraphics[width=0.2\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/investors/partner-logos/tum.png}
+\hfill
+  \includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/gnu.jpeg}
+
+\end{document}
+