[taler-marketing] branch master updated: offline cbdc considerations: WIP

[gnunet]

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new 469146e  offline cbdc considerations: WIP
469146e is described below

commit 469146ee7c3a07ad49f9fbe165bf2133dbf573b9
Author: Florian Dold <florian@dold.me>
AuthorDate: Mon Mar 22 13:23:34 2021 +0100

    offline cbdc considerations: WIP
---
 2021-offline/literature.bib | 37 ++++++++++++++++++++
 2021-offline/offline.tex    | 85 +++++++++++++++++++++++++++++++++++++++------
 2 files changed, 112 insertions(+), 10 deletions(-)

diff --git a/2021-offline/literature.bib b/2021-offline/literature.bib
new file mode 100644
index 0000000..a92fc43
--- /dev/null
+++ 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
index 0218c44..3d6d39e 100644
--- 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}

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.