From 3404576d767e19c269bb2a8db975d255407a05d8 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Thu, 23 May 2019 15:29:10 +0200 Subject: starting point --- sa/sa.tex | 519 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 519 insertions(+) create mode 100644 sa/sa.tex (limited to 'sa') 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} + -- cgit v1.2.3