[taler-marketing] branch master updated: add Christian's first draft

[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 c50b6b1  add Christian's first draft
c50b6b1 is described below

commit c50b6b1d5fd07be4fd505d764114b00f48623cff
Author: Florian Dold <florian@dold.me>
AuthorDate: Wed Mar 17 16:15:13 2021 +0100

    add Christian's first draft
---
 2021-offline/offline.tex | 148 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 148 insertions(+)

diff --git a/2021-offline/offline.tex b/2021-offline/offline.tex
new file mode 100644
index 0000000..0218c44
--- /dev/null
+++ b/2021-offline/offline.tex
@@ -0,0 +1,148 @@
+\documentclass{article}
+
+\title{Why a Digital Euro should not work Offline}
+\author{Christian Grothoff \and Florian Dold}
+\date{\today}
+\begin{document}
+
+\maketitle
+
+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
+  components.
+\item Availability: the system is ``always'' able to provide
+  its service, which implies making updates to the state to
+  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. 
+\end{itemize}
+
+The well-known CAP theorem proves that it is impossible to design a
+network protocol that simultaneously achieves all three properties.
+For electronic payment systems, this means it is impossible to
+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
+  connectivity is restored, in privay-preserving systems
+  using conditional deanonymization, and attempting to recoup
+  the losses from the double-spending party afterwards.
+\end{itemize}
+
+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.  
+
+\section{Hurting security}
+
+If breaking the restrictive computing element's security properties
+gives users the ability to access virtually unlimited funds, they
+will.  Hardware protections typically fall against well-equipped
+adversaries with plenty of time and expertise. Nation-state attackers
+and organized crime may even find it advantageous to force large-scale
+network outages to bring the payment system into a stage where they
+can multi-spend.
+
+Deanonymization is similarly problematic, as the identified individual
+may actually be the victim of a computer crime. Furthermore, even if
+the guilty party is identified, it is unclear that they would be able
+to cover the costs of the multi-spend.  At scale, the resulting
+potential attacks could endager financial stability.
+
+
+\section{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
+they do not control is limiting their ability to control and customize
+their digital lives.
+
+In privacy-friendly systems (like those based on Chaum) where citizens
+can use digital cash to make purchases anonymously, adding the ability
+to retroactively deanonymize double-spending users implies that
+accidentally double-spending (say after restoring from backup) voids
+the privacy assurances of the system. A key security property of the
+systems would thus be weakened and becomes brittle.
+
+
+\section{Hurting availability}
+
+A hardware-based solution not only limits availability to those
+users that can afford the device, but also limits user's ability
+to make backups of their digital cash. Thus, loosing the hardware
+will result in citizens loosing their digital cash, something a
+software-based solution can avoid.  This drawback can only be
+offset by revealing the user's identitiy which means the solution
+would not offer good privacy protections.
+
+Similarly, in systems where double-spending is detected and later
+penalized, the resulting financial risks will create pressures
+to deny citizens with insufficient reputation or credit score
+from using the system to mitigate operational risk.
+
+One argument for offline CBDC is the objective to improve availability
+in situations where network access is unreliable. However, today
+network availability is usually only problematic in areas where access
+to electrical power is similarly limited. Thus, in these cases
+preserving physical cash will help much more, while an offline CBDC is
+unlikely to significantly improve availability.
+
+
+\section{Hurting innovation}
+
+In a world where everything is headed towards software solutions, a
+mandatory hardware security solution for a CBDC is pretty restrictive,
+not just for customers but also for businesses who want to process
+payments or offer services related to payments.  Furthermore, to
+ensure the security of the solution, the production of approved
+hardware devices would need to be strictly controlled, likely
+reinforcing existing anti-competitive monopolies in the hardware
+market.
+
+
+\section{Hurting cash}
+
+The abilitiy to continue to use physical cash is priced by central
+banks, citizens and experts in disaster management. In situations
+with wide-spread and lasting power outages, digital systems fail,
+and thus having cash as a fall-back is crucial. Children find it
+easier to learn about money if it is physical and not obscured by
+an electronic abstraction. Thus, availability and accessibility of
+physical cash will always be unmatched by electronic solutions.
+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}
+
+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*{Acknowledgements}
+
+We thank Thomas Moser for insightful comments on an earlier draft of this text.
+
+\end{document}

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