commit 469146ee7c3a07ad49f9fbe165bf2133dbf573b9
parent c50b6b1d5fd07be4fd505d764114b00f48623cff
Author: Florian Dold <florian@dold.me>
Date: Mon, 22 Mar 2021 13:23:34 +0100
offline cbdc considerations: WIP
Diffstat:
2 files changed, 112 insertions(+), 10 deletions(-)
diff --git a/2021-offline/literature.bib b/2021-offline/literature.bib
@@ -0,0 +1,37 @@
+@Article{calhoun2019puf,
+ AUTHOR = {Calhoun, Jeff and Minwalla, Cyrus and Helmich, Charles and Saqib, Fareena and Che, Wenjie and Plusquellic, Jim},
+ TITLE = {Physical Unclonable Function (PUF)-Based e-Cash Transaction Protocol (PUF-Cash)},
+ JOURNAL = {Cryptography},
+ VOLUME = {3},
+ YEAR = {2019},
+ NUMBER = {3},
+ ARTICLE-NUMBER = {18},
+ URL = {https://www.mdpi.com/2410-387X/3/3/18},
+ ISSN = {2410-387X},
+ DOI = {10.3390/cryptography3030018}
+}
+
+@misc{ecb2020digitaleuro,
+ title = {Report on a digital euro},
+ year = {2020},
+ month = {October},
+ howpublished = {\url{https://www.ecb.europa.eu/pub/pdf/other/Report_on_a_digital_euro~4d7268b458.en.pdf}},
+}
+
+@misc{chaum2021issue,
+ title={How to Issue a Central Bank Digital Currency},
+ author={David Chaum and Christian Grothoff and Thomas Moser},
+ year={2021},
+ eprint={2103.00254},
+ archivePrefix={arXiv},
+ primaryClass={econ.GN}
+}
+
+@inproceedings{chaum1988untraceable,
+ title={Untraceable electronic cash},
+ author={Chaum, David and Fiat, Amos and Naor, Moni},
+ booktitle={Conference on the Theory and Application of Cryptography},
+ pages={319--327},
+ year={1988},
+ organization={Springer}
+}
diff --git a/2021-offline/offline.tex b/2021-offline/offline.tex
@@ -1,13 +1,69 @@
\documentclass{article}
-\title{Why a Digital Euro should not work Offline}
+\usepackage{url}
+
+% The "Report on a Digital Euro" contains some discussion
+% about offline payments in Section 5.1.7.
+% We should make sure to reference/acknowledge this.
+%
+% Furthermore, the ECB seems to see the hardware requirements
+% for a digital euro as a potential to "support the
+% development of a common European end-user solution [...]
+% thereby supporting the digitalisation of the European economy".
+%
+% Section 5.2 makes a rather bad mistake: It first
+% suggests that two types of digital euro can exist.
+% One of them offline, one of them online.
+% However, it then concludes that only the offline-euro
+% should have anonymity: "However, this second type of digital euro would
+% exclude the possibility of anonymity for users."
+
+\title{Why a Digital Euro should be Online-first and Bearer-based}
\author{Christian Grothoff \and Florian Dold}
\date{\today}
\begin{document}
\maketitle
-Three properties are desirable for distributed systems:
+The European Central Bank's ``Report on a Digital
+Euro''~\cite{ecb2020digitaleuro} considers two distinct types of designs for a
+digital euro. It argues that all functional requirements laid out in the report
+can be fulfilled by operating these two types of systems in parallel:
+
+\begin{enumerate}
+ \item A bearer-based digital euro based on trusted hardware that can be used
+ offline, anonymously, and without third-party intervention.
+ \item An account-based digital euro that can be used online, is fully software-based
+ and excludes the possibility of anonymity.
+ % Actually, what's the difference to SEPA instant there?
+\end{enumerate}
+
+% why bad:
+% * assumes that online systems can't be bearer based
+% * assumes online systems can't be anonymous
+% * now *three* systems need to be maintained (cash, online CBDC, offline) CBDC
+
+The report does not discuss other choices of hybrid systems. However, the
+choice is more arbitrary than it might seem at first sight: Bearer-based
+systems are not necessarily offline payment systems, and online payment systems
+do not need to sacrifice anonymity.
+
+We argue that a different hybrid system would be superior in fulfilling the
+requirements laid out in the ECB report:
+
+\begin{enumerate}
+ \item An online, bearer-based payment instrument with anonymity and income
+ transparency features \cite{chaum1988untraceable,chaum2021issue}.
+ \item A limited and optional offline mode for the first payment system
+ \item Physical cash as a fallback for emergency situations where
+ power outages or cyber attacks render a digital euro temporarily
+ unusable.
+\end{enumerate}
+
+\section{Challenges of offline payments}
+
+Payment processing involves a distributed, networked system. Three properties
+are desirable for distributed systems:
\begin{itemize}
\item Consistency: there is one coherent view of the state of
the system and no contradictory believes held by different
@@ -17,7 +73,7 @@ Three properties are desirable for distributed systems:
perform transactions for the system's users.
\item Partition tolerance: the system tolerates network or
component failures which makes communication between
- parts of the distributed system temporarily impossible.
+ parts of the distributed system temporarily impossible.
\end{itemize}
The well-known CAP theorem proves that it is impossible to design a
@@ -27,12 +83,15 @@ simultaeneously protect against double-spending (Consistency) while
operating (Available) offline (Partition-tolerance). Thus, any
offline electronic payment system is left with one of the following
choices:
+
\begin{itemize}
\item Protect against double-spending by taking away
control over computing from the user, typically using
hardware security elements that prevent the user from
accessing certain functions of the device.
-\item Retroactively identifying the user after network
+\item
+ % FIXME: this is a bit too technical
+ Retroactively identifying the user after network
connectivity is restored, in privay-preserving systems
using conditional deanonymization, and attempting to recoup
the losses from the double-spending party afterwards.
@@ -43,7 +102,7 @@ could implement these designs (like blaming the merchant and forcing
merchants to cover the double-spending cost), the list is basically
exhaustive.
-\section{Hurting security}
+\subsection{Hurting security}
If breaking the restrictive computing element's security properties
gives users the ability to access virtually unlimited funds, they
@@ -60,7 +119,7 @@ to cover the costs of the multi-spend. At scale, the resulting
potential attacks could endager financial stability.
-\section{Hurting informational self-determination}
+\subsection{Hurting informational self-determination}
Both of the above choices hurt the user's fundamental human right to
informational self-determination. Forcing users to use hardware that
@@ -75,7 +134,7 @@ the privacy assurances of the system. A key security property of the
systems would thus be weakened and becomes brittle.
-\section{Hurting availability}
+\subsection{Hurting availability}
A hardware-based solution not only limits availability to those
users that can afford the device, but also limits user's ability
@@ -98,7 +157,7 @@ preserving physical cash will help much more, while an offline CBDC is
unlikely to significantly improve availability.
-\section{Hurting innovation}
+\subsection{Hurting innovation}
In a world where everything is headed towards software solutions, a
mandatory hardware security solution for a CBDC is pretty restrictive,
@@ -110,7 +169,7 @@ reinforcing existing anti-competitive monopolies in the hardware
market.
-\section{Hurting cash}
+\subsection{Hurting cash}
The abilitiy to continue to use physical cash is priced by central
banks, citizens and experts in disaster management. In situations
@@ -123,7 +182,9 @@ A CBDC that competes with cash by providing offline functionality
has a higher potential of harming the use of cash than a CBDC that
is online-only.
-\section{Conclusion}
+\section{An alternative hybrid system}
+
+FIXME: Describe Taler's properties of income transparency and anonymity here
Adding offline capabilities to a CBDC weakens it overall, while having
physical cash as a non-digital fallback readily available strengthens
@@ -145,4 +206,8 @@ offline-scenario.
We thank Thomas Moser for insightful comments on an earlier draft of this text.
+\bibliographystyle{alpha}
+\bibliography{literature}
+
+
\end{document}
