conclusions.tex (11217B)
1 \chapter{Future Work}\label{chapter:future-work} 2 We now discuss future work that builds upon the results presented so far. 3 4 5 \subsection*{Standard Model} 6 Our current instantiation of the Taler protocol relies heavily on hash 7 functions. Since the result by Canetti and others \cite{canetti2004random} 8 about the theoretical impossibility of securely instantiating protocols that 9 rely on the random oracle assumption for their security, a vast amount of 10 literature has been devoted to find instantiations of interesting protocols in 11 the standard model \cite{koblitz2015random}. The Taler protocol syntax could 12 likely be also instantiated securely in the standard model, based existing on 13 blind signature schemes in the standard model. The trade-off however is that 14 while removing the random oracle assumption, typically other less well known 15 assumptions must be made. 16 17 \subsection*{Post-Quantum security} 18 The possibility of post-quantum computers breaking the security of established 19 cryptographic primitives has lately received a lot of attention from 20 cryptographers. While currently most schemes with post-quantum security are impractical, 21 it might be worthwhile to further investigate their application to e-cash, based 22 on existing work such as \cite{zhang2018new}. 23 24 \subsection*{Applications to network incentives} 25 Some peer-to-peer networking protocols (such as onion routing 26 \cite{dingledine2004tor}) do not have inherent incentives and rely on 27 volunteers to provide infrastructure. In future work, we want to look at 28 adding incentives in the form of Taler payments to a peer-to-peer networking 29 platform such as GNUnet. 30 31 \subsection*{Smart(er) Contracts and Auctions} 32 Contract terms in Taler are relatively limited. There are some interesting 33 secure multiparty computations, such as privacy-preserving auctions 34 \cite{brandt2006obtain} that could be offered by exchanges as a fixed smart 35 contract. This would allow a full privacy-preserving auction platform, as 36 current auction protocols only output the winner of a privacy-preserving 37 auction but do not address the required anonymous payments. 38 39 40 \subsection*{Backup and Sync}\label{sec:future-work-backup-sync} 41 Synchronization of wallets between multiple devices is a useful feature, but a 42 na\"ive implementation endangers privacy. A carefully designed protocol for 43 backup and synchronization must make sure that the hosting service for the 44 wallet's data cannot collaborate with the exchange and merchants to deanonymize 45 users or transactions. Thus when spending coins for a payment, devices should 46 not have to synchronously talk to their backup/sync provider. This creates the 47 challenge of allocating the total available balance to individual devices in a 48 way that fits the customer's spending pattern, and only require synchronous 49 communication at fixed intervals or when really necessary to re-allocate coins. 50 51 Another possible approach might be to use Private Information Retrieval (PIR) 52 \cite{goldberg2007improving} to access backup and synchronization information. 53 54 55 \subsection*{Machine-Verified Proofs} 56 We currently model only a subset of the GNU Taler protocol formally, and proofs 57 are handwritten and verified by humans. A tool such as CryptoVerif 58 \cite{blanchet2007cryptoverif} can allow a higher coverage and computer-checked 59 proofs, and would allow protocol changes to be validated in shorter time. 60 61 \subsection*{Coin Restrictions / ``Taler for Children''} 62 By designating certain denominations for different purposes, GNU Taler could be 63 used to implement a very simple form of anonymous credentials 64 \cite{paquin2011u,camenisch2004signature}, which then could be used to 65 implement a Taler wallet specifically aimed at children, in order to teach them 66 responsible and autonomous spending behavior, while granting them privacy and 67 at the same time preventing them from making age-inappropriate purchases 68 online, as the discretion of parents. 69 70 %\subsection*{gnunet-blockchain / deployment of the full stack payment system} 71 %=> no, talk more about integration with real banks, KYC 72 % 73 %\subsection*{P2P payments} 74 % 75 %\subsection*{NFC Wallet} 76 % 77 %\subsection*{large, scalable deployment} 78 %I.e. sharding, db replication, load balancer(s) 79 % 80 %\subsection*{Hardware security module for exchange} 81 % 82 %\subsection*{Bitcoin/Blockchain integration} 83 % 84 %\subsection*{UX study and improvements} 85 %(including tracking/planning of spending) 86 % 87 %\subsection*{News Distribution} 88 89 \chapter{Conclusion}\label{chapter:conclusion} 90 91 % sources and inspirations 92 % https://www.bis.org/publ/arpdf/ar2018e5.pdf 93 % https://www.bis.org/publ/qtrpdf/r_qt1709f.pdf 94 % http://andolfatto.blogspot.com/2015/02/fedcoin-on-desirability-of-government.html 95 96 This book presented GNU Taler, an efficient protocol for 97 value-based electronic payment systems with focus on security and 98 privacy. While we believe our approach to be socially and economically beneficial, a 99 technological impact analysis is in order prior to adopting new 100 systems that have broad economic and socio-political implications. 101 102 Currencies serve three key functions in society:~\cite{mankiw2010macroeconomics} 103 \begin{enumerate} 104 \item As a unit for measurement of value, 105 \item a medium of exchange, and 106 \item a store of value. 107 \end{enumerate} 108 How do the various methods measure up to these requirements? 109 110 \section{Cryptocurrencies vs. Central-Bank-Issued Currencies} 111 112 \begin{figure} 113 \centering 114 \includegraphics[width=\textwidth]{diagrams/bitcoin-market-price.png} 115 \caption[Historical market price of Bitcoin.]{Historical market price (in 116 USD) of Bitcoin across major exchanges (Source:~\url{https://blockchain.com}).} 117 \label{fig:volatility} 118 \end{figure} 119 120 Cryptocurrencies generally fail to achieve the required stability to serve as a 121 reasonable unit of measurement (Figure~\ref{fig:volatility}). The volatility 122 of cyptocurrencies is caused by a combination of a lack of institutions that 123 could intervene to dampen fluctuations and a comparatively limited liquidity 124 in the respective 125 markets. The latter is exacerbated by the limited ability of decentralized 126 cryptocurrencies to handle large transaction volumes, despite their extreme 127 levels of resource consumption. As a result, the utility of decentralized 128 cryptocurrencies is limited to highly speculative investments and to the 129 facilitation of criminal transactions. 130 131 With respect to privacy, completely decentralized cryptocurrencies 132 provide either too much or too little anonymity. Transparent 133 cryptocurrencies create the spectre of discriminatory pricing, while 134 especially for privacy-enhanced cryptocurrencies the lack of 135 regulation creates an attractive environment for fraud and criminal 136 activity from tax evasion to financing of terrorism. 137 138 These problems are easily addressed by combining the register (or 139 ledger) with a central bank providing a regulatory framework and 140 monetary policy, including anti-money-laundering and 141 know-your-customer enforcement. 142 143 \section{Electronic Payments} 144 145 Day-to-day payments using registers are expensive and inconvenient. 146 Using a register requires users to {\em identify} themselves to {\em 147 authorize} transactions, and the use of register-based banking 148 systems tends to be more expensive than the direct exchange of 149 physical cash. However, with the ongoing digitalization of daily life 150 where a significant number of transactions is realized over networks, 151 some form of electronic payments remain inevitable. 152 153 The current alternative to (centrally banked) electronic cash are a 154 payment systems under full control of oligopoly companies such as 155 Google, Apple, Facebook or Visa. The resulting oligopolies are 156 anti-competitive. In addition to excessive fees, they sometimes even 157 refuse to process payments with certain types of legal businesses, 158 which then are often ruined due to lack of alternatives. Combining 159 payment services with companies where the core business model is 160 advertising is also particularly damaging for privacy. Finally, the 161 sheer size of these companies creates systemic risks, just as their 162 global scale creates challenges for regulation. 163 164 As GNU Taler is free software, even without backing by a central bank, 165 Taler would not suffer from these drawbacks arising from the use of 166 proprietary technology. 167 168 Furthermore, Taler-style electronic cash comes 169 with some unique benefits: 170 \begin{itemize} 171 \item improved income transparency compared to cash and traditional 172 Chaum-style e-cash, 173 \item anonymity for payers, 174 \item avoidance of enticement towards consumer debt --- especially 175 compared to credit cards, and 176 \item support of new business models and Internet security 177 mechanisms which require (anonymous) micro-transactions. 178 \end{itemize} 179 180 Central banks are carefully considering what might be the right 181 technology to implement an electronic version of their centrally 182 banked currency, and with Taler we hope to address most of their concerns. 183 Nevertheless, all electronic payment systems, including Taler even 184 when backed by central-bank-issued currencies, come with their own 185 inherent set of risks:~\cite{riksbank2017riksbank} 186 187 \begin{itemize} 188 \item increased risk of a bank run: in a banking crisis, 189 as it is easier to withdraw large amounts of digital 190 cash quickly --- even from remote locations; 191 \item increased volatility due to foreign holdings that would 192 not be as easily possible with physical cash; 193 \item increased risk of theft and disruption: while physical 194 cash can also be stolen (and likely with much less effort), it is 195 difficult to transport in volume~\cite{force2015money}, the 196 risk is increased with computers because attacks scale \cite{hammer2018billion}, and 197 generally many small incidents are socially preferable over a 198 tiny number of very large-scale incidents; and 199 \item unavailability in crisis situations without electricity and Internet 200 connectivity. 201 \end{itemize} 202 203 204 We believe that in the case of Taler, some of the risks mentioned 205 above can be mitigated: 206 \begin{itemize} 207 \item Volatility due to foreign holdings and the resulting increased 208 risk of bank runs can be reduced by putting limits on the amount of 209 electronic coins that customers can withdraw. Limiting the 210 validity periods of coins is another method that can help 211 disincentivize the use of Taler as a value store. 212 \item The use of open standards and reference implementations enables 213 white-hat security research around GNU Taler, which together with 214 good operational security procedures and the possibility of 215 competing providers should reduce the risks from attacks. 216 \item GNU Taler can co-exist with physical cash, and might even 217 help revive the use of cash if it succeeds in reducing credit 218 card use online thereby eliminating a key reason for people to 219 have credit cards. 220 \end{itemize} 221 222 Unlike cryptocurrencies, Taler does not prescribe a solution for monetary 223 policy or just taxation, as we believe these issues need to be subject to 224 continuous political debate and cannot be ``solved'' by simplistic algorithms. 225 What we offer to society is an open and free (as in free speech) system with 226 mechanisms to audit merchants' income, instead of proprietary systems 227 controlled by a few oligopoly companies.