[GNUnet-SVN] [taler-marketing] branch master updated: sarb

[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 7e492e8  sarb
7e492e8 is described below

commit 7e492e80db5455e160043f66396ac36c21467f0d
Author: Christian Grothoff <address@hidden>
AuthorDate: Thu May 23 21:38:49 2019 +0200

    sarb
---
 presentations/comprehensive/operations.png | Bin 259161 -> 259266 bytes
 sa/sa.tex                                  | 810 +++++++++++++++++++----------
 2 files changed, 547 insertions(+), 263 deletions(-)

diff --git a/presentations/comprehensive/operations.png 
b/presentations/comprehensive/operations.png
index a9365b2..cd55fa6 100644
Binary files a/presentations/comprehensive/operations.png and 
b/presentations/comprehensive/operations.png differ
diff --git a/sa/sa.tex b/sa/sa.tex
index ae2ae41..5f62480 100644
--- a/sa/sa.tex
+++ b/sa/sa.tex
@@ -1,4 +1,4 @@
-\documentclass{memoir} % {article} % {acmart}
+\documentclass{article} % {article} % {acmart}
 
 \usepackage{url}
 \usepackage{eurosym}
@@ -8,11 +8,7 @@
 \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}{}{}{}
+\usepackage{enumerate}
 
 \begin{document}
 \pagestyle{plain}
@@ -36,17 +32,16 @@
 \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.
+\section{Introduction}
 
-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.
+Taler Systems SA is developing an online payment system called Taler, that
+broadly fits the requirements of SARB's CBDC project.  Taler is an electronic
+payment system with focus on security, efficiency and data minimization.
+Cryptography is employed for security.  While Taler includes privacy features,
+it can at the same time guarantee that cash flows to merchants/retailers are
+transparent for AML and other financial auditing requirements.  Transactions
+with Taler are fast and can execute in one network round-trip time. Taler is
+economically viable for micro-payments (payments of 1 cent).
 
 The USPs of Taler are:
 
@@ -70,38 +65,12 @@ 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{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
@@ -141,7 +110,536 @@ The following components form the core of the system:
 The implementation of all core components is licensed as free and open
 source software (FOSS).
 
-\section*{Addressing CBDC Requirements}
+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.
+
+
+\section{CBDC principles and attributes}
+
+This section elaborates on how the open source payment system GNU Taler fits
+into the requirements of a Centrally Banked Digital Currencency (CBDC) as set
+forth in the SARB tender in Section~3.
+
+\begin{enumerate}[i]
+\subsection{Policy}
+\item
+{\bf CBDC will be issued as legal tender by the SARB only.}
+  The Taler protocol requires an auditor to certify that an
+  electronic money issuer is allowed to issue coins of a particular
+  denomination.  Usually the auditor would be tied to the
+  regulation of the respective central bank.  Thus, if SARB
+  only qualifies itself to issue CBDC for Rand, then only SARB
+  can issue Taler CBDC for Rand.
+\item
+{\bf A possible alternative scenario is for the SARB to back the CBDC and to 
set
+regulatory standards and interoperability requirements, but with commercial 
banks
+acting as issuing authorities under the regulatory oversight of the SARB.}
+  The Taler system also allows this. In this case, it is expected that
+  the commercial banks would have to provide escrow accounts as backing for
+  electronic coins they issued (and did not yet redeem).
+\item
+{\bf The supply of CBDC must be limited as determined by applicable monetary 
policy.}
+  CBDC is either supplied by a central bank creating them, or by commercial
+  banks moving existing funds into an escrow account when creating electronic
+  coins.  Thus, the introduction of Taler does not impact monetary policy,
+  except that it might be easier for foreigners to obtain and hold electronic
+  coins (compared to obtaining cash or Rand-denominated bank accounts).
+\item
+{\bf It must be possible to issue and distribute CBDC to commercial banks 
only, or to
+commercial banks as well as licensed service providers. Such licensed service
+providers could be instrumental in broadening the base for financial inclusion 
and
+would be authorised and licensed upon meeting a defined set of regulatory 
criteria.}
+  Taler is intended for consumers. It is unclear to us what the value would be
+  in restricting distribution to commercial banks and service providers only
+  and thus excluding consumers.
+\item
+{\bf CBDC must be complementary to cash and is not intended to replace cash. 
However,
+it is expected that CBDC would influence the movement of cash or even displace
+cash to some extent over time.}
+  Recent developments in California suggest that regulation needs to be
+  in place to force businesses to accept cash, as some businesses may
+  like to discriminate against consumers that use cash. Nevertheless, this
+  is a regulatory issue and unrelated to a particular choice of CBDC.
+\item
+{\bf CBDC must be a liability on the SARB balance sheet.}
+  Taler is designed to work for all currencies for which
+  a register-based accounting system exists and are expected
+  to be denominated in the currency of the underlying register.
+  Taler coins in circulation would thus be backed by an
+  escrow account at a commercial bank, or when created by the SARB
+  be booked as a liability on the SARB balance sheet in anticipation
+  of future deposits of the electronic coins.
+\item
+{\bf CBDC must be issued at one-to-one parity with the rand.}
+  Taler is designed to map 1:1 to any existing fiat currency.
+  Taler coins are expected to map 1:1 to the fiat currency and
+  show up in the respective user-interface in the respective
+  fiat denomination.
+\item
+{\bf Transacting with CBDC must be free to the consumer, or at a very low cost
+  significantly below current payment channel fees.}
+  We estimate
+  that the actual costs per transaction at scale (excluding migration cost)
+  are generally less than 0.1 cent/transaction.  It is conceivable that the
+  SARB might absorb the entire (low) cost. The protocol also includes 
provisions
+  for hiding the cost from consumers by charging fees primarily to the 
merchants.
+\item
+{\bf CBDC must offer value or an incentive to promote its use, including a 
lower cost to
+  the industry compared with the cost of cash.}
+  As stated earlier, Taler comes with a range of USPs, including lower costs,
+  improved security, convenience, competition, and privacy.
+\item
+{\bf CBDC must be ubiquitous and accepted as a means of payment by all sizes of
+business and by the government.}
+  Taler is designed to handle micropayments as well as arbitrarily large
+  payments between consumers, companies and authorities.
+\item
+{\bf CBDC must not introduce the risk of destabilising the financial sector and
+mechanisms must be incorporated to give effect to policy decisions regarding 
its
+supply and movement. Specifically, it must be possible to manage risks such as 
value
+migrating rapidly from commercial bank money to CBDC, thereby skewing the 
ability
+of commercial banks to provide credit.}
+  Regulation may impose limits on withdrawals and maximum amounts transacted.
+\item
+{\bf CBDC must provide the opportunity for stakeholders to innovate in terms 
of payment
+products, but must not be seen to disintermediate commercial banks.
+CBDC must be usable alongside the rand in the member states of the Common
+Monetary Area (CMA).}
+  Taler comes with a Free and Open Source reference implementation and is not
+  encumbered by patents.  Taler's openness should thus enable new services
+  to be developed with a minimal barrier to entry into the market.
+  By design, Taler does not disintermediate as every Taler payment must go
+  into a (commercial) bank account.  In other words, Taler coins can only
+  be spent once, the system does not allow for transitivity.
+\item
+{\bf Consumers must be able to own and transact in CBDC without the need for a 
bank
+  account.}
+  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
+{\bf Consumers and businesses must be provided with the channels to obtain or 
return
+  CBDC in exchange for cash and commercial bank money.}
+  With Taler, every transaction must always specify the bank account
+  details of the receiving party.  We note that for efficiency, the
+  wire transfer to the business are typically performed in aggregate
+  to minimize the cost created by the traditional register-based wire transfer.
+  Consumers that do have a bank account can ask their wallet to transfer the
+  CBDC back into their bank account.
+\item
+{\bf CBDC must be freely and seamlessly interchangeable between an 
account-based
+store of value and a tokenised store of value. CBDC is expected to be 
interest-free
+or attract zero interest. This must, however, be a variable attribute to cater 
for different
+policy positions in future.}
+  Taler could theoretically support interest on CBDC by varying the exchange
+  rate between CBDC and Rand.  Taler can also theoretically support {\em 
negative}
+  interest on coins held long-term in wallets.  However, these are optional
+  features and in general we fully agree that the most usable and practical 
design
+  is to fix the exchange rate between CBDC and Rand and to not impose 
significant
+  fees on holding coins.
+
+\subsection{Branding}
+\item
+  {\bf CBDC must be branded and its ownership by the SARB as issuer must be 
evident.}
+  Given that the CBDC is denominated in Rand, this should be trivial.
+  We can also create SARB-branded software if desired.
+\item
+{\bf CBDC must be unique in its design and its SARB ownership must be clear and
+  evident.}
+  SARB is welcome to create any particular branding, especially for
+  consumer-facing products. However, the
+  Taler {\em protocol} will be a global commons (Free Software) and other
+  countries must be allowed to adopt the same technology stack.  That said,
+  SARB will be free to adopt the technology to its needs within the limits
+  of the licensing agreement with Taler Systems SA and/or the GNU Affero
+  General Public License.
+\item
+{\bf CBDC must be trusted and acceptable to all members of the public as legal 
tender,
+  a safe store of value, and as secure means to transfer value during 
transacting.}
+  The SARB would primarily hold the escrow account (or liability).  It could 
also either
+  (1) run the operations of the exchange and guarantee the exchange of CBDC
+  in Rand directly, or (2) else audit privately operated exchanges
+  similar to its regulatory oversight of conventional banks and payment 
processors.
+  This should assure the public about the safety of the CBDC.
+  We are not familiar with legal tender regulation in SA to determine what 
else would
+  be required to make it legal tender.
+
+\subsection{Transactional usage}
+\item
+{\bf It must enable immediate person-to-person transfer of value without 
clearing and
+  settlement in today’s terms.}
+
+\item
+{\bf It must be possible to set limits for CBDC transaction values and to 
implement
+graduated regulation depending on transaction value.}
+\item
+{\bf CBDC payment products should enable transaction notifications to 
consumers.}
+  Customers and merchants always have access to their full account
+  histories and their balances on their local computer.
+\item
+{\bf CBDC must be accepted and usable at all levels of transactions, in the 
same way
+cash is accepted and usable at all levels of transactions.}
+\item
+{\bf CBDC must provide real-time, final and irrefutable transfer of value.}
+Taler payments typically clear in one network RTT, concluding with
+an electronically signed statement providing irrefutable proof of the
+transfer of value.
+\item
+{\bf It must be able to operate on a peer-to-peer (face-to-face) basis as well 
as online. In
+the absence of connectivity/Internet/data, consumers must be able to transfer 
value
+to each other or to a business. This implies that mechanisms will be required 
to
+enforce offline transaction limits, prevent double-spending, and reconcile 
transaction
+data once online.}
+  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
+{\bf The government must be able to make payments in CBDC.}
+\item
+{\bf Interoperability principles must enable CBDC to be used at all levels 
throughout the
+payment system.}
+  With proper system integration, wire transfers, debit and credit cards or 
even
+  NFC-enabled ATMs could all be used to fund the CBDC wallet.  Our 
specifications
+  are public, thus broad integration is a question of regulation and/or
+  incentives.
+\item
+{\bf The CBDC value transfer mechanisms must prevent double-spending.}
+  The Taler exchange performs online double-spending detection by comparing 
against
+  known coins when processing deposit requests.
+\subsection{Auditability and traceability}
+\item
+{\bf CBDC must be traceable.}
+  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.
+  Taler is thus {\em untraceable} in that the system cannot necessarily
+  identify the buyer.  However, Taler does provide for income
+  transparency.  We believe this is critical to avoid 1984-like
+  totalitarian control over society while ensuring compliance with
+  reasonable KYC and AML regulation.
+\item
+{\bf CBDC must be auditable in terms of proof of issuance and ownership.}
+  When Taler electronic coins are created, the issuer electronically
+  signs the public key of the coin, thus providing proof of issuance.
+  The private key of the coin is only known to the owner, never
+  disclosed (not even upon payment) and is used as proof of ownership.
+
+\item
+{\bf Auditability of transactions should be parameterised in order to 
determine the balance
+between anonymity of the transacting parties and traceability of funds 
transfers.}
+\item
+{\bf It must be possible to issue a consumer with a ‘proof of payment’ from 
transaction
+  audit trails.}
+  Every Taler transaction concludes with the consumer having a proof of
+  payment (including details of the contract that was paid for).
+\item
+{\bf It must be possible to recreate a consumer’s ‘electronic vault’ or 
‘e-wallet’ in the case
+  of loss caused by technology failure.}
+  We will provide an optional electronic backup service for
+  consumer's electronic wallets which uses secret sharing for
+  key escrow (if desired).  This electronic vault will also
+  be used to support cross-device synchronization.
+
+\subsection{Security}
+\item
+{\bf CBDC must be issued using highly secure and trusted modern cryptographic
+  mechanisms.}
+Taler is only using modern cryptography (RSA, SHA-512, EdDSA/Curve25519).
+\item
+{\bf CBDC must be generated/created during its issuance as a secure discreet 
offline
+activity and not as a mining operation such as those deployed for private 
virtual
+currencies.}
+Taler does not use mining or any other forms of proof-of-work
+or proof-of-stake operations.
+\item
+{\bf CBDC must not be easily counterfeited.}
+Taler uses established cryptographic primitives and comes with a peer-reviewed
+security proof.
+\item
+{\bf CBDC must be configurable in its design features in order to keep pace 
with
+  improvements in technology and security mechanisms.}
+The key security settings in Taler (RSA key length, $\kappa$ CNC parameter) are
+configurable.  The protocol includes versioning features to enable future 
updates.
+\item
+{\bf It must be possible to withdraw/revoke a CBDC by serial number in case of 
proven
+or suspected counterfeiting or theft.}
+\subsection{General and non-functional}
+\item
+{\bf The ability to transact with CBDC must be ‘always on – in real time, 24 
hours a day,
+7 days a week.}
+  The Taler system is designed for 24/7 operations.
+\item
+{\bf The CBDC data structure must allow open access to third-party service 
providers to
+add value. In general, the CBDC must be designed to encourage innovation and
+enable value-added services.}
+\item
+{\bf There are no expectations of the technology platform having to be based 
on DLT,
+blockchain or an existing ‘traditional’ technology. It is envisaged that a 
solution could
+be based on any one or a combination of technologies.}
+\item
+{\bf CBDC must be simple and user friendly.}
+The Taler wallet enables one-click payments.  We have successfully
+tested the system with children below the age of 10.
+\item
+{\bf CBDC transactions must be fast and efficient.}
+Taler requires only a few signature operations and only a few kilobytes
+of data transfer per transaction.  The Taler wallet pre-computes signatures
+while waiting for the user to confirm the transaction. As a result, actual
+transactions are usually confirmed in one network round-trip time.
+\item
+{\bf Consumers must be able to transact in CBDC using smart phones and 
unstructured
+  supplementary service data.}
+A Taler wallet for Android is under development. Payments via NFC are under
+development.
+\item
+{\bf Processes must be provided to manage technology upgrades. This implies
+  that it must be possible for CBDC tokens to be withdrawn from circulation
+  and replaced with newly issued, more advanced CBDC.}  Taler implements a
+revocation mechanism to inform wallets that a particular signing key is being
+withdrawn from circulation, forcing the wallets to automatically deposit coins
+in circulation back into the consumer's bank account in case the CBDC is
+discontinued, or to withdraw a different CBDC if available.  Wallets
+periodically check for such revocations and automatically adopt their money
+holdings, without requiring input from the consumer.
+
+\end{enumerate}
+
+
+
+
+
+
+
+\section{Company profile}
+
+\subsection{Company structure and physical location(s)}
+%, with the
+%emphasis on sustainability and the ability to undertake the
+%feasibility project
+
+% FIXME: Leon
+
+\subsection{Capacity to support the feasibility project}
+
+% in terms of the
+%location and availability of subject matter experts and
+% technical support
+
+% FIXME: Leon
+
+\section{Ability in the subject matter}
+
+\subsection{Participation in similar initiatives or projects}
+
+Mention ECB, SNB, Riksbank consultations, and cooperation with German bank
+on real-world deployment.
+
+\subsection{Experience and skill set offered by the subject matter experts}
+%
+%and technical experts applicable to the feasibility project
+
+Grab vitas of our core team from investor presentation.
+Also mention advisory board members.
+
+\subsection{Commentary on the CBDC principles and attributes}
+
+We provided detailed commentary on each of the CBDC principles and attributes
+in Section~\ref{section:cbdc:requirements}.  In summary, we believe that we
+cover most of the critical requirements well.
+
+Overall, it should be noted that we believe it to be {\em impossible} for any
+available technology to provid off-line transactions with a purely
+software-based (and hence cost-efficient) solution without creating systemic
+risks from deferred double-spending detection.
+
+We are also surprised that privacy for citizens using the system is
+not listed as a principle objective and urge the SARB to consider
+adding privacy considerations to their requirements.
+
+
+\section{Proposed approach and methodology}
+
+\subsection{Proposed approach to support the objectives}
+%of the
+%feasibility approach specifically and the needs of an
+%innovation lab (sandpit) in general
+
+We imagine a realistic CBDC solution based on the Taler system to
+be effectively a hybrid solution, with a register-based component
+provided by integrating the existing SA banking system with
+a value based component using Taler.
+
+The CBDC 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 CBDC.   Regulators could
+limit the amount an entity is entitled to exchange from Rand into
+CBDC, 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.
+
+
+\subsection{Methodology proposed to support the proposed approach}
+
+SARB issues electronic coins based on deposits into an escrow
+account.  Citizens could use their wallets to withdraw CBDC
+from their traditional bank accounts, or they could be provided
+CBDC 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 CBDC
+back into Rand when they are deposited by merchants.  An auditor
+supervises the operation of the exchange, unless the exchange
+is fully operated within SARB's trusted infrastructure. In this
+case, SARB may still want to run the auditing logic to provide
+assurance against insider threats.
+
+
+\section{Conclusion}
+
+Taler effectively provides electronic cash and thus solves the problem
+of gaining access to risk-free assets.  As the SARB supervises the
+CBDC escrow funds (either directly or by auditing the private
+operator), the government can assure citizens that they can always
+exchange CBDCs 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.
+
+Further information about the Taler system can be found at
+\begin{center}
+  \url{https://taler.net/}
+\end{center}
+
+
+\section*{Contact}
+
+\renewcommand\logo{}
+
+\begin{center}
+  
\includegraphics[width=0.5\textwidth]{../presentations/comprehensive/taler-logo-2018.pdf}
+  \vfill
+  {\Large  \url{https://taler.net/}}
+  \vfill
+
+\begin{tabular}{l l}
+  Prof. Dr. C. Grothoff        &       address@hidden  \\
+  Dr. F. Dold           &   address@hidden \\
+  L. Schumacher                &       address@hidden  \\
+  M. Widmer            &       address@hidden  \\
+\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/comprehensive/bfh.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}
+
+
+
+\subsection*{What would a solution for a register-based CBDC 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.
+
+\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} \label{section: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
@@ -303,217 +801,3 @@ 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        &       address@hidden  \\
-  Dr. F. Dold           &   address@hidden \\
-  L. Schumacher                &       address@hidden  \\
-  M. Widmer            &       address@hidden  \\
-\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}
-

-- 
To stop receiving notification emails like this one, please contact
address@hidden