commit 8037f88f2bad1b233ce98b308900bec8664a8d86
parent 469146ee7c3a07ad49f9fbe165bf2133dbf573b9
Author: Florian Dold <florian@dold.me>
Date: Mon, 22 Mar 2021 14:17:50 +0100
better conclusion
Diffstat:
1 file changed, 52 insertions(+), 33 deletions(-)
diff --git a/2021-offline/offline.tex b/2021-offline/offline.tex
@@ -1,6 +1,7 @@
\documentclass{article}
\usepackage{url}
+\usepackage{enumitem}
% The "Report on a Digital Euro" contains some discussion
% about offline payments in Section 5.1.7.
@@ -18,6 +19,12 @@
% should have anonymity: "However, this second type of digital euro would
% exclude the possibility of anonymity for users."
+
+% We still need to mention the following issues:
+%
+% * Offline payments should be a fallback, not regular (migitate risks!)
+% * Payments with anonymity should not be "second class" citizens
+
\title{Why a Digital Euro should be Online-first and Bearer-based}
\author{Christian Grothoff \and Florian Dold}
\date{\today}
@@ -44,21 +51,17 @@ can be fulfilled by operating these two types of systems in parallel:
% * 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
+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.
+do not need to exclude 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}
+We argue that operating a bearer-based payment system to complement an
+account-based CBDC in order to gain offline and privacy features is not a good
+trade-off. Adding permanent, regular offline capabilities via the bearer-based
+payment instrument constantly exposes the CBDC to the severe issues inherent in
+offline-capable payment systems. Instead, the offline mode of operation should
+be restricted to scenarios where it is actually required, which mitigates the
+risks.
\section{Challenges of offline payments}
@@ -100,7 +103,7 @@ choices:
There is no third choice. While there are minor variations how one
could implement these designs (like blaming the merchant and forcing
merchants to cover the double-spending cost), the list is basically
-exhaustive.
+exhaustive.
\subsection{Hurting security}
@@ -182,25 +185,41 @@ 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{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
-the whole system. Trying to accommodate both necessarily (CAP!) gives
-you a hybrid that is not particularly good for either the online or
-the offline scenario.
-
-Given these drawbacks, requiring a CBDC to operate offline is of
-questionable benefit. While having a single uniform payment system
-for everything has some estetic appeal, it only creates significant
-cost benefits if cash were to be abolished entirely. As most central
-banks investigating CBDCs have publicly stated that their goal is not
-to get rid of physical cash, they should then drop offline
-functionality from their list of desired properties, and in fact
-recommend that the technical solution should not work securely in an
-offline-scenario.
+
+\section{Conclusion}
+
+While in some situations, offline payments might be a desireable requirement,
+adding offline capabilities to a payment system comes with substantial risks.
+The exposure to these risks should be limited by only resorting to an offline
+fallback mode of the payment system when actually required.
+
+% FIXME: Probably this is not explained well enough
+Discouraging the use of the offline fallback mode can be easily achieved by by
+exposing the payee to counterparty risk. In a system based on restricted
+hardware elements, the payee would bear the risk in case of a compromised
+hardware system. In a system based on identifying offline double spenders /
+cheaters, the payee would bear the risk in case the offline double spender /
+cheater can't be found and held accountable.
+
+Preliminary results from a survey done by the ECB have shown that privacy is
+regarded as one of the the most important feature by participants among
+citizens and businesses. Only providing privacy in the offline
+payment instrument would make privacy a second class citizen, especially
+as privacy is important in innovative online usages of a digital euro.
+
+Thus, our improved suggestion for a secure, robust and privacy-friendly
+digital euro would be the following hybrid:
+
+\begin{enumerate}
+ \item An online, bearer-based payment instrument with anonymity and income
+ transparency features \cite{chaum1988untraceable,chaum2021issue}.
+ Note that in this proposal, only one of the two parties (payer, payee)
+ needs to have network connectivity.
+ \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*{Acknowledgements}
