commit 50947243b05119c1b0123e50e4081553c5f9c69f
parent c37b69df4521bdbb2c0f23ab3b11fdf88e38543f
Author: Gian Demarmels <gian@demarmels.org>
Date: Sun, 13 Feb 2022 22:40:45 +0100
Merge branch 'master' of ssh://git.taler.net/marketing
Diffstat:
15 files changed, 925 insertions(+), 98 deletions(-)
diff --git a/2022-privacy/bibliography/CNNum-Dossier-Billets_et_jetons_la_nouvelle_concurrence_des_monnaies.pdf b/2022-privacy/bibliography/CNNum-Dossier-Billets_et_jetons_la_nouvelle_concurrence_des_monnaies.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/Monnaie Numérique de Banque Centrale.pdf b/2022-privacy/bibliography/Monnaie Numérique de Banque Centrale.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/Qu’est-ce qu’une blockchain souveraine -.pdf b/2022-privacy/bibliography/Qu’est-ce qu’une blockchain souveraine -.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/bis948.pdf b/2022-privacy/bibliography/bis948.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/cwps.pdf b/2022-privacy/bibliography/cwps.pdf
Binary files differ.
diff --git a/2022-privacy/ecb.op286~9d472374ea.en.pdf b/2022-privacy/bibliography/ecb.op286~9d472374ea.en.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/fca.pdf b/2022-privacy/bibliography/fca.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/lightening.pdf b/2022-privacy/bibliography/lightening.pdf
Binary files differ.
diff --git a/2022-privacy/bibliography/nzz-egold.docx b/2022-privacy/bibliography/nzz-egold.docx
Binary files differ.
diff --git a/2022-privacy/bibliography/othp35.pdf b/2022-privacy/bibliography/othp35.pdf
Binary files differ.
diff --git a/2022-privacy/literature.bib b/2022-privacy/literature.bib
@@ -1,4 +1,5 @@
@misc{schneier2016toxic,
+ author = {Bruce Schneier},
title = {Data Is a Toxic Asset, So Why Not Throw It Out?},
year = {2016},
month = {March},
@@ -7,6 +8,199 @@
+@Misc{fca,
+ author = {{Financial Conduct Authority}},
+ title = {FCA Retention Schedule},
+ howpublished = {\url{https://www.fca.org.uk/publication/systems-information/retention-schedule.pdf}},
+ month = {February},
+ year = {2022},
+}
+
+@Book{carbon,
+ author = {Ricardo Coelho},
+ editor = {Joanna Cabello and Tamra Gilbertson},
+ title = {Green is the Color of Money: The EU ETS failure as a model for the “green economy”},
+ publisher = {Carbon Trade Watch},
+ year = {2012},
+ month = {June},
+}
+
+@PhdThesis{cwps,
+ author = {J. Appelbaum},
+ title = {Communication in a world of pervasive surveillance},
+ school = {TU Eindhoven},
+ year = {2022},
+ month = {February},
+}
+
+@misc{zcash,
+ title={Zcash protocol specification},
+ author={Hopwood, Daira and Bowe, Sean and Hornby, Taylor and Wilcox, Nathan},
+ howpublished={\url{https://raw.githubusercontent.com/zcash/zips/master/protocol/protocol.pdf}},
+ year={2016}
+}
+
+@book{voigt2017eu,
+ title={The EU General Data Protection Regulation (GDPR)},
+ author={Voigt, Paul and Von dem Bussche, Axel},
+ volume={18},
+ year={2017},
+ publisher={Springer}
+}
+
+
+@Article{huawei,
+ author = {Adam Smith},
+ title = {Huawei ban: Trump extends executive order against China tech firms},
+ journal = {The Independent},
+ year = {2020},
+ month = {May},
+ url = {\url{https://www.independent.co.uk/life-style/gadgets-and-tech/news/huawei-ban-trump-china-zte-executive-order-us-telecoms-security-a9513576.html}},
+}
+
+@TechReport{bis948,
+ author = {Raphael Auer and Rainer B\"ohme},
+ title = {Central bank digital currency: the quest for minimally invasive technology},
+ institution = {Bank of International Settlement},
+ year = {2021},
+ type = {BIS Working Papers},
+ number = {948},
+ month = {June},
+}
+
+@article{lightening,
+ doi = {10.1088/1367-2630/aba062},
+ url = {https://doi.org/10.1088/1367-2630/aba062},
+ year = 2020,
+ month = {aug},
+ publisher = {{IOP} Publishing},
+ volume = {22},
+ number = {8},
+ pages = {083022},
+ author = {Jian-Hong Lin and Kevin Primicerio and Tiziano Squartini and Christian Decker and Claudio J Tessone},
+ title = {Lightning network: a second path towards centralisation of the Bitcoin economy},
+ journal = {New Journal of Physics},
+}
+@InCollection{ chaum2021,
+ author = {David Chaum and Christian Grothoff and Thomas Moser},
+ title = {How to Issue a Central Bank Digital Currency},
+ booktitle = {SNB Working Papers},
+ publisher = {Swiss National Bank},
+ year = {2021},
+ number = {2021-3},
+ month = {February},
+}
+
+@Misc{p2e2022,
+ author = {Paul Butler},
+ title = {"Play-to-earn” and Bullshit Jobs},
+ howpublished = {\url{https://paulbutler.org/2021/play-to-earn-and-bullshit-jobs/}},
+ month = {December},
+ year = {2021},
+}
+
+@inproceedings{sahin2010overview,
+ title={An overview of business domains where fraud can take place, and a survey of various fraud detection techniques},
+ author={Sahin, Y and Duman, E},
+ booktitle={Proceedings of the 1st international symposium on computing in science and engineering, Aydin, Turkey},
+ year={2010}
+}
+@inproceedings{garera2007framework,
+ title={A framework for detection and measurement of phishing attacks},
+ author={Garera, Sujata and Provos, Niels and Chew, Monica and Rubin, Aviel D},
+ booktitle={Proceedings of the 2007 ACM workshop on Recurring malcode},
+ pages={1--8},
+ year={2007},
+ organization={ACM}
+}
+@book{stallman2002essays,
+ title={Free software, free society: Selected essays of Richard M. Stallman},
+ author={Stallman, Richard},
+ year={2002},
+ publisher={Lulu.com}
+}
+
+@inproceedings{monero,
+ title={RingCT 2.0: a compact accumulator-based (linkable ring signature) protocol for blockchain cryptocurrency monero},
+ author={Sun, Shi-Feng and Au, Man Ho and Liu, Joseph K and Yuen, Tsz Hon},
+ booktitle={European Symposium on Research in Computer Security},
+ pages={456--474},
+ year={2017},
+ organization={Springer}
+}
+
+
+@Misc{afganistan2021,
+ author = {Margaret Hu},
+ title = {The Taliban reportedly have control of US
+biometric devices -- a lesson in life-and-death consequences
+of data privacy},
+ howpublished = {\url{https://theconversation.com/the-taliban-reportedly-have-control-of-us-biometric-devices}},
+ year = {2021},
+}
+
+@TechReport{usfed2022,
+ author = {{Board of Governers of the Federal Reserve System}},
+ title = {{Money and Payments: The U.S. Digital Dollar in the Age of Digital Transformation}},
+ institution = {United States Federal Reserve},
+ year = {2022},
+ month = {January},
+ note = {\url{https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf}},
+}
+
+@PhdThesis{dold2019,
+ author = {Florian Dold},
+ title = {The GNU Taler System},
+ school = {L'university de Rennes 1},
+ year = {2019},
+}
+
+@Article{nzz,
+ author = {Peter Bernholz},
+ title = {Eine Franken-Gold-Kombination brächte mehr Sicherheit},
+ journal = {Neue Zürcher Zeitung},
+ year = {2012},
+ number = {113},
+ pages = {31},
+ month = {May},
+}
+
+@article{french2021,
+ author = {Gilles Dowek and Elisabeth Grosdhomme and Joëlle Toledano and Jean-Marc Vittori},
+ title = {Billets et jetons --- La Nouvelle concurrence des monnaies},
+ journal = {Counseil National Du Numerique},
+ year = {2021},
+ pages = {44},
+ month = {November},
+ note = {\url{https://cnnumerique.fr/nos-travaux/billets-et-jetons-la-nouvelle-concurrence-des-monnaies}},
+}
+
+@Misc{rugpull,
+ author = {Phemex},
+ title = {What is a Rug Pull and How Can You Avoid One?},
+ howpublished = {\url{https://phemex.com/academy/what-is-a-rug-pull}},
+ month = {August},
+ year = {2021},
+}
+
+@Inbook{Helbing2019,
+author="Helbing, Dirk",
+title="Digital Fascism Rising?",
+bookTitle="Towards Digital Enlightenment: Essays on the Dark and Light Sides of the Digital Revolution",
+year="2019",
+publisher="Springer International Publishing",
+address="Cham",
+pages="99--102",
+abstract="Can we still stop a world of technological totalitarianism?",
+isbn="978-3-319-90869-4",
+doi="10.1007/978-3-319-90869-4_8",
+url="https://www.theglobalist.com/fascism-big-data-artificial-intelligence-surveillance-democracy/"
+}
+
+
+
+
+
@article{cap,
author = {Gilbert, Seth and Lynch, Nancy},
title = {Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services},
@@ -311,3 +505,94 @@ series = {SEC'16}
year={2021},
}
+@Misc{designagerestriction2021,
+ title={{Anonymous Age Restriction Extension for GNU Taler}},
+ author={\"Ozg\"ur Kesim},
+ howpublished={\url{https://docs.taler.net/design-documents/024-age-restriction.html}},
+ journal={{GNU Taler Design documents}},
+ year={2021},
+}
+
+@Misc{talerPrinciples,
+ title={GNU Taler: Design Principles},
+ author={{GNU Taler Authors}},
+ howpublished={\url{https://taler.net/en/principles.html}},
+ year={2014},
+}
+
+@misc{EurostatAge10,
+ author = {Eurostat},
+ title = {{Population on 1 January by age and sex (Europa, Altersgruppe 10)}},
+ howpublished = {\url{https://bit.ly/32iWEyV}}
+}
+
+@book{dannen2017introducing,
+ title={Introducing Ethereum and solidity},
+ author={Dannen, Chris},
+ volume={318},
+ year={2017},
+ publisher={Springer}
+}
+
+@misc{merge2022,
+ title={The merge},
+ year={2022},
+ howpublished = {\url{https://ethereum.org/en/upgrades/merge}}
+}
+
+@misc{nelson2021,
+ title={The State of the Merge: An Update on Ethereum’s Merge to Proof of Stake in 2022},
+ author={Matt Nelson},
+ year = {2021},
+ howpublished = {\url{https://consensys.net/blog/news/the-state-of-the-merge-an-update-on-ethereums-merge-to-proof-of-stake-in-2022/}}
+}
+
+@article{noether2015ring,
+ title={Ring SIgnature Confidential Transactions for Monero.},
+ author={Noether, Shen},
+ journal={IACR Cryptol. ePrint Arch.},
+ volume={2015},
+ pages={1098},
+ year={2015}
+}
+@article{nakamoto2008re,
+ title={Re: Bitcoin P2P e-cash paper},
+ author={Nakamoto, Satoshi},
+ journal={The Cryptography Mailing List},
+ year={2008}
+}
+
+
+
+@misc{dictionaryCurrency,
+ author = {Currency},
+ title = {Dictionary.com},
+ howpublished = {\url{{https://www.dictionary.com/browse/currency}}}
+}
+
+@misc{LeRobertMonnaie,
+ author = {Monnaie},
+ title = {{Dictionnaire Le Robert}},
+ howpublished = {\url{https://dictionnaire.lerobert.com/definition/monnaie}}
+}
+
+@book{cattaneo2016man,
+ title={MAN and SHELLS Molluscs in the History},
+ author={Cattaneo-Vietti, Riccardo and Doneddu, Mauro and Trainito, Egidio},
+ year={2016},
+ publisher={Bentham Science Publishers}
+}
+
+@misc{WikipediaFrancCFA,
+ author = {Franc CFA},
+ title = {Wikipedia {Franc CFA}},
+ howpublished = {\url{https://fr.wikipedia.org/wiki/Franc_CFA}}
+}
+
+@misc{BISHelvetia2020,
+ author = {BIS},
+ title = {Project Helvetia Phase I: Settling tokenised assets in central bank money},
+ howpublished = {\url{https://www.bis.org/publ/othp35.pdf}},
+ year = 2020,
+ month = {December}
+}
diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
@@ -2,9 +2,26 @@
\usepackage{url}
\usepackage{enumitem}
+\usepackage{authblk}
-\title{Accounts Considered Harmful}
-\author{Christian Grothoff \and \"Ozg\"ur Kesim}
+\title{Accounts are an Unnecessary Evil \\ A critique of two
+ papers\footnote{We thank Martin Summer for encouraging us to put our
+ critique of the ECB's report in writing. We thank central bankers for their
+ good aspirations, which they should keep up even if we question their
+ universal realization.}}
+
+\author[$\triangle\pounds$]{Antoine~d'Aligny}
+\author[$\triangle$]{Emmanuel~Benoist}
+\author[$\dagger\heartsuit$]{Florian~Dold}
+\author[$\triangle\dagger\heartsuit$]{Christian~Grothoff}
+\author[$\S$]{\"Ozg\"ur~Kesim}
+\author[$\ddagger\heartsuit$]{Martin~Schanzenbach}
+\affil[$\triangle$]{Bern University of Applied Sciences}
+\affil[$\pounds$]{École d'Ingénieurs Généraliste du Numérique}
+\affil[$\dagger$]{Taler Systems SA}
+\affil[$\S$]{Freie Universit\"at Berlin}
+\affil[$\ddagger$]{Fraunhofer Institute for Applied and Integrated Security}
+\affil[$\heartsuit$]{The GNU Project}
\date{\today}
\begin{document}
@@ -21,10 +38,116 @@ paper. We argue that an account-based design cannot meet the ECB's stated
design goals and that the ECB needs to fundamentally change its mindset when
thinking about its role in the context of the Digital Euro if it wants the
project to succeed.
+
+Along the same lines, the French National Council for Digitalization published
+a report on ``Notes and Tokens, The New Competition of
+Currencies''~\cite{french2021}. Here, the authors make similar false
+assumptions about inevitable properties of Central Bank Digital Currencies
+(CBDCs), going as far as stating that a CBDC is not possible without an eID
+system. Our paper sets the record straight.
+
% [oec] Shouldn't we also mention GNU Taler already here as an example for an alternative?
-}
-\section{The ECB cannot be the Guardian of Privacy}
+\noindent
+{\bf JEL Classification Codes:} E42, E58 \\
+{\bf Keywords: } retail CBDC, privacy, crypto-currency, trust
+
+
+\section{Introduction}
+\label{sec:intro}
+
+This article presents our comments regarding two papers that have been written
+by the European Central Bank (ECB)~\cite{ecb2021} and the French National
+Council for Digitalization\footnote{Conseil national du numérique}
+(CNNum)~\cite{french2021}. As the French report is using some rather unclear
+definitions of currency and crypto-currency, we will begin with a brief
+introduction of terms and technologies.
+
+We will then explain why the ECB should not be the only guardian of the
+privacy of the European citizen and why coupling of a Central Bank Digital
+Currency (CBDC) with an identity system is a bad idea. We address a question
+raised in the ECB's report on the risks of a retail CBDCs promoting
+disintermediation to a degree that might threaten traditional banks.
+
+The second part of this paper proposes a set of design principles that any
+retail CBDC must integrate. We then argue that a retail CBDC based on GNU
+Taler would not only satisfy these principles, but also could provide an added
+value over existing commercial solutions for a retail CBDC. Finally, we
+explain how tokenization can help to build an eGold payment system or a system
+allowing micropayments in Bitcoins and Ethereum.
+
+
+\section{Currency, crypto-currency and payment systems} \label{sec:terms}
+
+Currency is ``something that is used as a medium of exchange;
+ money.''\cite{dictionaryCurrency}. From the French dictionary, currency
+(i.e. la monnaie) is an ``Instrument of measurement and conservation of
+ value, legal means of exchanging goods''\footnote{Instrument de mesure et
+ de conservation de la valeur, moyen légal d'échange des biens.}, or
+``Unit of value accepted and used in a country, a group of
+ countries.''\footnote{Unité de valeur admise et utilisée dans un pays, un
+ ensemble de pays.}~\cite{LeRobertMonnaie}
+The main desired properties of a currency are therefore: conservation of value and
+availability for exchange.
+
+For more than a hundred years, most currencies were issued by central banks.
+Over the last decade a large number of new crypto-currencies have appeared,
+and these currencies are not tied to any central bank. The first and best
+known of them is Bitcoin~\cite{nakamoto2008re}. The various crypto-currencies
+are very heterogeneous and based on different principles. Some use accounts
+with balances with a blockchain used to establish a consensus on the account
+balances (Bitcoin was the first currency to use it), while others allow the
+transfer of fungible tokens that are disassociated from any transaction
+history (Zcash~\cite{zcash}). Among those using a blockchain, some use proof
+of work (Bitcoin, Ethereum), others use proof of stake
+(Ethereum, expected in Q2 2022~\cite{merge2022,nelson2021}) or most recently
+proof of wasted human lifetime (Play to Earn~\cite{p2e2022}). Some are rather
+transparent (Bitcoin, Ethereum), while others allow private transactions
+(Monero~\cite{noether2015ring}).
+
+Crypto-currencies do not have a central bank controlling the rules governing
+the currency. Instead, software developers program rules into algorithms. New
+rules are adopted if they find the consensus of the ``miners'' (for
+crypto-currencies using proof of work) or ``stakeholders'' (for
+crypto-currencies using proof of stake). In general, the rules are written to
+produce some artificial scarcity of the currency minted according to the
+rules, so as to convince hoarders of the value of their limited-edition
+bitstrings. A key design challenge is thus to provide ample rewards to
+``miners'' and ``stakeholders'' that facilitate transactions while maintaining
+a limited supply.
+
+Crypto-currencies are beginning to gain functionalities through the addition
+of payment systems on top of these basic currency mechanisms. In general, any
+payment system enables participants to make financial transactions, but does
+not in itself establish a new currency. Compared to the transaction mechanisms
+offered by the underlying currency, payment systems can provide credit, make
+transactions faster, cheaper, more private or more usable. Payment systems may
+require their users to trust payment system providers, as these intermediaries
+may introduce new failure modes into the system. As a result, payment service
+providers are generally regulated entities, at least when they deal with
+traditional fiat currencies. Examples for payment systems used with
+crypto-currencies include the various proprietary crypto-trading platforms as
+well as distributed layer-2 solutions like the Lightning
+network~\cite{lightening}.
+
+There are two types of CBDCs, retail CBDCs and
+wholesale CBDCs. Wholesale CBDC is expected to be primarily used to trade
+between banks and between the central bank and banks. An example of wholesale
+CBDC can be found in the description of the project Helvetia of the Swiss
+National Bank~\cite{BISHelvetia2020}.\footnote{We note that the French report
+ confuses project Helvetia (which implements a wholesale CBDC) with an
+ entirely different proposal~\cite{chaum2021} for a retail CBDC.} In
+contrast, a retail CBDC is intended to be used by citizens and businesses in
+their daily lives for their ordinary expenses, basically providing a form of
+digital cash that is, like physical cash, a liability of the central bank.
+This paper is about retail CBDCs. Our discussion will
+assume that the currency for the CBDC already exists, and thus focus on the
+requirements for the payment system that facilitates ordinary people to make
+digital transactions with such a currency.
+
+
+\section{Central Banks cannot be the Guardian of Privacy}
+\label{sec:guardians}
The ECB's report starts with a public interest-oriented self-image of central
banks. For example, the authors claim that ``central banks operate in the
@@ -55,98 +178,144 @@ citizen is in control of their personal data. The ECB asserting the ``ability
to control the privacy'' is thus an oxymoron: once anyone else has control,
citizens have no privacy. As an institution that claims to act in the public
interest, the ECB's report thus shows a fundamental lack of respect of its
-sovereign: the European citizens. If European democratic ideals are to
-prevail, we clearly need to reestablish the principles of personal
-self-reliance, personal independence and subsidiarity in the design processes
+sovereign: the European citizens.
+
+The French report~\cite{french2021} correctly states that a Digital Euro based
+on accounts poses ``democratic risks''\footnote{risques démocratiques} and could allow ``state surveillance of
+all transactions of every individual''\footnote{surveillance de toutes les transactions de chaque individu par l’État}.
+Subsequently the wording of the French report is misleading, as it turns the
+possibility of privacy-invasive monitoring into a mandatory feature of any
+CBDC, which is demonstrably false: There are many digital currencies and
+payment systems that do not allow comprehensive
+surveillance~\cite{monero,dold2019}. Thus, it is wrong for the authors of the
+French report to take a possible design choice of an account-based system as a
+necessity, for example when they write that ``the centralization and data
+tracking of CBDC projects leads to a loss of privacy
+that coupled with the programmability of the currency can have serious
+consequences.''\footnote{Toutefois, la centralisation et la traçabilité des données des projets de monnaie numérique de banque centrale conduit à une perte de vie privée qui, associée à la programmabilité de la monnaie, peut avoir de lourdes conséquences. } Using the indicative here is a serious mistake, as it is
+understood that any CBDC design would necessarily lead to a loss of privacy,
+when this is false.
+
+Furthermore, the use of the term ``surveillance'' in the French report actually
+understates the negative impact of an account-based CBDC, as with an
+account-based CBDC the central bank would likely also be in a position to
+prevent individuals from spending money and to manipulate their balances,
+thereby gaining comprehensive power over the economic activities of
+individuals going far beyond mere analytical capabilities. The use of
+permissioned blockchains does not inherently prevent such manipulations as
+long as the participating operators are colluding. Thus, if European
+democratic ideals and personal freedoms are to prevail, we clearly cannot
+ignore this danger and must reestablish the principles of personal
+responsibility, personal independence and subsidiarity in the design processes
for critical infrastructure created by European institutions.
+Since this far-fetched assumption is taken as true while counterexamples
+exists, the conclusion of the first part of the French report follows a
+logical fallacy. The authors assert that ``the new properties of CBDC raise
+political questions''\footnote{``Dans un contexte où les nombreux projets d’émettre
+des monnaies numériques viennent étendre le rôle des banques
+centrales se pose la question des enjeux démocratiques et politiques de
+ces nouveaux attributs.''} which implies that the deployment of a CBDC would be
+impossible in the current state. But adaptations of central bank missions to
+include ``absolute control over the rules and regulations of the use'' of
+money via the issuance of a CBDC (as envisioned by Agustin Carstens of the
+Bank of International Settlement\footnote{See speech given on October 19th
+ 2020 on ``Cross-Border Payment -- A vision for the future''}) are dangerous
+if the central bank can choose to void privacy assurances. Carsten's reasons
+include that the central bank should have the ability to know about every
+payment. As he states that the central bank would be able to strictly enforce
+its rules and regulations, this implies the bank could arbitrarily block
+payments by private citizens. The repressive potential of a government with
+such a capability is so large that it must be firmly rejected.
+
+Instead, we believe the question should be if central banks should limit CBDC
+issuance corresponding to their mission instead of adapting it. Wisely, the
+US Federal Reserve is currently barred from maintaining digital account
+balances for individuals~\cite{usfed2022}, which limits its ability to issue a
+retail CBDC. We consider this law wise, as we will next argue that tightly
+coupling payments with identity is harmful. Furthermore, the law does not seem
+to prevent the Federal Reserve from issuing a token-based privacy-respecting
+CBDC.
+
+
\section{Harmful coupling with identity}
+\label{sec:coupling}
+The arguably most dangerous idea of the ECB report is ``combining use of
+digital identity and CBDC''. The same idea is echoed in the French report
+which quotes an unpublished report from Catenae (2020) to say that ``it is
+difficult to envisage the creation of a retail CBDC, and more specifically a
+Digital Euro without first creating a reliable, secure digital identity
+offering the necessary guarantees''\footnote{il est difficile d'envisager la
+ création d'une monnaie numérique de banque centrale de détail, et plus
+ particulièrement d’un ``euro numérique'', sans création préalable d'une
+identité numérique fiable, s\'ecuris\'ee et offrant les garanties
+ nécessaires}. From a technical perspective, the statement is hard to
+defend since current cryptocurrencies work perfectly well without depending on
+a ``trusted digital identity''.
-The probably most dangerous idea of the ECB report is ``combining use of
-digital identity and CBDC''.
-Because even if central banks were neutral custodians of citizens' privacy
-(see above) the problem is the data itself.
-As Bruce Schneier has concisely argued already in 2016: ``Data is a toxic asset.
-We need to start thinking about it as such, and treat it as we would any other
-source of toxicity. To do anything else is to risk our security and privacy.''~\cite{schneier2016toxic}
-And here, the report is insunuating to link identities with payments which
-consequently and inevitably produces highly sensitive metadata.
-Referring to the toxicity of this metadata, Edward Snowden famously said at IETF 93
-in 2019 that \begin{quote}
- ``(...) we need to get away from true-name payments on the Internet.
- The credit card payment system is one of the worst things that happened
- for the user, in terms of being able to divorce their access from their
- identity.''
+From a regulatory perspective, it is understood that institutions working with
+a Digital Euro will at times be legally required to establish the identity of
+actors. However, when a Digital Euro needs a digital identity for some of the
+actors in the digital currency production chain, one can use existing
+Know-Your-Customer (KYC) processes of commercial banks or use certificates
+based on the already widely used X.509 standard, which are both already in
+common use on the Internet.\footnote{They correspond to the ``s'' in
+``https'', for example.} While we can imagine a world in which a new
+``trusted digital identity'' exists, and develop new protocols for this world,
+this is by no means a prerequisite to any work on a Digital Euro. Waiting for
+the creation of a new trusted digital identity at the European level before
+creating a CBDC may be equivalent to postponing the decision indefinitely, and
+the necessity of first deploying a new electronic identity scheme is not shown
+by the authors.
+
+What neither report appreciates is that combining payments with such a digital
+identity system would create a serious liability. Even if central banks were
+neutral custodians of citizens' privacy (see Section~\ref{sec:guardians}), the problem is the data
+itself. As Bruce Schneier has concisely argued already in 2016:
+``Data is a toxic asset. We need to start thinking about it as such, and treat
+it as we would any other source of toxicity. To do anything else is to risk our
+security and privacy.''~\cite{schneier2016toxic}
+Despite this well-established insight, the ECB report is insinuating to link
+identities with payments which consequently and inevitably produces highly
+sensitive\footnote{Or to stick with Schneier's analogy, ``super-toxic''}
+metadata. Referring to the toxicity of this metadata, Edward Snowden famously
+said at IETF 93 in 2019
+that \begin{quote} ``(...) we need to get away from true-name payments on the
+ Internet. The credit card payment system is one of the worst things that
+ happened for the user, in terms of being able to divorce their access from
+ their identity.''
\end{quote}
If the European Union wants to avoid a dystopia of the transparent citizen
and catastrophic cases of personal data theft, it must enable citizens to put a
firewall between their identity and their payments.
-Tightly coupling them is thus probably the worst idea so far
-proposed in the design space for CBDCs.
-
-The Swiss population recently rejected a proposal for a national
-E-ID~\cite{eid2021}, and the newly elected German government is promising a
-reversal of ubiquitous data retention (without cause) in
-Germany~\cite{koalitionsvertrag2021}. The European Parliament has members
-proposing to ban the use of facial recognition in public
-spaces~\cite{euai2021}. The ECB's proposal ignores the popular rejection of
-treating every citizen as a criminal suspect. Payment data is typically
-retained for 6 or more years. The missing link in the ECB proposal that would
-show the dystopic reality they would invoke would be a statement that facial
-recognition could be used to conveniently establish the payer's identity --- or
-``pay with your smile'', as contemporary account-based digital payment
-offerings already put it. If CBDC payment data is strongly coupled with our
-identities, those who dislike living in a panopticon could only hope for such a
-CBDC to be rarely used.
-
-But the ECB is not the only institution pushing for digital identity-based
-solutions. Another domain where this is inappropriately pursued is the
-decades-old debate about age-verification for Websites. The common pattern
-here is a security need (for example countering financing of terrorism (CFG),
-anti-money laundering (AML) or protecting the children) which is ``addressed''
-by strong identification.
-% msc: Note this is a claim without a cite. Can we somehow show this? Maybe showing
-% that is is not effective (as opposed to cost effective) is easier.
-Not only is this simplistic approach rarely
-cost-effective, but it contributes to the conversion of soverign citizens to
-digital subjects.
-
-\subsection{Privacy in payments can be done right}
-% msc: GNU Taler needs a cite. And I would even suggest to ONLY use a cite.
-% Also: The age verification plug is a stretch.
-% The example of age verification was given by this
-% paper above. How does it related to the ECB paper? Is this a strawman going
-% down here? Should this section come at the end and formulate requirements
-% that should be taken into account for a CDBC?
-Token-based payments like GNU Taler offer an alternative, enabling the state
-to ensure business is legal (and tax-paying) without infringing on the
-soverenity of private citizens.
-We recently extended this principle also into
-the domain of age-restrictions in e-commerce. %citation needed
-Assuming that owners of
-bank-accounts are mature adults, it allows them to withdraw age-restricted
-coins for their wards. The wards can then anonymously spend the coins, but
-transactions will fail at merchants that sell goods with an age-restriction
-exceeding the age-limit of the coins as specified by the bank account holder,
-acting as a guardian. This design guarantees that the only information
-disclosed is that the age-restriction imposed by the merchant is satisfied -
-but not the age itself. The payment service provider does not even learn that
-age-restrictions are being used, and merchants cannot distinguish successful
-purchases by adults from successful purchases by wards with a sufficiently high
-age-limit. Thus, this design offers a clear alternative to identity-based
-age-verification that is better aligned with the principle of subsidiarity
-which requires that we solve problems at the smallest unit that can solve them.
-And protecting the children should be the task of their parents. We argue that
-the ECB should merely give the parents the technical means to protect their
-children as they see fit, instead of taking control.
+
+Citizens themselves are well aware of this aspect and it consequently would
+have a significant impact on acceptance of a CDBC: The Swiss population
+recently rejected a proposal for a national eID~\cite{eid2021}, and the newly
+elected German government is promising a reversal of ubiquitous data retention
+(without cause)~\cite{koalitionsvertrag2021}. The European Parliament has
+members proposing to ban the use of facial recognition in public
+spaces~\cite{euai2021}. The ECB's proposal seemingly ignores the popular
+rejection of treating every citizen as a criminal suspect by doubling down.
+The missing link in the ECB proposal that would reveal the dystopic reality
+they would invoke would be a statement that facial recognition could be used
+to conveniently establish the payer's identity --- or ``pay with your smile'',
+as contemporary account-based digital payment offerings already put it. We
+stress that CBDC payment data, like other payment data, can be expected to be
+retained for 6 or more years~\cite{fca}. If CBDC payment data is additionally
+strongly coupled with our identities, those who dislike living in a panopticon
+could only hope for such a CBDC to be rarely used.
+
\section{Addressing Balance Sheet Disintermediation via Self-Custody}
+\label{sec:disintermediation}
The ECB report describes the risk of (commercial) bank balance sheet
disintermediation as one of the major risks to consider from the introduction
-of a CBDC. Basically, the risk is that consumers loosing faith in a
-commercial bank may shift funds into CBDC, thereby exacerbating the situation.
+of a CBDC. Basically, the risk is that consumers losing faith in a
+commercial bank may shift funds into CBDC, thereby exacerbating the situation
+by creating a ``bank run''.
The ECB report discusses various strategies, but primarily focuses on limiting
``hoarding'' of CBDC by imposing a balance limit. They then realize that this
can be quite difficult, as businesses may have varying needs for CBDC, so a
@@ -158,12 +327,13 @@ Here, the ECB fails to learn the hard lessons from the introduction of $CO_2$
emissions certificates, where initial allocations were calculated based on
``presumed emission needs'' of certain industries, resulting in windfalls for
shifty polluters that managed to rig the calculations, giving them excess
-certificates that they could then resell. If CBDC holdings are limited and
+certificates that they could then resell.~\cite{carbon} If CBDC holdings are limited and
financially attractive, there will clearly again be businesses profiting from
organizing their business data to obtain high account limits. This kind of
socially unproductive optimization will happen regardless of the specific
rules that the ECB will design. Thus, this is a fundamentally flawed design.
+
The ECB's focus on account-based solutions seems to have caused it to ignore a
better solution that was proposed in~\cite{snb2021}, even though it was
clearly on the table: When justifying the need to control hoarding of CBDC,
@@ -181,30 +351,367 @@ citizens and businesses would themselves determine appropriate individual
limits for their CBDC holdings based on their actual cash needs.
+\section{Design principles for CBDCs}
+
+We think that any CBDC must be based on the following design principles
+inspired by~\cite{dold2019}, given in order of priority:
+
+\begin{enumerate}
+ \item \textbf{A CBDC must be implemented as Free Software.}
+
+ Free refers to ``free as in free speech'', as opposed to ``free as in free beer''.
+ More specifically, the four essential freedoms of free software
+ \cite{stallman2002essays} must be respected, namely users must have the
+ freedom to (1) run the software, (2) study and modify it, (3) redistribute
+ copies, and (4) distribute copies of the modified version.
+
+ This prevents vendor lock-in, as another software provider can
+ take over, should the current one provide inadequate quality of service.
+ Only Free Software can be seen as truly respecting the sovereignty of
+ citizens using the software, as well as countries relying on it.
+ As the ECB report states, international or even cross-border use of a
+ CBDC may be desireable, but this excludes solutions that would be under
+ the control of one nation unless we presume that nations will be willing
+ to subject critical infrastructure to the whims of other nations.
+ Recent attacks by the US government against Huawei effectively limited
+ Huawei's ability to use US software~\cite{huawei}. Such political games
+ can cause significant suffering for the population when they impact
+ critical infrastructure. It is thus clear that
+ only domestic or Free Software is acceptable for critical infrastructure of sovereign
+ countries. Cross-border payments using the same payment system
+ require at least one country to use
+ non-domestic software. Thus, only with Free Software all countries and
+ organizations can run the payment system without the risk of being controlled by
+ foreign entities. Customers benefit from this freedom, as the wallet
+ software can be made to run on a variety of platforms, and user-hostile
+ features such as tracking or telemetry could easily be removed from
+ wallet software.
+
+ This rules out the mandatory usage of specialized
+ hardware such as smart cards or other hardware security modules, as the
+ software they run cannot be modified by the user. These components can,
+ however, be voluntarily used by merchants, customers or payment processors
+ to increase their operational security.
+
+ \item \textbf{A CBDC must protect the privacy of buyers.}\label{item:privacy}
+ % FIXME: I'd suggest a comma after 'possible',
+ % otherwise 'possible' might be understood as
+ % a adjective for 'privacy'.
+ Where possible privacy should be guaranteed via technical measures as opposed to mere
+ organizational policies. Especially with micropayments for online content, a
+ disproportionate amount of rather private data about buyers would be revealed, if
+ the payment system does not have privacy protections.
+
+ In legislations with data protection regulations (such as the recently introduced GDPR in Europe~\cite{voigt2017eu}),
+ merchants benefit from this as well, as no data breach of customers can happen if this information
+ is, by design, not collected in the first place. Obviously some private data, such as the shipping
+ address for a physical delivery, must still be collected according to business needs.
+
+ The security of the payment systems also benefits from this, as the model
+ shifts from authentication of customers to mere authorization of payments.
+ This approach rules out whole classes of attacks such as phishing~\cite{garera2007framework} or credit
+ card fraud~\cite{sahin2010overview}.
+
+ \item \textbf{A CBDC must enable the state to tax income and crack down on
+ illegal business activities.}
+
+ Naturally, a central bank cannot deploy a payment system that does not
+ meet broadly accepted rules and regulations for payment systems. While
+ it is conceivable that specific rules and regulations may be modified to
+ accomodate a CBDC, it is inconceivable that states would relax the rules
+ to the point where businesses receiving income are not held accountable
+ for their actions, especially as there seems to be a broad consensus that
+ levying of taxes based on economic activity is beneficial to society.
+
+ \item \textbf{A CBDC must prevent payment fraud.}
+
+ This imposes requirements on the security of the system, as well as on the
+ general design, as payment fraud can also happen through misleading user
+ interface design or the lack of cryptographic evidence for certain
+ processes.
+
+ \item \textbf{A CBDC must only disclose the minimal amount of information
+ necessary.}
+
+ The reason behind this goal is similar to (\ref{item:privacy}). The
+ privacy of buyers is given priority, but other parties such as merchants
+ still benefit from it, for example, by keeping details about the merchant's financials
+ hidden from competitors. Similarly, the central bank should not know
+ all the details of say the contract between a merchant and a consumer, and
+ only learn the amount transacted. Other state agencies, such as the tax
+ office during a tax audit, may be able to compell merchants to disclose
+ additional information, but again always only the minimal amount necessary
+ for the specific function.
+
+ \item \textbf{A CBDC must be usable.}
+
+ Specifically it must be usable for non-expert customers, such as children.
+ We note that account-based payments are generally not accessible to
+ children, as they are often unable to open a regular bank account under
+ current rules. This alone is a good reason for a CBDC to not be
+ account-based! Usability also
+ applies to the integration with merchants, and informs choices about the
+ architecture, such as encapsulating procedures that require cryptographic
+ operations into an isolated component with a simple API.
+
+ \item \textbf{A CBDC must be efficient.}
+
+ Approaches such as proof of work are ruled out by this requirement. Efficiency is
+ necessary for a CBDC to scale to the hundreds of thousands of transactions
+ required to support larger economic areas. Efficient payments can also open
+ up new use-cases by enabling micropayments.
+
+ \item \textbf{A CBDC must avoid single points of failure.}
+
+ While a central bank is itself kind-of a single point of failure and inherent
+ in a CBDC, the technical deployment should avoid single
+ points of failure. This manifests in architectural choices such as
+ the isolation of certain components, and auditing procedures.
+
+ \item \textbf{A CBDC must foster competition.}
+
+ It must be relatively easy for various commercial businesses to operate
+ components of the overall payment system. While the
+ barriers for this in traditional financial systems are rather high, the
+ technical burden for new operators to join must be minimized. Operators
+ may incluce licensed entities such as banks (for operations that are closely
+ related to the payment processing), but also unlicensed entities can partake
+ in activities such as enabling backups or integrating payment services at
+ retailers. A design choice that supports this is to split the whole system into smaller
+ components with well-defined protocols between them, such that the various
+ components can be operated, developed and improved upon independently,
+ instead of having one completely monolithic system.
+
+\end{enumerate}
+
+In our opinion, any candidate for CBDC must follow at least those principles
+to be trustworthy and successful.
+
+A cross-cutting concern here is that when achieving the security goals, the
+CBDC must never rely on the central bank being trustworthy. Good security
+designs always strive to avoid trusted parties. This implies that neither the
+correctness nor the privacy assurances must rely on an honest central bank.
+This false sense of security also became evident when the former director of
+the NSA (DIRNSA) revealed his belief that with respect to control over the
+toxic data assets accumulated by the NSA ``nobody comes after us''~\cite[page
+ 6f]{cwps}, suggesting that the (by the DIRNSA clearly presumed trustworthy)
+US government would never fall. The assumption turned deadly when the Taliban
+took over personal profiles including biometric data of Afgahnis that had
+collaborated with NATO forces after the retreat of NATO in
+2021~\cite{afganistan2021}. We must not make the same mistake, that is
+believing that our institutions are good and eternal, when it comes to our
+private payment data. Thus, it is necessary that technical protections for our
+privacy are put in place that even the central bank cannot break:
+
+Privacy is most meaningful when it is guaranteed via technical measures, as
+opposed to mere policies. Without a technical layer providing
+privacy-by-default, financial transactions reveal unnecessary levels of
+personal or private data. This would be especially true if a CBDC became a
+ubiquitous payment method. Thus, a CBDC must protect the privacy of buyers and
+avoid the use of accounts to avoid facilitating totalitarian control over the
+population. Limited private data, such as the shipping address for a physical
+delivery, may need to be collected by merchants (but not the central bank)
+according to business needs and protected according to local laws. In this
+case, the CBDC must enable deletion of such data as soon as it is no longer
+required.
+
+A possible trap for the design of a privacy-respecting CBDC is central banks
+merely delegating responsibility for privacy-sensitive data to commercial
+banks. Such a delegation does not provide adequate protection against state
+overreach, as commercial banks still could too easily be compelled to sanction
+opposition against the ruling party. Nevertheless, Auer's
+proposal~\cite{bis948} to delegate the technical operation of a CBDC to
+tightly supervised commercial banks as an alternative to the central bank
+acquiring the technological prowess to centrally operate such a system has
+merit: such a delegation can eliminate a likely single point of failure, and
+might entice commercial banks to diversify the feature set. It would also give
+commercial banks a raison d'être, and thus mitigate the risks from CBDC
+disintermediation. In order for commercial banks to make a valuable
+contribution when operating the CBDC, we believe the central bank would still
+need to set an open standard to ensure interoperability. Strict
+cryptographically-enforced privacy-assurances for consumers must be baked into
+such a standard.
+
+\section{GNU Taler}
+
+We have implemented the GNU Taler token-based payment system based on the
+above principles~\cite{dold2019}. GNU Taler offers an alternative to
+ID/account-based systems, while still enabling the state to ensure business is
+legal (and tax-paying) without infringing on the sovereignty of private
+citizens.
+
+In addition, CBDCs should also provide additional benefits compared to existing
+digital payment systems. One of the key questions the ECB report raises is
+what it might take for a CBDC to be successful in the market, as the authors
+realize that even if a central bank offers a payment system, this does not
+assure that the population will adopt it to a meaningful extend.
+
+So far, we have already given several reasons for adoption, including the use
+of Free Software, the protection of privacy, usability and cost-effectiveness.
+Furthermore, we believe that a CBDC should also strongly consider the issue of
+inclusion, from children to illiterate or innumerate users which are
+underserved by contemporary commercial payment solutions. When it comes to
+serving children, age-verification for Websites is a related domain where
+digital identity-based solutions are inappropriately pursued today: With
+Taler, we can cryptographically extend the principle of strictly protected
+privacy also into the domain of age restrictions in
+e-commerce~\cite{designagerestriction2021}. By integrating age restrictions
+with privacy-preserving payments, we can enable legal guardians to protect
+their wards without contributing to the conversion of sovereign citizens to
+digital subjects. This extension offers benefits for society in multiple
+ways: Buyers remain anonymous during payment, yet efficacy of age restriction
+is guaranteed. Anonmyous age restriction during payment simplifies processees
+for merchants significantly. It is based on the principle of subsidiarity and
+gives control over age restriction to closest responsible persons (generally
+the parents). And finally, for more than 5 million children in the European
+Union between 10 and 18~\cite{EurostatAge10} this would allow participation in
+e-commerce more freely.
+
+Assuming that owners of bank-accounts are mature adults, it allows them to
+withdraw age-restricted coins for their wards. The wards can then anonymously
+spend the coins, but transactions will fail at merchants that sell goods with
+an age restriction exceeding the age-limit of the coins as specified by the
+bank account holder, acting as a guardian. This design guarantees that the
+only information disclosed is that the age-restriction imposed by the merchant
+is satisfied - but not the age itself. The payment service provider does not
+even learn that age-restrictions are being used, and merchants cannot
+distinguish successful purchases by adults from successful purchases by wards
+with a sufficiently high age-limit. Thus, this design offers a clear
+alternative to identity-based age-verification that is better aligned with the
+principle of subsidiarity which requires that we solve problems at the smallest
+unit that can solve them. And protecting the children should be the task of
+their parents. We argue that the ECB should merely give the parents the
+technical means to protect their children as they see fit, instead of taking
+control.
+
+
+\section{Tokenization beyond CBDC}
+\label{sec:tokenization}
+
+With electronic tokens it is possible to implement payment systems that are
+not CBDCs. For example, a Swiss group around Claudio
+Zanetti~\footnote{\url{https://www.zanetti.ch/}} is considering launching an
+electronic payment system based on gold. Direct payments with physical gold
+are problematic, as giving change
+is impractical with
+gold as is the validation that the gold is pure. With eGold, Zanetti plans to
+``establish a private competitor to the Swiss National Bank, that is not able
+to deflate economic crises by inflating the currency at the expense of the
+working class''.\footnote{Personal communication.} It remains to be seen if
+this effective limitation on central bank policy making is ultimately
+beneficial, given the ecological cost of mining gold and the detrimental effect
+of rampant economic crises on the poor. Regardless, the idea is interesting as
+it may require governments to take a more preventative stance against economic
+crises --- and economists (naturally ignoring the global environmental impact
+of mining gold) have previously claimed that a competing gold-backed payment
+system might be inherently beneficial to the (Swiss) economy~\cite{nzz}.
+
+Systems like Bitcoin and Ethereum that are based on distributed ledger
+technology (DLT) are often confused with true token-based systems. In Bitcoin and
+Ethereum funds are still stored in accounts that have a value because of an
+incoming transaction, and not because some issuer backs the token. With the
+Depolymerizer~\footnote{\url{https://git.taler.net/depolymerization.git}} we
+have created an adapter that allows the tokenization of blockchain-based
+cryptocurrencies. Here, the cryptocurrency would be held in escrow by a
+trusted third party that backs the tokens representing Bitcoin or
+Ether. By reducing the need for on-chain transactions, we expect that a
+Depolymerized DLT can in theory scale linearly with the available
+computational resources, primarily limited by the much slower transaction rate
+of the underlying DLT for inbound and outbound on-chain transactions. The
+resulting system would also provide durable transactions within milliseconds,
+making cryptocurrency payments significantly more practical. However, like
+with e-gold it would do nothing to mitigate the environmental cost of
+(cryptocurrency) mining, so fiat currency remains an environmentally
+preferable choice.
+
+For the conversion between fiat currency, e-gold and Depolymerizer-tokenized
+cryptocurrencies it is likely that regulated payment service pro\-viders will
+be required to perform some kind of KYC procedure to
+identify their customers. However, this is no different from identification
+procedures required by banks today, and hence hardly predicated on the
+creation of a national or even global electronic identity platform with its
+associated dangers for individual freedom and
+democracy~\cite{Helbing2019,french2021}.
+
+An interesting aspect that all these electronic payment systems based on a
+tokenization system would share is that they require some trust
+into the issuer of the currency, as in all cases the issuer could renegotiate on its
+promise to redeem the electronic tokens for the underlying asset.
+For such systems it should be possible for third parties to audit the issuer of
+tokens~\cite{dold2019}, which in the absence of fractional reserve banking
+reduces the risk from the issuer to that of the underlying asset class.
+
+We note that issuer risk always exists and this mitigation is crucial. With
+cryptocurrencies, an issuer (like a cryptocurrency exchange) defaulting is
+a type of exit scam commonly called a ``rug pull'' for cryptocurrency
+``investments''.~\cite{rugpull} For (largely historic)
+currencies tied to gold such a ``default'' was legalized by calling it
+``abandoning the gold standard'' or ``currency reform''. We note that even
+modern fiat currencies usually have some limited backing in the form of assets
+held by the central bank that the central bank is expected to wisely use these
+assets to stabilize the value of its currency. Here, the equivalent of an exit
+scam is hyperinflation from quickly balooning central bank liabilities. The
+effect is equivalent to an exit scam, as it again effectively disowns the
+holders of the central-bank backed tokens. Hence, even central bank
+liabilities are hardly ``risk-free assets'', a final questionable claim
+repatedly made in the ECB's report. The same assumption of the Euro not
+requiring trust into the ECB is made in the French report. In their section on
+trust, the authors try to contrast ``natural'' trust in fiat currencies with
+``abnormal'' trust for cryptocurrencies. The authors write that ``While trust
+in money has long relied on a mechanical guarantee in gold or the role of the
+state, neither of these guarantees of trust exist for
+cryptocurrencies.''\footnote{Si la confiance en la monnaie a longtemps reposé sur une garantie mécanique en or ou sur le rôle de l’État, aucun de ces gages de confiance existent pour les cryptomonnaies. }. Here, the authors pretend to be unaware that the Euro is
+neither based on a mechanical guarantee in gold (first abandoned in France
+during the First World War and then definitively under the Popular Front
+almost a century ago), nor on the role of a state since the Eurozone has none
+of the prerogatives of a state (army, tax, foreign policy, or even
+government).
+
+Confidence in fiat currencies is much more complex than what is described in
+the French report, and one must at least include the following elements:
+\begin{itemize}
+\item confidence in the non-inflationary nature of the currency (it can be hoarded without significant risk)
+\item confidence in the stability of the exchange rate (it is safe to trade with other assets)
+\item confidence in the banking system (that assets will not disappear overnight)
+\end{itemize}
+All these properties are currently those of the major European currencies,
+even if this has not always been the case. From this perspective, we can see
+that some of the large crypto-currencies also more or less respect these
+criteria (with some problems on the side of price stability).
+
+
+
\section{Conclusion}
+There are no trusted third parties. That does not prevent people from
+designing and deploying systems that rely on the assumption that a trusted
+third party exists. Central banks must not follow the former DIRNSA's
+hybris~\cite[page 6f]{cwps}
+and assert that they are an eternally trusted third party.
+
The dominance of accounts on the Internet and the resulting delegation of
economic and political power to big Internet service providers sets a
dangerous precedent for the design of CBDCs. It is time for central banks
-to abandon this mindset.
-
-Specifically, the ECB needs to review its design approach for the Digital Euro
-and commit to granting financial soverenity to its constituents. Instead of
-controlling the citizen's privacy and forcing a particular ECB App onto CBDC
-user's phones, the ECB needs to design a Digital Euro based on respect for the
-citizen's sovereignity and self-responsibility. A digital cash system can be
-build using privacy-preserving open protocols with Free Software reference
-implementations. The resulting self-responsibility of citizens will address
-various key design challenges inherent to account-based designs, including the
-biggest challenge of all: creating a product citizens would actually like to
-use.
+to abandon this account-centric mindset, which will help them address
+privacy issues and help the Internet transcend surveillance capitalism.
+
+More specifically, the ECB needs to review its design approach for the Digital
+Euro and commit to granting financial sovereignty to its constituents. Instead
+of controlling the citizen's privacy and forcing a particular ECB App onto
+% FIXME: I'd suggest "users' phones",
+% unless it is really meant that one
+% user has multiple phones.
+CBDC user's phones, the ECB needs to design a Digital Euro based on respect
+for the citizen's sovereignty and self-responsibility. A digital cash system
+can be build using privacy-preserving open protocols with Free Software
+reference implementations. The resulting self-responsibility of citizens will
+address various key design challenges inherent to account-based designs,
+including the biggest challenge of all: creating a product citizens would
+actually like to use.
%[oec] Highlight again that alternatives _are_ on the table
-\section*{Acknowledgements}
-We thank Martin Summer for encouraging us to put our critique of the ECB's
-report in writing. We thank Ulrich Bindseil for listening.
% We thank XXX for insightful comments on an earlier draft of this text.
@@ -213,3 +720,29 @@ report in writing. We thank Ulrich Bindseil for listening.
\end{document}
+
+Cut for brevity:
+
+
+
+Most crypto-currencies seek to have the properties of a currency, the
+conservation of value and the availability for exchange. For the two largest
+of them (BTC and ETH), we must note that since their creation they have been
+able to play the two roles of a currency. These currencies are both available
+for exchange and can be hoarded. These currencies are subject to great
+variations in price, but they are far from the variations of the Argentine
+Peso (which is commonly considered to be a currency). Some also have limited
+availability for real-time transactions, with Bitcoin for example requiring a
+very long validation time preventing its use for everyday purchases, but can
+be used for remote purchases (say for international remittances) where
+latencies and costs are actually competitive compared to existing payment
+systems.
+
+Central banks manage fiat currencies. These currencies are also mainly
+digital, as often the actual transactions are facilitated by digital payment
+systems bolted on top of the currency provided by the central bank. While it
+is in most cases still possible to use the central bank provided physical cash
+directly, transactions using real coins and bills are declining. The quantity
+of money, as well as the interest rate at which this money is made available
+to banks, allows central banks to influence the value of the currencies they
+manage.
diff --git a/presentations/comprehensive/main.pdf b/presentations/comprehensive/main.pdf
Binary files differ.
diff --git a/standards/errata.txt b/standards/errata.txt
@@ -0,0 +1,6 @@
+* Currencies MUST be interpreted as case-insensitive.
+ (Not specified in the RFC.)
+* Mandate use of "," separator for currencies?
+ (avoids easy bug of someone using a floating point parser?)
+* Stress currency field being mandatory, and say why (i.e.
+ multi-currency bank account or countries with multiple currencies)
diff --git a/standards/links.txt b/standards/links.txt
@@ -0,0 +1,3 @@
+https://github.com/cryptohub-digital/payto
+https://github.com/alexrios/payto
+https://github.com/bence98/libpayto
