[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-marketing] branch master updated: offline cbdc considerations: WI
From: |
gnunet |
Subject: |
[taler-marketing] branch master updated: offline cbdc considerations: WIP |
Date: |
Mon, 22 Mar 2021 13:23:40 +0100 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-marketing] branch master updated: offline cbdc considerations: WIP,
gnunet <=