commit b2e7752f13874446a0bb5daf1155fc99241e47f0 parent d840c63803896b63a683f0ed15650bdd3aea699f Author: Christian Grothoff <christian@grothoff.org> Date: Thu, 25 Jan 2024 23:17:11 +0100 cleanup Diffstat:
302 files changed, 0 insertions(+), 1994 deletions(-)
diff --git a/2019-osf/taler.md b/2019-osf/taler.md @@ -1,66 +0,0 @@ -GNU Taler: A Digital Cash Commons - -Economic activity is central to modern life, but with the disappearance of -physical cash the monetary foundation for our economy is privatized. -Contemporary trends are frightening: mass-surveillance is enabled by tracking -consumers though payments, payment processors can and do impose economic death -sentences on NGOs, business or individuals they disagree with, and oligopolies -established by Big Tech charge excessive rent on their platforms in the form -of high transaction fees. Alternative currencies using blockchains are mostly -renowned for impractically low transaction rates, excessive energy consumption -and virtually exclusive use for speculation and criminal transactions. - -With GNU Taler, we are creating an electronic payment system that is Free -Software and (according to experts) compatible with existing regulations, -including KYC, AML and GDPR. Payments are processed in existing currencies -like Euros or Dollars. Taler offers customers privacy when they spend their -electronic cash, but at the same time ensures that income is transparent to -the state (facilitating anti-corruption and tax-collection efforts). Taler -scales to millions of transactions per second, and is also environmentally -responsible due to transaction costs substantially below those of cash or -credit cards. As a result, consumers will finally be able to make -micropayments. This will provide an alternative for funding of online -journalists, bloggers and content creators, relieving their current dependence -on advertisement revenue for their income. As a reserve-based system, Taler -also has advantages for economically disadvantaged populations, as consumers -need neither a bank account nor credit-worthiness. Our Free Software -implementation can be modified to accomodate disabled people and to include -educational features to teach users financial responsibility. Parents will be -able to set budgets and restrict purchases of their children to -age-appropriate goods and services. - -Taler's core technology is implemented and documented -(https://docs.taler.net/) by the GNUnet (e.V.) community and Taler Systems SA -(a business we founded to provide commercial support). We integrated the -payment system with various demonstrator applications, from Web shops (such as -WooCommerce) to in-person payments via QR code or NFC. The Taler wallet is -available as a WebExtension for Chrome, Firefox and Brave, and also as an App -for Android. There are ongoing discussions with several central banks (ECB, -SNB) about the use of Taler as a CBDC. We also have a German community bank -partnering with us to bring the system into commercial operation. Several -organizations (like the Tor Project and various publishers) have signed -letters of intent to deploy Taler as soon as we have regulatory approval and -are in operation. A demo of online services that use GNU Taler for payments -is available at https://demo.taler.net/. - -For regulatory approval, we need to still enhance the wallet with backup -functionality, improve the documentation, and find a way to fund independent -security audits. Additional funding is sought to port the Taler wallet to -further platforms, add financial education features that analyze a user's -spending on their own device, improve the documentation, and to translate our -user interfaces into more languages. - -We will deploy the Taler system inside the University of Applied Sciences in -Bern for internal payments in Q1 2020. After this small-scale operation that -requires no regulatory approval, we will complete the integration with the -German bank and proceed to document the system for regulatory approval. Once -approved, we will launch the system with our media partners. Various -non-profits have already signalled their support (Wau Holland Foundation, -Renewable Freedom Foundation, DigitalCourage, as well as many individual -Ashoka fellows, including people involved with Wikipedia and Change.org). -After the launch, we will work in parallel on the integration with more and -more platforms and also continue to push the development of the consumer's -wallet (financial education, accessibility, translation). If we can show -significant up-take, we envision to eventually transition the system to become -a centrally banked digital currency operated by the respective central bank -as legal tender. diff --git a/2019-osf/taler.tex b/2019-osf/taler.tex @@ -1,72 +0,0 @@ -\documentclass{article} -\usepackage[a4paper,total={6in,8in}]{geometry} -\begin{document} -\thispagestyle{empty} -\begin{center} - {\large GNU Taler: A Digital Cash Commons} -\end{center} -Economic activity is central to modern life, but with the disappearance of -physical cash the monetary foundation for our economy is privatized. -Contemporary trends are frightening: mass-surveillance is enabled by tracking -consumers though payments, payment processors can and do impose economic death -sentences on NGOs, business or individuals they disagree with, and oligopolies -established by Big Tech charge excessive rent on their platforms in the form -of high transaction fees. Alternative currencies using blockchains are mostly -renowned for impractically low transaction rates, excessive energy consumption -and virtually exclusive use for speculation and criminal transactions. - -With GNU Taler, we are creating an electronic payment system that is Free -Software and (according to experts) compatible with existing regulations, -including KYC, AML and GDPR. Payments are processed in existing currencies -like Euros. Taler offers customers privacy when they spend their -electronic cash, but at the same time ensures that income is transparent to -the state (facilitating anti-corruption and tax-collection efforts). Taler -scales to millions of transactions per second, and is also environmentally -responsible due to transaction costs substantially below those of cash or -credit cards. As a result, consumers will finally be able to make -micropayments. This will provide an alternative for funding of online -journalists, bloggers and content creators, relieving their current dependence -on advertisement revenue for their income. As a reserve-based system, Taler -also has advantages for economically disadvantaged populations, as consumers -need neither a bank account nor credit-worthiness. Our Free Software -implementation can be modified to accomodate disabled people and to include -educational features to teach users financial responsibility. Parents will be -able to set budgets and restrict purchases of their children to -age-appropriate goods and services. - -Taler's core technology is implemented and documented -(https://docs.taler.net/) by the GNUnet (e.V.) community and Taler Systems SA -(a business we founded to provide commercial support). We integrated the -payment system with various demonstrator applications, from Web shops (such as -WooCommerce) to in-person payments via QR code or NFC. The Taler wallet is -available as a WebExtension for Chrome, Firefox and Brave, and also as an App -for Android. There are ongoing discussions with several central banks (ECB, -SNB) about the use of Taler as a CBDC. We also have a German community bank -partnering with us to bring the system into commercial operation. Several -organizations (like the Tor Project and various publishers) have signed -letters of intent to deploy Taler as soon as we have regulatory approval and -are in operation. A demo of online services that use GNU Taler for payments -is available at https://demo.taler.net/. - -For regulatory approval, we need to still enhance the wallet with backup -functionality, improve the documentation, and find a way to fund independent -security audits. Additional funding is sought to port the Taler wallet to -further platforms, add financial education features that analyze a user's -spending on their own device, improve the documentation, and to translate our -user interfaces into more languages. - -We will deploy the Taler system inside the University of Applied Sciences in -Bern for internal payments in Q1 2020. After this small-scale operation that -requires no regulatory approval, we will complete the integration with the -German bank and proceed to document the system for regulatory approval. Once -approved, we will launch the system with our media partners. Various -non-profits have already signalled their support (Wau Holland Foundation, -Renewable Freedom Foundation, DigitalCourage, as well as many individual -Ashoka fellows, including people involved with Wikipedia and Change.org). -After the launch, we will work in parallel on the integration with more and -more platforms and also continue to push the development of the consumer's -wallet (financial education, accessibility, translation). If we can show -significant up-take, we envision to eventually transition the system to become -a centrally banked digital currency operated by the respective central bank -as legal tender. -\end{document} diff --git a/2021-taler-vs-lightning/taler-vs-lightning.md b/2021-taler-vs-lightning/taler-vs-lightning.md @@ -1,72 +0,0 @@ -# Taler with blockchain adapter vs. Lightning - -## Lightning network - -The lightning network is an additional payment layer on top of Bitcoin. Its -goal is to settle transactions faster without involving a full transaction on -the Blockckain every time that money is moved, because that would be slow and -expensive. - -It works by establishing "payment channels" between two parties, where both -parties "lock" an initial amount (say, Alice locks 2 BTC and Bob locks 1 BTC to -create a channel). - -Signatures communicated outside of the blockchain change how money is allocated -between the two sides of the payment channel. Eventually a payment channel will -be closed by submitting a multi-party signature of the latest allocation between -the two parties to the Blockchain, and the locked money will be sent back to -Alice/Bob according to the most recent allocation. - -A payment can be "routed" through a network of multiple bidirectional channels. -If channels "Alice-Bob" and "Bob-Carol" exist and are funded, then Alice can -send a payment to Carol over the route "Alice-Bob-Carol". - - -Problems: - -* A payment can only be made if route made up of channels exists - between the payer and payee. -* Participating in the Lightning Network requires the participants - to "lock" significant amounts of Bitcoin in a channel, - resulting in opportunity costs. -* To participate in Lightning Network payments, the payer+payee either need - to run their own Bitcoin node (impossible for the average user) - or fully trust a third-party Lightning Network node. -* Privacy of payments is unclear [1], and - there is no notion of "income transparency" for AML/KYC either. -* Even though Lighning Network is theoretically decentralized, - it is tending towards centralization in practice [2]. -* Fraud attempts are possible, and need to be resolved via - a complex penalty system if channels are force-closed - without taking the latest allocation of funds into account -* The implementation is not yet battle-tested [3] - -## Taler with blockchain adapter - -Taler works by providing a central, trusted payment service provider that -settles payments instantly via blind signature tokens. It can work -with Blockchain or any other lower-level settlement layer. - -* Taler requires participants to trust the operator - of the exchange, or at least the responsible auditor(s). - Trust is required until the payment is settled on-chain. -* Payments are always possible and instant when both parties - trust the Taler exchange. Route establishment can't fail, - payment channels can't be force-closed. -* Taler covers more than just the settlement system: There is a wallet software - (including Anastasis) and the merchant backend, which serves as an - (on-premise or hosted) payment gateway that is easy to use for merchants. -* There is no requirement to lock money up-front to participate. - Payer/payee only need a wallet, and do not need to - operate a node that needs to be permanently online. -* Payments with Taler / T-BTC have clear privacy and income-transparency - guarantees, and are based on signed, digital contract terms - between the two parties. -* T-BTC could be operated in two modes: Custodial and non-custodial. - In the custodial version, the exchange would keep and fully manage the - users' Bitcoin, whereas in the non-custodial version, the user would - need their own Bitcoin address. - -[1] https://arxiv.org/abs/2003.12470 -[2] https://iopscience.iop.org/article/10.1088/1367-2630/aba062 -[3] https://news.bitcoin.com/lightning-network-exploits-continue-to-hinder-the-bitcoin-scaling-solution/ diff --git a/2023-blockchain-integration.md b/2023-blockchain-integration.md @@ -1,29 +0,0 @@ -# Taler/Blockchain Synergies - -Two types of complementary Blockchain integration are possible: - -1. Blockchain as underlying account-based settlement layer (RTGS, wholesale CBDC) -2. Blockchain as decentralized, durable, append-only data storage - -# Taler + RTGS Blockchain - -* Blockchain can be used as the underlying account-based settlement layer - * Incoming transactions to exchange are monitored as part of issuing digital cash - * Outgoing payments are initiated by exchange to pay merchants/customers for deposited digital cash -* Requires adapter that exposes HTTP/JSON interface to exchange (called a wire gateway) -* Depolymerizer project implements this for ETH and BTC Blockchains - -Implementation estimates (person-days): -* Subsequent integration w/ different Blockchain: 40-80 - -# Taler + Data Storage Blockchain - -* Taler Exchange can use Blockchain as append-only database for crucial records - (coin invalidations, deposit confirmations, ...) -* Architecture: Exchange has postgresql as caching layer, Blockchain as - source-of-truth. Two-way synchronization between Blockchain and Taler exchange -* Can also be used to improve quantum resilience (c.f. Chaum) - -Implementation estimates (person-days): -* Implementation with first Blockchain: 200-400 -* Subsequent integration w/ different Blockchain: 40-80 diff --git a/ecb/age.txt b/ecb/age.txt @@ -1,94 +0,0 @@ - Age-Restrictions for Taler - -Age-restrictions are part of the agenda of Taler Systems SA to make -digital cash more programmable. We propose to extend Taler with an -innovative age verification tied into the payment process. For this, -the GNU Taler protocol is to be extended with a mechanism that adds -age restrictions to digital coins when they are withdrawn. This will -then allow merchants to perform age verification while preserving the -anonymity of the buyer, providing an alternative to contemporary -identity-based age verfication while also streamlining the checkout -process by integrating payment with age verification. - -Existing solutions -================== - -Contemporary solutions to the problem are primarily special special -debit or credit cards for teenagers. Major players on the US market -are Greenlight (www.greenlightcard.com), Step (step.com) and Current -(current.com). The provider Greenlight, for example offers credit -cards for children and allows parents a fine-grained selection of -businesses that they can be released for payment with the card --- but -not on individual products. One App allows children to manage income -``that they receive from doing household chores'', and set savings -goals. Classic credit card companies like American Express, Visa and -Mastercard issue additional cards to the credit card of the -responsible owner, which young people from 14 years of age can use. -All of these procedures require children to be registered and use -traceable ones Identities (credit card numbers etc.) and therefore -cannot protect the anonymity and privacy of children. Furthermore, -the use of credit cards in particular creates the financial risk of -children going into debt. Also, none of these systems offer an easy -way for merchants to set age restrictions to be attached to individual -products. - - -Properties of the envisioned solution -===================================== - -The introduction of an anonymous age verification coupled to payments -as envisioned by Taler Systems SA is thus new. The planned procedure -will have the following properties: - -1. The age information remains privately under the control of the - account holder who authorized the withdrawl of the age-restricted coins. -2. The protection of children's privacy is guaranteed when buying: - A zero-knowledge proof with the age check during the purchase process - only confirms the required minimum age to the seller. -3. When change is issued, the age limit is carried over to the coins returned - as changed. -4. The labeling and verification of age restrictions of individual products - is possible. -5. The introduction of an age check does not lead to compromises in terms - of data protection. -6. The age verification as part of the payment process simplifies the work - for merchants and enables an efficient implementation in terms of - bandwidth, storage space and computing time. - - -Political relevance -=================== - -According to Eurostat, around ten percent of the European population -in 2020 were children between the ages of 10 and 18 years. It is of -general social interest to enable them economic participation and -allow them to learn how to manage their finances. Existing payment -systems for children, in particular those based on credit cards, keep -getting into trouble due to unauthorized purchases by children. For -example, Apple was approved by the Federal Trade Commission (FTC) in -2014 United States required to pay at least $ 32.5 million in -compensation to parents for failing authorized purchases by their -children. This is one of many examples illustrating the in financial -damage done by credit cards to families. In 2012, the United States -introduced new rules for protection Children's Privacy on the Internet -(COPPA), exposting the lack of protection of children's privacy -in the current technical state of the Internet and its services. - - -Conclusion -========== - -The envisioned extension of GNU TALER will allow parents to give their -children pocket money with age restrictions as determined by the legal -guardian. Parents will have the certainty that the children are only -able to buy goods and services that meet the age restriction, and -merchants will be able to easily specify and enforce the age -restrictions without additional cost to the merchant, avoiding the -need for expensive registration processes and the risks of storing -sensitive personal data of their customers. - - -Contact -======= - -grothoff@taler-systems.com diff --git a/ecb/answers.txt b/ecb/answers.txt @@ -1,436 +0,0 @@ -# Answers to ECB survey "Your views on a digital Euro" - -(https://www.ecb.europa.eu/euro/shared/files/Questionnaire_on_a_digital_euro.pdf) - - -# Question 1 - -How would you rank, in order of importance, the features that a -digital Euro should offer? - -## Answer: - -Important: -h. I want it to be a secure means of payment. -c. I want to be able to use it with my smartphone and at payment -terminals. -b. I want my payments to remain a private matter -e. I want it to be easy to use. -i. I want my transactions to be completed instantaneously. -a. I want to be able to use it throughout the Euro area. -f. I want to use a digital Euro without having to pay additional costs. - -Not important (exclude if possible): -d. I want to be able to pay even when there is no internet or power -connection. -g. I want it to take the form of a dedicated physical device. - -Comments: - -The ability to pay securely without Internet or power connection requires the -use of proprietary, trusted hardware modules and excludes a solution solely -based on sofware and open standards. Futhermore, as also noted in the ECB -report on the digital Euro, a digital Euro would merely supplement cash. As -such, we think that cash is already an approproate fall-back payment solution -in case of power or network outages. - - -# Question 2 - -Do you envisage any challenges associated with a digital Euro that would -prevent you or others from using it? If so, what are they? - -## Answer: - -A digital Euro that requires proprietary hardware, proprietary software or that -is based on patent-encumbered technology would severely restrict its use as the -basis for innovations in the field of retail payments, as well as stifle the -development of user-centric services and assistive/accessible technologies for -it. - -A digital Euro that does not offer privacy protections is unlikely to be -able to compete with existing commercial payment providers. - -Thus we recommend that the digital Euro should be based on an open standard -that implements privacy-by-design and privacy-by-default (see GDPR) while also -including adequate provisions for KYC/AML/CFT, and is accompanied by a Free -Software reference implementation. - -# Question 3: - -What user features should be considered to ensure a digital Euro is accessible -for people of all ages, including those who do not have a bank account or have -disabilities? - -## Answer: - -In accordance with the answer to question 2, only a digital Euro that is based -on an open standard without requiring proprietary software or hardware can be -easily adapted to the diverse needs of users that have disabilities or -additional age-related requirements. - -To enable access to the digital Euro for tourists, unbanked or even stateless people -residing in the European Union, we recommend a hybrid solution of an -account/token-based system, where digital Euros are kept as a blind-signed token -in wallets, but receipt of funds through a digital Euro payment must always -pass through a KYCed account. - -We note that when we talk about a token-based system, we do NOT talk -about an offline-capable digital Euro. This seems to be conflated in -the ECB's report on the digital Euro (and in the Bitkom response to -this survey). A token-based system can be online-only, especially -if it is based on software with digital signatures and not on -secure hardware. - - -# Question 4: - -There are two approaches we can take to make a digital Euro work, one that -requires intermediaries to process the payment and one that doesn’t. - -If we design a digital Euro that has no need for the central bank or an -intermediary to be involved in the processing of every single payment, this -means that using a digital Euro would feel closer to cash payments, but in -digital form – you would be able to use the digital Euro even when not -connected to the internet, and your privacy and personal data would be better -protected. - -The other approach is to design a digital Euro with intermediaries recording -the transaction. This would work online and allow broader potential for -additional services to be provided to citizens and businesses, creating -innovation opportunities and possible synergies with existing services. For -example, it could make it easier to integrate a digital Euro into currently -available electronic banking services and applications. From your perspective, -which of the following do you find most appealing? (select one): - -a. a digital Euro focused on privacy and the protection of personal data, -which can be used offline; -b. a digital Euro with broader potential for additional services, allowing -innovative features and other benefits for citizens and businesses; -c. a combination of both. -For more information, please refer to Sections 5.1.5 and 6.1 of the Eurosystem Report on a digital Euro - -## Answer: - -c. a combination of both - -The user of intermediaries does not conflict with privacy when the digital Euro -is based on Chaum-style blindly signed electronic cash with income -transparency. - - -# Question 5 - -What role do you see for banks, payment institutions and other commercial -entities in providing a digital Euro to end users? - -## Answer: - -Existing commercial banks should continue to be responsible for consumer and -business KYC, and the management of savings and loans. Software companies -should provide integration services, both for consumers with special needs -(such as disabilities) and for merchants wanting to accept payments using -digital Euros. Most existing digital payment processing businesses built -around credit cards should wither, as these middleman are too expensive -for their limited added value. - -# Question 6 - -A digital Euro may allow banks and other entities to offer additional services, -on top of simple payments, which could benefit citizens and businesses. - -What services, functionalities or use cases do you think are feasible and -should be considered when developing a digital Euro? - -For more information, please refer to Section 6 of the Eurosystem Report on a -digital Euro - -## Answer: - -We see a limited use for "smart contracts". Here, most likely very few -well-defined built-in contracts (such as currency trading and -privacy-preserving digital auctions, as proposed by Prof. Brandt (TUM)) could -be useful. A Turing-complete general smart contract runtime would likely be -too slow, too generic, too insecure and most importantly lead to digital -contracts that would not be understood by their human users. - -Low-cost digital Euro payments can open the door to micro-payments, where users -may request payment to read e-mail (killing spam), servers may request payment -before returning expensive resources (limiting DDoS attacks), and online -publishers may process payments for each article instead of relying on -advertising or long-term subscriptions. - -A well-designed digital Euro platform could be used to not only process -payments involving digital Euros, but might also serve to digitize stock -exchanges if digital coins are used to represent securities like company shares -and handle corporate actions such as voting rights. Integrated currency trading -would then also enable stock trading. - -Regarding smart contracts derivatives, for instance, could be a -fertile territory to use them since payments and deliveries are -dependent on a conditional logic. However, one cannot only focus on -the economic terms and the payment mechanics of individual -transactions. They are not taking into account overarching contractual -terms regulating the broader contractual relationship between the -parties (like the rules from the International Swaps and Derivatives -Association, ISDA). Examples are the requirement to deliver certain -documents to the other party, payments that are subject to withholding -tax or the insolvency of a party. - -A Touring-complete general smart contract runtime where end-users can -submit arbitrary contracts for execution cannot enforce such rules, while -centrally approved digital contract templates following a well-defined -legal framework can be written (and continuously adapted) to satisfy the -regulatory environment. Ethereum is dominated by a few different smart -contract templates (the most well-known one being ERC-20 tokens), so is -seems plausible that only allowing smart contracts that have been vetted -and undergone regulatory approval would suffice to address most of the -social needs, while also minimizing risks to the platform. - - -# Question 7 - -What requirements (licensing or other) should intermediaries fulfil in order to -provide digital Euro services to households and businesses? Please base your -answer on the current regulatory regime in the European Union. - -## Answer: - -Any digital Euro solution must be based on Free Software reference -implementations of open APIs (no patents, no royalties for the design) -to ensure a level playing field for all actors. The design must -furthermore implement privacy-by-design and privacy-by-default (see GDPR) -while also including adequate provisions for KYC/AML/CFT. We know this -is possible. - -# Question 8: - -Which solutions are best suited to avoiding counterfeiting and technical -mistakes, including by possible intermediaries, to ensure that the amount of -digital Euro held by users in their digital wallets matches the amount that has -been issued by the central bank? - -## Answer: - -Cryptographic signatures are the first line of defence, with a proper design -ensuring that post-hoc audits can attribute failures to the respective guilty -party. Automated real-time audits of both the internal records and financial -transactions of the payment service can aid in early detection of technical -mistakes or a compromise. Additionally, modern designs can ensure that -financial losses from time-limited compromises of a party are at least bounded -to the volume handled by that party during the time window of the compromise. - -# Question 9 - -What technical solutions (back-end infrastructure and/or at device level) could -best facilitate cash-like features (e.g. privacy, offline use and usability for -vulnerable groups)? - -## Answer - -Blind signatures for Chaum-style digital cash remain the best foundation -for cash-like digital payments. However, modern designs add additional -capabilities, such as giving change, key management (expiration of -key material) and charge reversal (refunds). - -We believe that offline use should not be considered for digital -payments. With software-only offline use, it is always possible for customers -to engage in double-spending while the global system state is -inconsistent. Given that electronic transactions can be automated, -the damage from double-spending is not double, but potentially -unlimited. Recouping funds after double-spending may not be possible -in cases where the culprit has privacy, does not have the economi c -means, or even was a victim of a (cyber)crime themselves. - -Offline payments based on special-purpose hardware are in conflict -with an open design and implementation of a digital Euro wallet that -other parties can improve and innovate on. Furthermore, the long-term -security and impact on privacy of such hardware modules is -questionable. Such hardware-based designs typically try to protect -their operational logic against their "owner", who has full physical -access to the device. This is typically a loosing battle, as physical -security mechanisms are very good at delaying access, but usually -break given an attacker with the right tools and enough time. - -Furthermore, offline use is already adequately addressed by the -existing physical cash, which should be preserved as a means of -payment. - - -# Question 10 - -What should be done to ensure an appropriate degree of privacy and protection -of personal data in the use of a digital Euro, taking into account anti-money -laundering requirements, and combating the financing of terrorism and tax -evasion? - -## Answer - -A good trade-off is to ensure that anyone obtaining digital cash must identify -to withdraw, and that anyone receiving digital cash must deposit it immediately -into a KYC'ed bank account to provide income transparency. Additionally, anyone -receiving digital cash should be responsible to provide digital evidence (like -a digital contract) cryptographically tied to the transaction that explains why -the funds were received. At the same time, the system MUST NOT identify the -spender (unless reaching certain limits or involving special transactions), -thus ensuring that citizens have privacy in where they spent their money while -also making sure that merchants receiving funds can be held to account. - - -# Question 11 - -The central bank could use several instruments to manage the quantity of -digital Euro in circulation (such as quantity limits or tiered remuneration), -ensuring that the transmission of monetary policy would not be affected by -shifts of large amounts of commercial bank money to holdings of digital Euro. - -What is your assessment of these and other alternatives from an economic -perspective? - -(Tiered remuneration is when a central bank sets a certain remuneration on -holding balances of digital Euro up to a predefined amount and a lower -remuneration for digital Euro holding balances above that amount.) - -## Answer - -Withdrawal limits on digital cash, possibly combined with an expiration time -for the validity of digital cash signatures, are sufficient to manage the -quantity of digital cash in circulation. Reasonable withdraw limits will -likely even be requested by citizens, as they may want to limit the damage from -someone compromising their online banking credentials and then illicitly -withdrawing digital Euros on their behalf. - -# Question 12 - -What is the best way to ensure that tiered remuneration does not negatively -affect the usability of a digital Euro, including the possibility of using it offline? - -## Answer - -Tiered remuneration should not be applied to the digital Euro, just like it is -not applied to cash. Instead, large holdings of digital Euros should be -controlled via withdrawal limits, possibly in combination with digital -signature expiration to limit hoarding over extensive periods of time. -Similar mechanisms are used with cash today, where some countries have -imposed withdraw limits and physical bank notes are often removed from -circulation (after 20+ years). - - -# Question 13 - -If a digital Euro were subject to holding balance limits, what would be the best -way to allow incoming payments above that limit to be shifted automatically into -the user’s private money account (for example, a commercial bank account) -without affecting the ease of making and receiving payments? - -## Answer: - -Incoming funds from transactions in digital Euros should not be directly placed -into the receiver's electronic wallet at all, but always into their regular -bank account or a special-purpose KYCed account that will immediately used to -withdraw digital Euros again. Citizens should obtain digital Euros only by (1) -withdrawing them from a KYC-enabled account, (2) receiving them as subsidies from -the government, or (3) non-transactional (trusted) sharing of funds (say -between family members sharing a wallet). This way, withdrawal limits on -digital currency can be used to easily limit holdings, and the state can -enforce taxation on income and revenues by auditing (regular) commercial bank -account transactions. - -Given the current state of computer security, holding large amounts of -digital cash on a personal computer or mobile device is also risky, so -withdrawal limits should suffice to effectively cap the balance users should -be willing to carry. - - -# Question 14 - -What would be the best way to integrate a digital Euro into existing banking and -payment solutions/products (e.g. online and mobile banking, merchant -systems)? What potential challenges need to be considered in the design of the -technology and standards for the digital Euro? - -## Answer - -In addition to development of a regulatory framework for the digital Euro, the -ECB should adopt a solution with an open technical specifications for protocols -and application programming interfaces, as well as a Free Software reference -implementation for the core components. This would facilitate faster -integration into the existing infrastructure of commercial banks and merchants. - -# Question 15 - -What features should the digital Euro have to facilitate cross-currency -payments? - -## Answer - -We do not see an urgent need for cross-currency payments, this creates -mostly economic and political hazards. However, what is important is -that a global standard is created, and that consumers can carry balances -in various currencies in their unified digital wallet. To create such -a global standard, a patent-free Free Software approach is crucial, as -no country should make itself dependent on proprietary software that -is likely subject to foreign influence. When the USA recently sanctioned -Huawei's use of Google Android, only the Free Software components remained -usable for Huawei. Creating a proprietary European standard would thus -fail to satisfy the possibility of global appeal, as countries increasingly -realize that they cannot have their critical infrastructure depend on -proprietary foreign technology. - -Smart contracts for auctions can enable trading of digital Euros for -other currencies or stock. We believe this is one type of smart -contract that should eventually be supported. Depending on the -regulatory environment, the central bank logic may here require -attestations from banks, including possibly foreign banks, which -suggests that developing this capability at a global scale that -satisfies non-domestic regulation will need extensive work that may -not be within the remit of the Central bank and could be performed by -commercial entities. - - -# Question 16 - -Should the use of the digital Euro outside the Euro area be limited and, if so, -how? - -## Answer - -By requiring KYC on anyone receiving digital Euro payments, the use of the -digital Euro for income can easily be restrained to European residents, without -in any way excluding visitors from spending money in Europe as they would have -the opportunity to withdraw (possibly limited amounts of) digital Euros at -ATMs, banks or online. - -# Question 17 - -Which software and hardware solutions (e.g. mobile phones, computers, -smartcards, wearables) could be adapted for a digital Euro? - -## Answer - -An efficient design with a software-only approach is in principle usable -from any networked device. If the core platform is written in C, the code -would be highly efficient and can run on any embedded system. By providing -a Free Software reference implementation, all vendors can easily integrate -support for the digital Euro into their products. - -# Question 18 - -What role can you or your organisation play in facilitating the appropriate -design and uptake of a digital Euro as an effective means of payment? - -## Answer - -Taler Systems SA can provide ECB with a complete implementation of a -payment processor, commercial bank integration, consumer wallet(s), merchant -backends suitable for issuing a digital Euro. GNU Taler has been designed with -appropriate consideration of the regulatory concerns (including privacy and -CFT/AML and fiscal policy) and is expected to scale easily to the required -transaction levels and at minimal cost per transaction. - -The swift introduction of a digital Euro will be crucial to slow the -rise of cryptocurrencies and to protect European banking from the -onslaught of platform-driven digital payment services like GooglePay, -Libra/Diem, AliPay and ApplePay. Digital technology lends itself to -natural monopolies, and the swift introduction of a digital Euro could -be essential to protect Europe's federated banking system. diff --git a/2015-flyer/flyerTalernewversionv3.pdf b/flyers/2015-flyer/flyerTalernewversionv3.pdf Binary files differ. diff --git a/2015-flyer/flyertalerv2.indd b/flyers/2015-flyer/flyertalerv2.indd Binary files differ. diff --git a/2016-flyer/flyerTalerVersion2016_NLv5BD.pdf b/flyers/2016-flyer/flyerTalerVersion2016_NLv5BD.pdf Binary files differ. diff --git a/2017-flyer/flyer.pdf b/flyers/2017-flyer/flyer.pdf Binary files differ. diff --git a/summary/ercim-taler.txt b/papers/2016-ercim-taler/ercim-taler.txt diff --git a/depolymerization/taler.bib b/papers/2016-ercim-taler/taler.bib diff --git a/summary/taler.tex b/papers/2016-ercim-taler/taler.tex diff --git a/depolymerization/ui.bib b/papers/2016-ercim-taler/ui.bib diff --git a/2018-cbdc-response/taler-cbdc.tex b/papers/2018-cbdc-response/taler-cbdc.tex diff --git a/2021-offline/literature.bib b/papers/2021-offline/literature.bib diff --git a/2021-offline/offline.tex b/papers/2021-offline/offline.tex diff --git a/2022-privacy/are-we-the-baddies.jpg b/papers/2022-privacy/are-we-the-baddies.jpg Binary files differ. diff --git a/2022-privacy/bibliography/CNNum-Dossier-Billets_et_jetons_la_nouvelle_concurrence_des_monnaies.pdf b/papers/2022-privacy/bibliography/CNNum-Dossier-Billets_et_jetons_la_nouvelle_concurrence_des_monnaies.pdf Binary files differ. diff --git a/2022-privacy/bibliography/Monnaie Numérique de Banque Centrale.pdf b/papers/2022-privacy/bibliography/Monnaie Numérique de Banque Centrale.pdf Binary files differ. diff --git a/2022-privacy/bibliography/Qu’est-ce qu’une blockchain souveraine -.pdf b/papers/2022-privacy/bibliography/Qu’est-ce qu’une blockchain souveraine -.pdf Binary files differ. diff --git a/2022-privacy/bibliography/bis948.pdf b/papers/2022-privacy/bibliography/bis948.pdf Binary files differ. diff --git a/2022-privacy/bibliography/cwps.pdf b/papers/2022-privacy/bibliography/cwps.pdf Binary files differ. diff --git a/2022-privacy/bibliography/ecb.op286~9d472374ea.en.pdf b/papers/2022-privacy/bibliography/ecb.op286~9d472374ea.en.pdf Binary files differ. diff --git a/2022-privacy/bibliography/fca.pdf b/papers/2022-privacy/bibliography/fca.pdf Binary files differ. diff --git a/2022-privacy/bibliography/lightening.pdf b/papers/2022-privacy/bibliography/lightening.pdf Binary files differ. diff --git a/2022-privacy/bibliography/nzz-egold.docx b/papers/2022-privacy/bibliography/nzz-egold.docx Binary files differ. diff --git a/2022-privacy/bibliography/othp35.pdf b/papers/2022-privacy/bibliography/othp35.pdf Binary files differ. diff --git a/2022-privacy/general_alexander.jpg b/papers/2022-privacy/general_alexander.jpg Binary files differ. diff --git a/2022-privacy/literature.bib b/papers/2022-privacy/literature.bib diff --git a/2022-privacy/photos/Antoine.jpg b/papers/2022-privacy/photos/Antoine.jpg Binary files differ. diff --git a/2022-privacy/photos/Emmanuel_Benoist.jpg b/papers/2022-privacy/photos/Emmanuel_Benoist.jpg Binary files differ. diff --git a/2022-privacy/photos/Grothoff_Christian_03_Small-1600x1200_pixels.jpg b/papers/2022-privacy/photos/Grothoff_Christian_03_Small-1600x1200_pixels.jpg Binary files differ. diff --git a/2022-privacy/photos/Martin.jpeg b/papers/2022-privacy/photos/Martin.jpeg Binary files differ. diff --git a/2022-privacy/photos/florian.jpg b/papers/2022-privacy/photos/florian.jpg Binary files differ. diff --git a/2022-privacy/photos/kesim-photo.jpg b/papers/2022-privacy/photos/kesim-photo.jpg Binary files differ. diff --git a/2022-privacy/privacy-fr.tex b/papers/2022-privacy/privacy-fr.tex diff --git a/2022-privacy/privacy.tex b/papers/2022-privacy/privacy.tex diff --git a/2022-privacy/privacy_size.dia b/papers/2022-privacy/privacy_size.dia Binary files differ. diff --git a/2022-privacy/privacy_size.pdf b/papers/2022-privacy/privacy_size.pdf Binary files differ. diff --git a/2022-privacy/slides.tex b/papers/2022-privacy/slides.tex diff --git a/2022-privacy/suref.docx b/papers/2022-privacy/suref.docx Binary files differ. diff --git a/2022-privacy/suref.tex b/papers/2022-privacy/suref.tex diff --git a/2022-privacy/twitter.jpg b/papers/2022-privacy/twitter.jpg Binary files differ. diff --git a/2022-privacy/twitter2.jpg b/papers/2022-privacy/twitter2.jpg Binary files differ. diff --git a/2022-privacy/wir-sind-die-guten.png b/papers/2022-privacy/wir-sind-die-guten.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.07.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.07.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.35.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.35.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.40.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.40.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.48.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.15.48.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.17.37.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.17.37.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.17.44.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.17.44.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.17.51.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.17.51.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.18.18.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.18.18.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.18.57.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.18.57.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.19.24.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.19.24.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.19.45.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.19.45.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.12.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.12.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.32.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.32.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.45.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.45.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.58.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.20.58.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.22.09.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.22.09.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.22.25.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.22.25.png Binary files differ. diff --git a/depolymerization/Screenshots/ScreenShot-2022-11-22_14.22.44.png b/papers/depolymerization/Screenshots/ScreenShot-2022-11-22_14.22.44.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210438.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210438.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210443.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210443.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210448.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210448.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210513.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210513.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210559.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210559.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210606.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210606.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210626.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210626.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210653.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210653.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210656.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210656.png Binary files differ. diff --git a/depolymerization/Screenshots/Screenshot_20221121-210709.png b/papers/depolymerization/Screenshots/Screenshot_20221121-210709.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.21.17.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.21.17.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.21.38.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.21.38.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.08.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.08.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.13.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.13.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.25.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.25.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.33.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.33.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.46.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.22.46.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.23.18.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.23.18.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.23.35.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.23.35.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.01.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.01.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.23.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.23.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.43.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.43.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.51.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.24.51.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.28.36.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 10.28.36.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 11.18.20.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-08 à 11.18.20.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 13.36.46.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 13.36.46.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.36.32.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.36.32.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.36.38.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.36.38.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.37.10.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.37.10.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.37.23.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.37.23.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.37.29.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-09 à 14.37.29.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 13.36.57.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 13.36.57.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 13.37.05.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 13.37.05.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 14.07.56.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 14.07.56.png Binary files differ. diff --git a/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 14.24.51.png b/papers/depolymerization/Screenshots/browser-wallet/Capture d’écran 2023-06-23 à 14.24.51.png Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-02-20-839_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-02-20-839_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-02-45-266_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-02-45-266_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-03-10-988_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-03-10-988_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-04-22-819_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-04-22-819_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-04-40-561_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-04-40-561_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-05-00-887_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-05-00-887_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-05-20-959_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-05-20-959_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-21-57-650_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-21-57-650_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-22-18-066_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-17-22-18-066_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-18-10-00-090_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-07-18-10-00-090_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-13-34-59-481_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-13-34-59-481_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-13-35-16-698_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-13-35-16-698_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-14-37-39-261_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-14-37-39-261_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-14-38-04-337_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-14-38-04-337_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-14-38-22-402_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-09-14-38-22-402_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-35-26-056_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-35-26-056_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-35-34-228_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-35-34-228_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-35-49-814_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-35-49-814_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-36-07-426_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-36-07-426_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-39-46-671_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-13-39-46-671_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-05-02-729_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-05-02-729_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-05-34-558_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-05-34-558_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-07-27-106_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-07-27-106_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-25-06-902_net.taler.wallet.jpg b/papers/depolymerization/Screenshots/phone_app/Screenshot_2023-06-23-14-25-06-902_net.taler.wallet.jpg Binary files differ. diff --git a/depolymerization/en.tex b/papers/depolymerization/en.tex diff --git a/depolymerization/figures/analysis.tex b/papers/depolymerization/figures/analysis.tex diff --git a/depolymerization/figures/conf_delay.tex b/papers/depolymerization/figures/conf_delay.tex diff --git a/depolymerization/figures/conflict.tex b/papers/depolymerization/figures/conflict.tex diff --git a/depolymerization/figures/depolymerizer_arch.tex b/papers/depolymerization/figures/depolymerizer_arch.tex diff --git a/depolymerization/figures/fork.tex b/papers/depolymerization/figures/fork.tex diff --git a/depolymerization/figures/harmless_reorg.tex b/papers/depolymerization/figures/harmless_reorg.tex diff --git a/depolymerization/figures/settlement_layer.tex b/papers/depolymerization/figures/settlement_layer.tex diff --git a/depolymerization/figures/taler_arch.tex b/papers/depolymerization/figures/taler_arch.tex diff --git a/depolymerization/media/fee.png b/papers/depolymerization/media/fee.png Binary files differ. diff --git a/depolymerization/media/fee_var.png b/papers/depolymerization/media/fee_var.png Binary files differ. diff --git a/depolymerization/media/news0.png b/papers/depolymerization/media/news0.png Binary files differ. diff --git a/depolymerization/media/news1.png b/papers/depolymerization/media/news1.png Binary files differ. diff --git a/depolymerization/media/news2.png b/papers/depolymerization/media/news2.png Binary files differ. diff --git a/depolymerization/media/taler.png b/papers/depolymerization/media/taler.png Binary files differ. diff --git a/summary/taler.bib b/papers/depolymerization/taler.bib diff --git a/summary/ui.bib b/papers/depolymerization/ui.bib diff --git a/esorics2022/definitions.tex b/papers/esorics2022/definitions.tex diff --git a/esorics2022/esorics2022.pdf b/papers/esorics2022/esorics2022.pdf Binary files differ. diff --git a/esorics2022/esorics2022.tex b/papers/esorics2022/esorics2022.tex diff --git a/esorics2022/images/bfh.png b/papers/esorics2022/images/bfh.png Binary files differ. diff --git a/esorics2022/images/esorics2022.png b/papers/esorics2022/images/esorics2022.png Binary files differ. diff --git a/esorics2022/images/fraunhofer.png b/papers/esorics2022/images/fraunhofer.png Binary files differ. diff --git a/esorics2022/images/fub.pdf b/papers/esorics2022/images/fub.pdf Binary files differ. diff --git a/esorics2022/images/taler-logo-2020.jpg b/papers/esorics2022/images/taler-logo-2020.jpg Binary files differ. diff --git a/esorics2022/setup.tex b/papers/esorics2022/setup.tex diff --git a/2022-nullcon/adversary.odg b/presentations/2022-nullcon-anastasis/adversary.odg Binary files differ. diff --git a/2022-nullcon/adversary.pdf b/presentations/2022-nullcon-anastasis/adversary.pdf Binary files differ. diff --git a/2022-nullcon/anastasis-presentation.pptx b/presentations/2022-nullcon-anastasis/anastasis-presentation.pptx Binary files differ. diff --git a/2022-nullcon/ashoka.png b/presentations/2022-nullcon-anastasis/ashoka.png Binary files differ. diff --git a/2022-nullcon/backup.mp4 b/presentations/2022-nullcon-anastasis/backup.mp4 Binary files differ. diff --git a/2022-nullcon/bandiera_stelle.png b/presentations/2022-nullcon-anastasis/bandiera_stelle.png Binary files differ. diff --git a/2022-nullcon/bfh.png b/presentations/2022-nullcon-anastasis/bfh.png Binary files differ. diff --git a/2022-nullcon/bootcamp.pdf b/presentations/2022-nullcon-anastasis/bootcamp.pdf Binary files differ. diff --git a/2022-nullcon/bootcamp.tex b/presentations/2022-nullcon-anastasis/bootcamp.tex diff --git a/2022-nullcon/compare.pdf b/presentations/2022-nullcon-anastasis/compare.pdf Binary files differ. diff --git a/2022-nullcon/compare.tex b/presentations/2022-nullcon-anastasis/compare.tex diff --git a/2022-nullcon/gantt.tex b/presentations/2022-nullcon-anastasis/gantt.tex diff --git a/2022-nullcon/identity.odg b/presentations/2022-nullcon-anastasis/identity.odg Binary files differ. diff --git a/2022-nullcon/identity.pdf b/presentations/2022-nullcon-anastasis/identity.pdf Binary files differ. diff --git a/2022-nullcon/logo.png b/presentations/2022-nullcon-anastasis/logo.png Binary files differ. diff --git a/2022-nullcon/motivation.pdf b/presentations/2022-nullcon-anastasis/motivation.pdf Binary files differ. diff --git a/2022-nullcon/mvp.pdf b/presentations/2022-nullcon-anastasis/mvp.pdf Binary files differ. diff --git a/2022-nullcon/mvp.tex b/presentations/2022-nullcon-anastasis/mvp.tex diff --git a/2022-nullcon/ngi_ledger.pdf b/presentations/2022-nullcon-anastasis/ngi_ledger.pdf Binary files differ. diff --git a/2022-nullcon/nullcon.pdf b/presentations/2022-nullcon-anastasis/nullcon.pdf Binary files differ. diff --git a/2022-nullcon/nullcon.tex b/presentations/2022-nullcon-anastasis/nullcon.tex diff --git a/2022-nullcon/overview.odg b/presentations/2022-nullcon-anastasis/overview.odg Binary files differ. diff --git a/2022-nullcon/overview.pdf b/presentations/2022-nullcon-anastasis/overview.pdf Binary files differ. diff --git a/2022-nullcon/polynominal.png b/presentations/2022-nullcon-anastasis/polynominal.png Binary files differ. diff --git a/2022-nullcon/recovery.mp4 b/presentations/2022-nullcon-anastasis/recovery.mp4 Binary files differ. diff --git a/2022-nullcon/roadmap.pdf b/presentations/2022-nullcon-anastasis/roadmap.pdf Binary files differ. diff --git a/2022-nullcon/roadmap.tex b/presentations/2022-nullcon-anastasis/roadmap.tex diff --git a/2022-nullcon/simplifications.odg b/presentations/2022-nullcon-anastasis/simplifications.odg Binary files differ. diff --git a/2022-nullcon/simplifications.pdf b/presentations/2022-nullcon-anastasis/simplifications.pdf Binary files differ. diff --git a/2022-nullcon/step1.odg b/presentations/2022-nullcon-anastasis/step1.odg Binary files differ. diff --git a/2022-nullcon/step1.pdf b/presentations/2022-nullcon-anastasis/step1.pdf Binary files differ. diff --git a/2022-nullcon/step11.odg b/presentations/2022-nullcon-anastasis/step11.odg Binary files differ. diff --git a/2022-nullcon/step11.pdf b/presentations/2022-nullcon-anastasis/step11.pdf Binary files differ. diff --git a/2022-nullcon/step12.odg b/presentations/2022-nullcon-anastasis/step12.odg Binary files differ. diff --git a/2022-nullcon/step12.pdf b/presentations/2022-nullcon-anastasis/step12.pdf Binary files differ. diff --git a/2022-nullcon/step13.odg b/presentations/2022-nullcon-anastasis/step13.odg Binary files differ. diff --git a/2022-nullcon/step13.pdf b/presentations/2022-nullcon-anastasis/step13.pdf Binary files differ. diff --git a/2022-nullcon/step14.odg b/presentations/2022-nullcon-anastasis/step14.odg Binary files differ. diff --git a/2022-nullcon/step14.pdf b/presentations/2022-nullcon-anastasis/step14.pdf Binary files differ. diff --git a/2022-nullcon/step15.odg b/presentations/2022-nullcon-anastasis/step15.odg Binary files differ. diff --git a/2022-nullcon/step15.pdf b/presentations/2022-nullcon-anastasis/step15.pdf Binary files differ. diff --git a/2022-nullcon/step16.odg b/presentations/2022-nullcon-anastasis/step16.odg Binary files differ. diff --git a/2022-nullcon/step16.pdf b/presentations/2022-nullcon-anastasis/step16.pdf Binary files differ. diff --git a/2022-nullcon/step2.odg b/presentations/2022-nullcon-anastasis/step2.odg Binary files differ. diff --git a/2022-nullcon/step2.pdf b/presentations/2022-nullcon-anastasis/step2.pdf Binary files differ. diff --git a/2022-nullcon/step3.odg b/presentations/2022-nullcon-anastasis/step3.odg Binary files differ. diff --git a/2022-nullcon/step3.pdf b/presentations/2022-nullcon-anastasis/step3.pdf Binary files differ. diff --git a/2022-nullcon/step4.odg b/presentations/2022-nullcon-anastasis/step4.odg Binary files differ. diff --git a/2022-nullcon/step4.pdf b/presentations/2022-nullcon-anastasis/step4.pdf Binary files differ. diff --git a/2022-nullcon/step5.odg b/presentations/2022-nullcon-anastasis/step5.odg Binary files differ. diff --git a/2022-nullcon/step5.pdf b/presentations/2022-nullcon-anastasis/step5.pdf Binary files differ. diff --git a/2022-nullcon/step6.odg b/presentations/2022-nullcon-anastasis/step6.odg Binary files differ. diff --git a/2022-nullcon/step6.pdf b/presentations/2022-nullcon-anastasis/step6.pdf Binary files differ. diff --git a/2022-nullcon/step7.odg b/presentations/2022-nullcon-anastasis/step7.odg Binary files differ. diff --git a/2022-nullcon/step7.pdf b/presentations/2022-nullcon-anastasis/step7.pdf Binary files differ. diff --git a/2022-nullcon/step8.odg b/presentations/2022-nullcon-anastasis/step8.odg Binary files differ. diff --git a/2022-nullcon/step8.pdf b/presentations/2022-nullcon-anastasis/step8.pdf Binary files differ. diff --git a/2022-nullcon/technically.pdf b/presentations/2022-nullcon-anastasis/technically.pdf Binary files differ. diff --git a/2022-nullcon/what.pdf b/presentations/2022-nullcon-anastasis/what.pdf Binary files differ. diff --git a/2022-nullcon/white.png b/presentations/2022-nullcon-anastasis/white.png Binary files differ. diff --git a/2023-fsf/README b/presentations/2023-fsf/README diff --git a/2023-fsf/fsf2023.pdf b/presentations/2023-fsf/fsf2023.pdf Binary files differ. diff --git a/2023-fsf/fsf2023/219a06993cd03ea80f01e4822209c9cf.jpg b/presentations/2023-fsf/fsf2023/219a06993cd03ea80f01e4822209c9cf.jpg Binary files differ. diff --git a/2023-fsf/fsf2023/2809854ae3b7f9430e9d4ef27eefb8d8.png b/presentations/2023-fsf/fsf2023/2809854ae3b7f9430e9d4ef27eefb8d8.png Binary files differ. diff --git a/2023-fsf/fsf2023/69ee5e9ebdcfc613ba383d0caa4c094b.png b/presentations/2023-fsf/fsf2023/69ee5e9ebdcfc613ba383d0caa4c094b.png Binary files differ. diff --git a/2023-fsf/fsf2023/e2bf6339a2c83c27dea5d4b6834d5bfe.png b/presentations/2023-fsf/fsf2023/e2bf6339a2c83c27dea5d4b6834d5bfe.png Binary files differ. diff --git a/2023-fsf/lib/fonts/asul/asul-bold.woff b/presentations/2023-fsf/lib/fonts/asul/asul-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/asul/asul-regular.woff b/presentations/2023-fsf/lib/fonts/asul/asul-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/asul/asul.css b/presentations/2023-fsf/lib/fonts/asul/asul.css diff --git a/2023-fsf/lib/fonts/cabinsketch/cabinsketch-bold.woff b/presentations/2023-fsf/lib/fonts/cabinsketch/cabinsketch-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/cabinsketch/cabinsketch-regular.woff b/presentations/2023-fsf/lib/fonts/cabinsketch/cabinsketch-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/cabinsketch/cabinsketch.css b/presentations/2023-fsf/lib/fonts/cabinsketch/cabinsketch.css diff --git a/2023-fsf/lib/fonts/josefinsans/josefinsans-bold.woff b/presentations/2023-fsf/lib/fonts/josefinsans/josefinsans-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/josefinsans/josefinsans-bolditalic.woff b/presentations/2023-fsf/lib/fonts/josefinsans/josefinsans-bolditalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/josefinsans/josefinsans-italic.woff b/presentations/2023-fsf/lib/fonts/josefinsans/josefinsans-italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/josefinsans/josefinsans-regular.woff b/presentations/2023-fsf/lib/fonts/josefinsans/josefinsans-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/josefinsans/josefinsans.css b/presentations/2023-fsf/lib/fonts/josefinsans/josefinsans.css diff --git a/2023-fsf/lib/fonts/katex/KaTeX_AMS-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_AMS-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Caligraphic-Bold.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Caligraphic-Bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Caligraphic-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Caligraphic-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Fraktur-Bold.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Fraktur-Bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Fraktur-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Fraktur-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Main-Bold.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Main-Bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Main-BoldItalic.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Main-BoldItalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Main-Italic.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Main-Italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Main-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Main-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Math-BoldItalic.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Math-BoldItalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Math-Italic.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Math-Italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Math-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Math-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_SansSerif-Bold.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_SansSerif-Bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_SansSerif-Italic.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_SansSerif-Italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_SansSerif-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_SansSerif-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Script-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Script-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Size1-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Size1-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Size2-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Size2-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Size3-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Size3-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Size4-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Size4-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/katex/KaTeX_Typewriter-Regular.woff b/presentations/2023-fsf/lib/fonts/katex/KaTeX_Typewriter-Regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/lato/lato-bold.woff b/presentations/2023-fsf/lib/fonts/lato/lato-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/lato/lato-bolditalic.woff b/presentations/2023-fsf/lib/fonts/lato/lato-bolditalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/lato/lato-italic.woff b/presentations/2023-fsf/lib/fonts/lato/lato-italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/lato/lato-regular.woff b/presentations/2023-fsf/lib/fonts/lato/lato-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/lato/lato.css b/presentations/2023-fsf/lib/fonts/lato/lato.css diff --git a/2023-fsf/lib/fonts/league/league_gothic.css b/presentations/2023-fsf/lib/fonts/league/league_gothic.css diff --git a/2023-fsf/lib/fonts/league/league_gothic.woff b/presentations/2023-fsf/lib/fonts/league/league_gothic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/league/league_gothic_license b/presentations/2023-fsf/lib/fonts/league/league_gothic_license diff --git a/2023-fsf/lib/fonts/merriweathersans/merriweathersans-bold.woff b/presentations/2023-fsf/lib/fonts/merriweathersans/merriweathersans-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/merriweathersans/merriweathersans-regular.woff b/presentations/2023-fsf/lib/fonts/merriweathersans/merriweathersans-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/merriweathersans/merriweathersans.css b/presentations/2023-fsf/lib/fonts/merriweathersans/merriweathersans.css diff --git a/2023-fsf/lib/fonts/montserrat/montserrat-bold.woff b/presentations/2023-fsf/lib/fonts/montserrat/montserrat-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/montserrat/montserrat-regular.woff b/presentations/2023-fsf/lib/fonts/montserrat/montserrat-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/montserrat/montserrat.css b/presentations/2023-fsf/lib/fonts/montserrat/montserrat.css diff --git a/2023-fsf/lib/fonts/newscycle/newscycle-bold.woff b/presentations/2023-fsf/lib/fonts/newscycle/newscycle-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/newscycle/newscycle-regular.woff b/presentations/2023-fsf/lib/fonts/newscycle/newscycle-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/newscycle/newscycle.css b/presentations/2023-fsf/lib/fonts/newscycle/newscycle.css diff --git a/2023-fsf/lib/fonts/opensans/opensans-bold.woff b/presentations/2023-fsf/lib/fonts/opensans/opensans-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/opensans/opensans-bolditalic.woff b/presentations/2023-fsf/lib/fonts/opensans/opensans-bolditalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/opensans/opensans-italic.woff b/presentations/2023-fsf/lib/fonts/opensans/opensans-italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/opensans/opensans-regular.woff b/presentations/2023-fsf/lib/fonts/opensans/opensans-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/opensans/opensans.css b/presentations/2023-fsf/lib/fonts/opensans/opensans.css diff --git a/2023-fsf/lib/fonts/overpass/overpass-bold.woff b/presentations/2023-fsf/lib/fonts/overpass/overpass-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass/overpass-light.woff b/presentations/2023-fsf/lib/fonts/overpass/overpass-light.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass/overpass-regular.woff b/presentations/2023-fsf/lib/fonts/overpass/overpass-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass/overpass.css b/presentations/2023-fsf/lib/fonts/overpass/overpass.css diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-bold.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-bolditalic.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-bolditalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-extralight.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-extralight.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-extralightitalic.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-extralightitalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-italic.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-italic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-light.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-light.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-lightitalic.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-lightitalic.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2-regular.woff b/presentations/2023-fsf/lib/fonts/overpass2/overpass2-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/overpass2/overpass2.css b/presentations/2023-fsf/lib/fonts/overpass2/overpass2.css diff --git a/2023-fsf/lib/fonts/oxygen/oxygen-bold.woff b/presentations/2023-fsf/lib/fonts/oxygen/oxygen-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/oxygen/oxygen-regular.woff b/presentations/2023-fsf/lib/fonts/oxygen/oxygen-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/oxygen/oxygen.css b/presentations/2023-fsf/lib/fonts/oxygen/oxygen.css diff --git a/2023-fsf/lib/fonts/quicksand/quicksand-bold.woff b/presentations/2023-fsf/lib/fonts/quicksand/quicksand-bold.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/quicksand/quicksand-regular.woff b/presentations/2023-fsf/lib/fonts/quicksand/quicksand-regular.woff Binary files differ. diff --git a/2023-fsf/lib/fonts/quicksand/quicksand.css b/presentations/2023-fsf/lib/fonts/quicksand/quicksand.css diff --git a/2023-fsf/lib/offline-v1.css b/presentations/2023-fsf/lib/offline-v1.css diff --git a/2023-fsf/lib/offline-v2.css b/presentations/2023-fsf/lib/offline-v2.css diff --git a/2023-fsf/lib/offline.js b/presentations/2023-fsf/lib/offline.js diff --git a/2023-fsf/lib/reveal-plugins.js b/presentations/2023-fsf/lib/reveal-plugins.js diff --git a/2023-fsf/lib/reveal.css b/presentations/2023-fsf/lib/reveal.css diff --git a/2023-fsf/lib/reveal.js b/presentations/2023-fsf/lib/reveal.js diff --git a/2023-fsf/operations.png b/presentations/2023-fsf/operations.png Binary files differ. diff --git a/2023-fsf/shirt.json b/presentations/2023-fsf/shirt.json diff --git a/2023-fsf/slides.html b/presentations/2023-fsf/slides.html diff --git a/2023-fsf/walkthrough.sh b/presentations/2023-fsf/walkthrough.sh diff --git a/2023-fsf/wicmp.jpg b/presentations/2023-fsf/wicmp.jpg Binary files differ. diff --git a/2016-logan/logan-rollup.pdf b/rollups/2016-logan/logan-rollup.pdf Binary files differ. diff --git a/sa/sa.tex b/sa/sa.tex @@ -1,1225 +0,0 @@ -\documentclass{article} % {article} % {acmart} - -\usepackage{url} -\usepackage{eurosym} -\usepackage[T1]{fontenc} -% \usepackage{lmodern} -% \usepackage{verbatim} -\usepackage[utf8]{inputenc} -\usepackage{graphicx} -\usepackage[a4paper,left=25mm,right=25mm, top=25mm, bottom=25mm]{geometry} -\usepackage{enumerate} - -\begin{document} -\pagestyle{plain} -% \thispagestyle{empty} - -\newcommand\logo{\includegraphics[width=0.07\textwidth]{../presentations/comprehensive/taler-big-accent.pdf}} - -\begin{center} -{\huge Taler as the Foundation for a \\ Centrally Banked Digital Currency} - -\medskip - -\end{center} - -\def\red{} % FIXME - -% TODO(Florian): General comments: -% Terminology-wise, should we use coins and denominations? Is it too low-level? - -\begin{abstract} - Taler is a cryptographic protocol with a Free Software reference - implementation for a value-based transaction system. Taler payments are - executed in an existing regulated fiat currency, hence Taler requires - integration with some register-based accounting system, such as traditional - bank accounts. Taler aggregates many small transactions from different - customers to the same merchant, thereby reducing the transaction cost in the - register-based accounting system. Taler provides privacy for consumers - and accountability for businesses receiving payments. -\end{abstract} - - -\section{Introduction} - -Taler Systems SA is developing an online payment system called Taler, that -broadly fits the requirements of SARB's CBDC project. The major parts -of the system have already been built. Taler's unique focus is -on regulatory compliance, efficiency and data minimization. Cryptography is -employed for security. While Taler includes privacy features, it can still -guarantee that cash flows to merchants/retailers are transparent for anti-% -money-laundering (AML) and know-your-customer (KYC) auditing requirements. -Transactions with Taler execute in one network round-trip time. Taler is -economically viable for micro-payments (payments of 1 cent) as its design -minimizes requirements in terms of CPU time (typically less than 1 M cycles -per transaction), bandwidth (typically 1-10 KB/transaction), and storage -(again a few KB/transaction, with the ability to delete old data once legal -data retention periods have expired). - -The USPs of Taler are: - -\begin{itemize} -\item All operations are cryptographically secured, with mathematically sound - proofs for courts and auditors -\item Customer payments are privacy-preserving, like cash -\item Merchants are identifiable in each payment they receive -\item Payments are in existing currencies -\item Payment fraud is eliminated, short of catastrophic failure in cryptographic primitives -\item Linear scalability ensures Taler can handle transaction volumes seen in global payment systems today -\item Suitable for micro-payments due to very low transaction costs -\item Ease of use (one-click, instant, no authentication during payment, again like cash) -\item The patent-free, open standard protocol and the free reference implementation provide - long-term sustainability and technological independence from foreign providers -\item Can be used for smart contracts -\end{itemize} - -The Taler architecture includes a register-based system of bank accounts -for customers and merchants with an escrow-account for the exchange. The -exchange signs electronic coins into existence, customers use them to sign -contracts and merchants deposit them in return for a credit to the register. -The exchange collects cryptographic proofs that it operates correctly, which -are then checked by an auditor (auditor not shown): - - -\begin{center} -\includegraphics[width=\textwidth]{../presentations/comprehensive/operations.png} -\end{center} - -Thus, the following components form the core of the system: - -\begin{enumerate} - \item An \emph{Electronic wallet} software stores cryptographic - tokens of value (called digital coins), implemented via blind - signatures. Wallets are typically managed by the end user; a - \emph{wallet provider} can manage storage of cryptographic - material for the user, providing backup, synchronization and - recovery. - - \item The \emph{Exchange} issues digital coins to wallets, after - receiving fiat money in an escrow account, or based on a - central bank creating the digital coins as a central bank liability. - The authorized electronic - wallet is identified using an ephemeral \emph{reserve public key} - encoded in the wire payment instructions. As blind signatures are - used, the exchange knows that it issued coins of a certain - monetary value, but not to which wallet. Digital coins are always - denominated in a fiat currency (e.g. Euro). - - \item The \emph{Merchant} proposes contracts to customers and - receives payment in the form of contracts signed using digital - coins. The merchant must then immediately clear these - \emph{deposit permissions} with the exchange. The exchange checks - against double-spending, and if everything is in order provides - the merchant with an instant \emph{deposit confirmation}. After - possibly aggregating many micro-transactions, the exchange sends - money from the escrow account to the merchant's bank account. - - \item \emph{Auditors} are entities that certify which Exchanges can - be trusted as legitimate. Auditors must be configured in the - electronic wallets and the merchants' infrastructure before these - users accept digital coins of the respective exchanges. Auditors - include a software component used to conduct ongoing automated - checks of the Exchanges' wire transaction history to detect if - they deviate from their expected operation. For this, auditors - must be provided a replica of the exchange's database and read-only - access to the escrow account. -\end{enumerate} - -The implementation of all core components is licensed as free and open -source software (FOSS). - -Our vision is close to the electronic cash system ``DigiCash'' proposed by -David Chaum in the 1990s, except that Taler's design and implementation -supports key features such as giving change, providing refunds, securely -handling aborts and various other practical issues previous technical -solutions lacked. - -In summary, the overall system roughly operates as follows: The Taler wallet is filled via -wire-transfer to the Taler exchange's escrow account, where the subject -identifies the Taler wallet eligible to withdraw the CBDC. Regulators can -limit the amount an entity is entitled to exchange from rand into CBDC, like -ATM withdrawal limits. When withdrawing electronic coins, they are blindly signed by the -Taler exchange and stored in the consumer's wallet, which is value-based. The -consumer can then spend its coins at merchants using cryptographic signatures -over electronic contracts. Merchants must immediately deposit the coins at -the exchange, which performs an online check for double-spending. The -exchange will then credit the merchant's register-based accounts using -aggregated wire-transfers. - - -\section{CBDC principles and attributes} \label{section:cbdc:requirements} - -This section elaborates on how the open source payment system GNU Taler fits -into the requirements of a Centrally Banked Digital Currencency (CBDC) as set -forth in the SARB tender in Section~3. - -\begin{enumerate}[i] -\subsection{Policy} -\item -{\bf CBDC will be issued as legal tender by the SARB only.} - The Taler protocol requires an auditor to certify that an - electronic money issuer is allowed to issue coins of a particular - denomination. Usually the auditor would be tied to the - regulation of the respective central bank. Thus, if SARB - only qualifies itself to issue CBDC for rand, then only SARB - can issue Taler CBDC for rand. The digital coins issued by - SARB would constitute themselves a fiat currency, i.e. rand. -\item -{\bf A possible alternative scenario is for the SARB to back the CBDC and to set -regulatory standards and interoperability requirements, but with commercial banks -acting as issuing authorities under the regulatory oversight of the SARB.} - The Taler system also allows this. In this case, it is expected that - the commercial banks would have to provide escrow accounts as backing for - electronic coins they issued (and did not yet redeem). -\item -{\bf The supply of CBDC must be limited as determined by applicable monetary policy.} - CBDC is either supplied by a central bank creating them, or by commercial - banks moving existing funds into an escrow account when creating electronic - coins. In the first case SARB fully controls the issuance of CBDC which will - increase M0/M1 unless offset by reducing cash. In the latter case, the - introduction of Taler does not impact monetary policy, - except that it is probably easier for foreigners to obtain and hold electronic - coins (compared to obtaining cash or rand-denominated bank accounts). -\item -{\bf It must be possible to issue and distribute CBDC to commercial banks only, or to -commercial banks as well as licensed service providers. Such licensed service -providers could be instrumental in broadening the base for financial inclusion and -would be authorised and licensed upon meeting a defined set of regulatory criteria.} - This requirement is satisfied through the Auditor component of Taler. - The Auditor for Taler would be controlled by the SARB, and provide licenses - (in the form of a digital certificate) to commercial banks and service providers - that shall be allowed to issue and distribute CBDC. -\item -{\bf CBDC must be complementary to cash and is not intended to replace cash. However, -it is expected that CBDC would influence the movement of cash or even displace -cash to some extent over time.} - Recent developments in California\footnote{\url{https://on.mktw.net/2V3yxOw}} suggest that regulation needs to be - in place to force businesses to accept cash, as some businesses may - like to discriminate against consumers that use cash. Nevertheless, this - is a regulatory issue and unrelated to a particular choice of CBDC. -\item -{\bf CBDC must be a liability on the SARB balance sheet.} - Taler is designed to work for all currencies for which - a register-based accounting system exists and are expected - to be denominated in the currency of the underlying register. - Taler coins in circulation would thus be backed by an - escrow account at a commercial bank, or when created by the SARB - be booked as a liability on the SARB balance sheet in anticipation - of future deposits of the electronic coins --- in the same way as cash. -\item -{\bf CBDC must be issued at one-to-one parity with the rand.} - Taler is designed to map 1:1 to any existing fiat currency. - Taler coins are expected to map 1:1 to the fiat currency and - show up in the respective user-interface in the respective - fiat denomination. -\item -{\bf Transacting with CBDC must be free to the consumer, or at a very low cost - significantly below current payment channel fees.} - We estimate - that the actual costs per transaction at scale (excluding migration cost) - are generally less than 0.1 cent/transaction. It is conceivable that the - SARB might absorb the entire (low) cost. The protocol also includes provisions - for hiding the cost from consumers by charging fees primarily to the merchants. -\item -{\bf CBDC must offer value or an incentive to promote its use, including a lower cost to - the industry compared with the cost of cash.} - As stated earlier, Taler comes with a range of USPs, including lower costs, - improved security, sustainability, convenience, competition, privacy and - it can be used for smart contracts. -\item -{\bf CBDC must be ubiquitous and accepted as a means of payment by all sizes of -business and by the government.} - Taler is designed to handle micropayments as well as arbitrarily large - payments between consumers, companies and authorities. -\item -{\bf CBDC must not introduce the risk of destabilising the financial sector and -mechanisms must be incorporated to give effect to policy decisions regarding its -supply and movement. Specifically, it must be possible to manage risks such as value -migrating rapidly from commercial bank money to CBDC, thereby skewing the ability -of commercial banks to provide credit.} - Regulation may impose limits on withdrawals and maximum amounts transacted. - This should mitigate the risk from bank runs (movement) that might be triggered - independent of the introduction of a CDBC. - As Taler does not introduce a new currency, - there is no risk of competing with existing currencies. However, Taler may - provide competition for profitable payment services offered by commercial banks, - possibly reducing the risk spread in the business activities of commercial banks. - Taler CBDC would be created as part of M1 by the SARB, thus it does not - impact SARB's ability to make policy decisions with regard to supply. -\item -{\bf CBDC must provide the opportunity for stakeholders to innovate in terms of payment - products, but must not be seen to disintermediate commercial banks.} - The Taler system is open to handle this in different ways. The CBDC could be - issued directly by SARB or via the commercial banks. The greater the role of - the commercial banks the higher the costs they charge for their services (see - requirement viii). -\item -{\bf CBDC must be usable alongside the rand in the member states of the Common -Monetary Area (CMA).} - Taler comes with a Free and Open Source reference implementation and is not - encumbered by patents. Taler's openness should thus enable new services - to be developed with a minimal barrier to entry into the market. - By design, Taler does not disintermediate as every Taler payment must go - into a (commercial) bank account. In other words, Taler coins can only - be spent once, the system does not allow for transitivity. - - In the case of a central bank operating the system, the involvement of a - commercial bank can be avoided in cases where wallet-holders have undergone - KYC checks outside of the scope of creating a traditional bank account. -\item -{\bf Consumers must be able to own and transact in CBDC without the need for a bank - account.} - Taler can enable distribution of funds (i.e. from social security) directly to - wallets. Thus, citizens having a Taler wallet could be given remittances without - the need for a bank account. However, merchants must have a register-based - bank account or perform KYC checks with the exchange operator to receive payments. -\item -{\bf Consumers and businesses must be provided with the channels to obtain or return - CBDC in exchange for cash and commercial bank money.} - With Taler, every transaction must always specify the bank account - details of the receiving party. We note that for efficiency, the - wire transfer to the business are typically performed in aggregate - to minimize the cost created by the traditional register-based wire transfer. - Consumers that do have a bank account can ask their wallet to transfer the - CBDC back into their bank account. -\item -{\bf CBDC must be freely and seamlessly interchangeable between an account-based -store of value and a tokenised store of value. CBDC is expected to be interest-free -or attract zero interest. This must, however, be a variable attribute to cater for different -policy positions in future.} - Taler could theoretically support interest on CBDC by varying the exchange - rate between CBDC and rand. Taler can also theoretically support {\em negative} - interest on coins held long-term in wallets. However, these are optional - features and in general we fully agree that the most usable and practical design - is to fix the exchange rate between CBDC and rand and to not impose significant - fees on holding coins. - -\subsection{Branding} -\item - {\bf CBDC must be branded and its ownership by the SARB as issuer must be evident.} - As the CBDC implemented by Taler can be denominated in rand and a - SARB-branded wallet software can be deployed, ownership by SARB would be - evident. -\item -{\bf CBDC must be unique in its design and its SARB ownership must be clear and - evident.} - We can create a SARB-branded user-interface for Taler and SARB would - be able to register and own trademarks for the respective branding. - The Taler {\em protocol} itself is a public specification - and our reference implementation is a global commons (Free Software), - which would allow other - countries to adopt the same technology stack (with other branding). That said, - SARB is free to adapt the technology to its needs within the limits - of the licensing agreement with Taler Systems SA and/or the GNU Affero - General Public License. -\item -{\bf CBDC must be trusted and acceptable to all members of the public as legal tender, - a safe store of value, and as secure means to transfer value during transacting.} - The SARB would primarily hold the escrow account (or liability). It could also either - (1) run the operations of the exchange and guarantee the exchange of CBDC - in rand directly, or (2) else audit privately operated exchanges - similar to its regulatory oversight of conventional banks and payment processors. - This should assure the public about the safety of the CBDC. - We are not familiar with legal tender regulation in SA to determine what else would - be required to make it legal tender. - -\subsection{Transactional usage} -\item -{\bf It must enable immediate person-to-person transfer of value without clearing and - settlement in today’s terms.} - Online person-to-person transfers are possible, but involve at least the - exchange as a service provider to protect against double spending. In this - case, the receiver also must have an account that satisfies KYC requirements - at the exchange to prevent money laundering. Taler enables also offline - person-to-person transfers without the involvement of third parties only by - sharing access to a selected amount of funds among with the receiver(s). The - participants in such an offline person-to-person transfer must trust each - other to behave honestly. Basically, such transfers are not transactions in - that the sender can spend the money elsewhere at any time. -\item -{\bf It must be possible to set limits for CBDC transaction values and to implement - graduated regulation depending on transaction value.} - Taler can impose withdrawal limits for consumers, and merchants may be required to - limit the value of individual transactions or to provide additional identification - of customers based on the specific product being sold or the value of the transaction. - Taler provides an audit trail for the state to ensure merchants comply with - applicable regulation on transactions. -\item -{\bf CBDC payment products should enable transaction notifications to consumers.} - Customers and merchants always have access to their full account - histories and their balances on their local computer or mobile device. - Thus transaction notfications are easily available. -\item -{\bf CBDC must be accepted and usable at all levels of transactions, in the same way - cash is accepted and usable at all levels of transactions.} - Taler is in principle suitable for microtransactions as well as very large - transactions, however the system assumes that the consumer is under control - of their computing resources. Given the state of security on mobile phones, - it may thus not be generally advisable to carry very large balances on a - mobile phone. We expect Taler to be primarily used for liquidity, and not - as a store of value. However, it is in principle possible to produce hardware - security modules to pay larger amounts with adequate security. -\item -{\bf CBDC must provide real-time, final and irrefutable transfer of value.} -Taler payments typically clear in one network round-trip time, concluding with -an electronically signed statement providing irrefutable proof of the -transfer of value. -\item -{\bf It must be able to operate on a peer-to-peer (face-to-face) basis as well as online. In -the absence of connectivity/Internet/data, consumers must be able to transfer value -to each other or to a business. This implies that mechanisms will be required to -enforce offline transaction limits, prevent double-spending, and reconcile transaction -data once online.} - For Taler transactions, either the payer or the merchant must be online and - able to communicate with the exchange. Otherwise the merchant cannot be sure - that the payer did not double-spend and risks being defrauded. We believe - that this is an inherent problem for any system that runs on untrusted - hardware, and only closed, ``unhackable'' hardware security modules could - theoretically avoid this limitation. While after-the-fact double spending - would be detectable and traceable to the misbehaving individual, allowing - offline transactions would create systemic risks in any CBDC without special - hardware security modules. -\item - {\bf The government must be able to make payments in CBDC.} - This is possible with Taler. -\item -{\bf Interoperability principles must enable CBDC to be used at all levels throughout the -payment system.} - With proper system integration, wire transfers, debit and credit cards or even - NFC-enabled ATMs and e-mails could all be used to fund the CBDC wallet. Our specifications - are public, thus broad integration is a question of regulation and/or - incentives. -\item -{\bf The CBDC value transfer mechanisms must prevent double-spending.} - The Taler exchange performs online double-spending detection by comparing against - known coins when processing deposit requests. -\subsection{Auditability and traceability} -\item -{\bf CBDC must be traceable.} - Taler is designed for payers to remain anonymous when buying goods, unless regulation - requires disclosure (i.e. for particular sensitive purchases). - However, the merchant is never anonymous. - Taler is thus {\em untraceable} in that the system cannot necessarily - identify the buyer. However, Taler does provide for income - transparency. We believe this is critical to avoid 1984-like - totalitarian control over society while ensuring compliance with - reasonable KYC and AML regulation. -\item -{\bf CBDC must be auditable in terms of proof of issuance and ownership.} - When Taler electronic coins are created, the issuer electronically - signs the public key of the coin, thus providing proof of issuance. - The private key of the coin is only known to the owner, never - disclosed (not even upon payment) and is used as proof of ownership. - -\item -{\bf Auditability of transactions should be parameterised in order to determine the balance - between anonymity of the transacting parties and traceability of funds transfers.} - Taler generally is setup to protect the privacy of consumers (who spend money) - and to provide full accountability for merchants (who receive money). Consumers - of course still have to authenticate when withdrawing funds. For particular - transactions (such as licensed sale of weapons, drugs, chemicals or high-value goods) merchants may - be required by law to identify the buyer (and possibly perform additional checks). - Taler does not assist merchants with this per-se, but by providing an electronic trail - from the Taler transaction to the business contract of the merchant, Taler makes it - easy for law enforcement to verify that merchants have complied with applicable regulation - on identifying customers for critical transactions. -\item -{\bf It must be possible to issue a consumer with a ‘proof of payment’ from transaction - audit trails.} - Every Taler transaction concludes with the consumer having a proof of - payment (including details of the contract that was paid for). -\item -{\bf It must be possible to recreate a consumer’s ‘electronic vault’ or ‘e-wallet’ in the case - of loss caused by technology failure.} - We will provide an optional electronic backup service for - consumer's electronic wallets which uses secret sharing for - key escrow (if desired). This electronic vault will also - be used to support cross-device synchronization. - -\subsection{Security} -\item -{\bf CBDC must be issued using highly secure and trusted modern cryptographic - mechanisms.} -Taler is only using modern and widely trusted cryptography (RSA, SHA-512, EdDSA/Curve25519). -\item -{\bf CBDC must be generated/created during its issuance as a secure discreet offline -activity and not as a mining operation such as those deployed for private virtual -currencies.} -Taler does not use mining or any other forms of proof-of-work -or proof-of-stake operations. However, the Taler coins are -created using online signatures when customers withdraw funds -from their accounts. The online signatures could be performed -using hardware security modules to provide additional protections -for the private keys used. -\item -{\bf CBDC must not be easily counterfeited.} -Taler uses established cryptographic primitives and comes with a peer-reviewed -security proof. -\item -{\bf CBDC must be configurable in its design features in order to keep pace with - improvements in technology and security mechanisms.} -The key security settings in Taler (RSA key length, $\kappa$ CNC parameter) are -configurable. The protocol includes versioning features to enable future updates. -\item -{\bf It must be possible to withdraw/revoke a CBDC by serial number in case of proven -or suspected counterfeiting or theft.} -Counterfeiting can only happen if the exchange's signing key of a denomination is -stolen. If this unlikely event happens, this signing key for this -particular denomination can be revoked. Legitimate owners of funds in this -denomination can provide a proof of legitimate ownership, and will then be -reimbursed. -\subsection{General and non-functional} -\item -{\bf The ability to transact with CBDC must be ‘always on – in real time, 24 hours a day, -7 days a week.} - The Taler system is designed for 24/7 operations. -\item -{\bf The CBDC data structure must allow open access to third-party service providers to -add value. In general, the CBDC must be designed to encourage innovation and -enable value-added services.} -All components of Taler provide APIs, allowing new and innovative technologies -to be built. -\item -{\bf There are no expectations of the technology platform having to be based on DLT, -blockchain or an existing ‘traditional’ technology. It is envisaged that a solution could -be based on any one or a combination of technologies.} -Taler is not based on DLT or a blockchain. Instead, blind signature -technology is used. The ledger could be implemented in a blockchain, -if required. -\item -{\bf CBDC must be simple and user friendly.} -The Taler wallet enables one-click payments. We have successfully -tested the system with children below the age of 10. -\item -{\bf CBDC transactions must be fast and efficient.} -Taler requires only a few signature operations and only a few kilobytes -of data transfer per transaction. The Taler wallet pre-computes signatures -while waiting for the user to confirm the transaction. As a result, actual -transactions are usually confirmed in one network round-trip time (generally -in milliseconds) and with minimal energy consumption. -\item -{\bf Consumers must be able to transact in CBDC using smart phones and unstructured - supplementary service data.} -A Taler wallet for Android is under development. Payments via NFC are under -development. -\item -{\bf Processes must be provided to manage technology upgrades. This implies - that it must be possible for CBDC tokens to be withdrawn from circulation - and replaced with newly issued, more advanced CBDC.} Taler implements a -revocation mechanism to inform wallets that a particular signing key is being -withdrawn from circulation, forcing the wallets to automatically deposit coins -in circulation back into the consumer's bank account in case the CBDC is -discontinued, or to withdraw a different CBDC if available. Wallets -periodically check for such revocations and automatically adopt their money -holdings, without requiring input from the consumer. - -\end{enumerate} - - - -\section{Company profile} - -\subsection{Company structure and physical location(s)} - -%, with the -%emphasis on sustainability and the ability to undertake the -%feasibility project - -Taler Systems SA was established in 2016. -Taler Systems SA is headquartered in Luxembourg, but also has developers in -Germany and Switzerland. Taler Systems SA was founded as a startup by with -support from INRIA, the French national institute for research in computer -security (\url{https://www.inria.fr/}) and the Free Software community -(\url{https://www.gnu.org/}). The company is privately owned and debt-free. - -In response to the SARB's tender, Taler Systems SA has established -partnerships with Community-Exchange Systems NPC (CES) and JumpingBean INC -(JBI) from South Africa to jointly pursue this opportunity. -The Memorandum of Understanding between the companies is included in our -application materials. - -CES and JBI will provide community support, local developers and their general -expertise in the area of payment systems and software integration to the -project. The consortium plans to jointly work on integrating Taler with the -SARB's banking systems, and also offer integration support for the broader -e-commerce sector in SA. - -Taler Systems SA will focus on providig technical support for CES and JBI to -the best of its ability. In particular, Taler Systems SA will freely share -all of its documentation, code and technical expertise with its partners, -holding nothing back. Furthermore, Taler Systems SA will evolve the core -implementation to support SARB requirements to the extent this is feasible. - - -% FIXME: Leon - -\subsection{Capacity to support the feasibility project} - -% in terms of the -%location and availability of subject matter experts and -% technical support - -Taler Systems is in the unique position of not having technological business -secrets to protect, as all of our code and documentation is freely available. -Thus, we can easily find and train local partners in our technology and focus -on providing second-level support. - -Taler Systems has a large network of industry experts and specialists. -Our experts are in principle all available to work on the SARB project, as -we are currently investigating options for a first deployment of the Taler -product. - - -\section{Ability in the subject matter} - -\subsection{Participation in similar initiatives or projects} - -We have been involved in consultations with the Swiss National Bank, the -European Central Bank, and the Swedish Riksbank as all three were interested -in Taler in their respective CBDC initiatives. However, none of them is yet at -the point where the respective central banks have made any commitments for any -particular direction or technical solution. - -We are also working with the German GLS Bank on a commercial deployment of -GNU Taler and expect the technical integration with their banking platform -to be concluded later this year. - - -\subsection{Experience and skill set offered by the subject matter experts} -% -%and technical experts applicable to the feasibility project - -The Taler Systems SA executive team currently consists of the following -members: - -\begin{description} - \item[Dr. Christian GROTHOFF (Founder \& Technology)] Christian is Professor - for computer science at the University of Applied Sciences in Bern - focusing on network security and privacy. He is an Ashoka fellow, serves - on the GNU advisory board and maintains four GNU software packages. He - earned his PhD in computer science from UCLA, an M.S. in computer science - from Purdue University, and a Diploma in Mathematics from the University - of Wuppertal. - \item[Leon SCHUMACHER (Founder \& Business)] Leon is a leader in the - international CIO community who possesses a deep knowledge of the needs - and functioning of Fortune 100 companies. Prior to co-founding Taler, Leon - served as group CIO at two global companies, Mittal Steel and Novartis. - Leon earned his master’s in electrical engineering from ETH Zürich and his - master’s in management from HEC Paris. He also has a post-MBA certificate - from the Kellogg School of Management at Northwestern University. - \item[Michael WIDMER (Investor, Business Development, Legal \& Regulatory)] - Michael is an Entrepreneur and Investor. He brings to Taler his extensive - banking and financial market experience. In his 20 years of experience in - the international financial sector, he worked as a commercial lawyer, as - managing director of the Eurex stock exchange and as Co-CEO of the - Gutenberg Group. He received a Ph.D. in Law from the University of Zurich - and an executive MBA from University of Rochester. Michael is also - admitted to the Bar Association in Zurich. - \item[Dr. Florian DOLD (Founder \& Development)] Florian is a passionate - programmer and researcher. Prior to co-founding Taler, he worked on - GNUnet, a decentralized and privacy-preserving peer-to-peer - Framework. Florian earned his Master of Science from the Technical - University of Munich. He has obtained his PhD at Inria / Rennes 1 in this - subject. -\end{description} - -Our advisory board members are: -\begin{description} -\item[Jenny MENNA] SVP, Information Systems Security at US Bank -\item[Teppo PAAVOLA] Former Head of Business Development at PayPal -\item[Sekhar NAGASUNDARAM] Head of Enterprise Data Security at Visa -\item[Sandeep MEHTA] EVP, Enterprise Platform Services Tech at Wells Fargo -\item[Greg FRAMKE] CIO at Manulife / John Hancock (former COO Etrade) -\item[Chris PAGETT] former Head of Security Fraud \& geopolitical Risk at HSBC -\item[Ante GULAM] CISO, Skyscanner -\item[Manish TIWARI] CISO, Airtel India -\item[Lars RABBE] former CIO of Yahoo! and Skype -\item[Justin DOLLY] EVP, CISO at Malwarebytes -\item[Dr. Richard STALLMAN] Founder of the GNU Project -\item[Dr. Mikhael ATALLAH] Professor of Computer Science, Purdue University -\item[Dr. Alex PENTLAND] Professor of Computer Science, MIT Media Lab -\item[Dr. Roberto DI COSMO] Professor of Computer Science, Director of IRILL -\item[Dr. Edgar FLEISCH] Professor of Information Management, ETH Z\"urich -\end{description} - -CES is operating a global network of regional community payment systems -based on software originally developed by Tim Jenkin, who will work with -the project in his capacity as director of CES. Tim Jenkin will also bring -in his network of contacts and developers in SA to support the project. - -JBI is a Free Software consultancy based in SA focusing on providing -integration solutions for e-commerce. They are ideally suited for assisting -us onboard businesses in SA to the GNU Taler platform. Mark Clarke also has a -network of contacts in SA to bring in further support for the project if -required. - - -\subsection{Commentary on the CBDC principles and attributes} - -We provided detailed commentary on each of the CBDC principles and attributes -in Section~\ref{section:cbdc:requirements}. In summary, we believe that we -cover most of the critical requirements well. - -Overall, it should be noted that we believe it to be {\em impossible} for any -available technology to provide off-line transactions with a purely -software-based (and hence cost-efficient) solution without creating systemic -risks from deferred double-spending detection. - -We are also surprised that data protection, data minimization and in general -respecting citizen's economic privacy is not listed as a primary objective and urge the -SARB to consider adding privacy considerations to their requirements. - -Similarly, we hope that SARB understands the value of a Free Software solution -in that it preserves SA's independence from particular vendors. Furthermore, -open standards and public source code enhance public verifiability and thus -the public's trust and acceptance in the solution. We believe that only a Free Software -solution can be in the best long-term interest of South Africa as it ensures -technological independence and sustainability, as was recently demonstrated -by the US government forcing Google to terminate all licenses to Huawei -{\bf except} those for Free Software. - -\section{Proposed approach and methodology} - -\subsection{Proposed approach to support the objectives} -%of the -%feasibility approach specifically and the needs of an -%innovation lab (sandpit) in general - -A realistic CBDC solution based on the Taler system requires integration with -an existing register-based banking system. Here, the Taler architecture calls -for the implementation of a simple adapter that needs to be able to query the -banking system for wire transfers into the escrow account and needs to be able -to trigger wire transfers from the escrow account/central bank liability into -merchant accounts. Once these two simple operations are implemented, Taler -can in principle transact in the respective currency. - -We would typically expect this integration with the existing SA banking system -to be the first step. In parallel, the specific regulatory requirements on -launch would be discussed and then deployed in the sandpit. At that point, one -might begin making the API publicly accessible to allow businesses to -experiment with integrating Taler support into their systems, while performing -exercises to stress test the system to ensure acceptable availability under -high load or component failures. - -The CBDC Taler wallet can exist on smartphones, in browsers, on smartcards or -secure USB sticks. However, typically the integration with the diverse payment -operations used in a country will take time. Taler Systems SA has already -integrated Taler support with a few shopping systems, but largely to gain -experience with the process. We have had a team of Bachelor students -successfully integrate Taler with a Web shop with virtually no support from us -as part of a student project in their 2nd year of study. Thus, given our open -system specification and Free Software reference implementations we expect the -bulk of the work to be done by local small businesses, which would only fall -back on us for 2nd level support. - - -\subsection{Methodology proposed to support the proposed approach} - -SARB issues electronic coins based on deposits into an escrow -account. Citizens could use their wallets to withdraw CBDC -from their traditional bank accounts, or they could be provided -CBDC directly (for example via social security) if they lack -a bank account. Electronic coins are blindly signed -by the issuing exchange, which is obliged to exchange CBDC -back into rand when they are deposited by merchants. An auditor -supervises the operation of the exchange, unless the exchange -is fully operated within SARB's trusted infrastructure. In this -case, SARB may still want to run the auditing logic to provide -assurance against insider threats. - - -\section{Secondary objectives} - -In this section, we want to anticipate the conclusions SARB -might draw for its secondary objectives (Section 2.3 of the -tender) with respect to the Taler system. While of course -the objective of the sand pit would be for SARB to draw these -conclusions, we want to provide an idea what results we predict -for these questions on the basis of our technology. - -\subsection{Focus area 1: Design considerations} - -\paragraph{What are the potential and preferred design options and deployment models of a - SARB-issued CBDC, and why?} -%Potential deployment models, for the purpose of -%the project, can either be based on distributed ledger technology (DLT) or -%cryptography. - -Deployment models using a truly distributed ledger will prove exceptionally -expensive and unable to handle the required transaction rates to be relevant -for non-criminal enterprises. - -In contrast, cryptographic techniques like those offered by Taler require -professionally-run mission-critical infrastructure, but will then be able to handle -transactions at rates comparable to those provided by cash today at lower cost. - -\paragraph{What are the emerging technologies that underpin CBDC designs and which - technology option(s) are appropriate, and why?} - -The Taler system was designed from its inception in 2013 to underpin a CBDC -for a socio-liberal society, respecting both the need for the state for -taxation and fundamental human rights, chiefly the protection against -discrimination and the right to privacy. - -Alternative designs will generally infringe upon either of these two fundamental -aspects, either enabling totalitarian control or an unrestricted criminal -economy. - -\paragraph{How would these technologies integrate into the SARB current and future -architecture?} - -Taler would be integrated via one or more escrow accounts in the -existing register-based banking system. Money transferred into these -escrow accounts by social security agencies or citizens would move -into the respective electronic wallets of the consumers via an -Internet service. Eventually, ATMs might also be used to exchange -cash deposits for CBDC, or transfer funds from bank accounts to -electronic wallets via NFC. The overall changes to the SARB's -architecture would be minimal, except that the operation of the -Taler system at scale may require an expansion of the existing -data centers. - -\paragraph{What are the possible transition arrangements, after due consideration of all the -relevant economic and financial/financial system implications as articulated -below?} - -Once an exchange is operational, customers and businesses would be -free to gradually migrate payments to the Taler CBDC. Given the -cost, security and convenience advantages, we expect this to be -largely driven by market forces. The CBDC would co-exist and -compete with existing payment methods (cash and commercial offerings). -As Taler is reserve-based, it would not compete with credit cards -used by consumers to get credit. - -We expect the fastest uptake to be in the market for e-commerce payments and -micropayments. Micropayments in particular will provide an alternative -new business model, especially for businesses depending on online -advertising for revenue today. - -\subsection{Focus area 2: Policy impact} - -\paragraph{Why should the SARB consider the issuance of a CBDC? How does issuance - link to the SARB’s mandate?} - -CBDC is a natural progression from cash. Compared to cash, Taler offers -superior protections against counterfeit, usability for online transactions, -lower cost, and income transparency / tracability. - -Furthermore, SARB would be the first central bank offering solutions for smart -contracts and has a clear response with respect to the issues caused by -speculative crypto currencies. In addition, with Taler SARB has a payment -system that is largely independent from the existing payment infrastructure -like cash. - - -\paragraph{How could the respective design options impact monetary policy, financial -stability, fiscal policy, financial market structures and any other policy objectives -(financial inclusion, competition etc.)?} - -A CBDC based on Taler opens a few additional options for monetary policy, such -as the possibility of charging a negative interest rate on CBDC.\footnote{For - a historic experiment with negative interest on cash, see - \url{https://en.wikipedia.org/wiki/W\%C3\%B6rgl#The_W\%C3\%B6rgl_Experiment}} - -A Taler CBDC may provide a national electronic payment standard, reducing -friction from a multitude of commercial offerings. - -Using an open standard with a Free Software reference implementation will -reduce technological barriers to entry and monopoly abuse (say by credit -companies charging high fees). Taler's privacy-respecting design ensures an -equal playing field for all. Finally, the Taler wallet could be augmented -with features to help citizens manage their budget, improving financial -literacy. - -\subsection{Focus area 3: Intended and unintended consequences} - -\paragraph{What are the potential economic and financial system impacts (e.g. on gross -domestic product, inflation targeting, monetary policy transmission mechanisms, -and impacts on financial institutions)?} - -Lower transaction costs should have similar impacts on gross domestic -product as a similar reduction in VAT, except without the government -spending cuts that usually follow tax reductions. - -Taler should be neutral on inflation targeting and monetary policy -transmission mechanisms. - -Financial institutions that rely on income from providing electronic -payment services may see some loss in profits. However, as Taler has -fundamentally lower costs, the losses in profits by commercial payment -service providers would be significantly below the cost reductions -achieved at a national scale. - -\paragraph{What are the major benefits and risks (including cyber-risks)? What potential -attack vectors are related to the issuance of a CBDC? What are the SARB’s -liability implications in the event of a significant breach?} - -CBDC systems, as all networked systems, require high-security and -high-availability deployments. Power- and network outages would have -more-or-less catastrophic impacts on the ability of businesses to run -transactions. Thus, high levels of redundancy should be in place to provide -availability once a significant share of transactions is performed by -Taler. SARB may also want to mandate that shops continue to accept physical -cash. - -Taler includes key revocation mechanisms to bound the worst-case impacts of -cyber attacks compromsing private keys. Any given private key would be used to -only sign a limit amount of CBDC into existence. Compromising that private key -would result in financial damage limited to the amount of {\em legitimate} -CBDC signed into existence with that key. Thus, financial liabilities from -issuing CBDC with Taler are limited, and frequent re-keying can be used to -further minimize the potential damage. - - -\paragraph{What are the lessons learned from practically issuing a CBDC in a test - environment?} - -The tests of the Taler system have demonstrated that the system is very -stable, fast and can handle large transactions. We expect to learn about the -complexity of integrating Taler with the wire transfer system of SA, and SARB -to learn how easy (or difficult) it is to migrate existing services to support -the Taler protocol. - -SARB will also learn details about the regulatory capabilities Taler offers, -and where the limitations on regulation are. - -\subsection{Focus area 4: Legal and regulatory regime} - -\paragraph{What are the legal implications and impacts of issuing a CBDC?} - -We are not familiar enough with the legal framework in SA to -comment on this question. - -\paragraph{What would a regulatory regime need to consider (e.g. how would the CBDC -scheme be structured and who would determine the scheme ‘rulebooks’)?} - -We can see two possible regulatory regimes, with either the SARB being -solely responsible for the issuance of Taler coins denominated in rand, or -with commercial banks issuing electronic rand. -In the first case, the Taler coins, i.e. electronic rand coins must -be recognized as legal tender like cash. -In the latter case, the -commercial banks would be subjected to permanent security audits to -verify that their escrow balance matches the amount of issued electronic -coins. Commercial banks may also have to take out insurance to cover -the potential losses from an attacker compromising their operations. - -\paragraph{What potential high-level rules would need to be considered (e.g. participation -criterion, chargebacks, liability shifts).} - -Compared to other electronic payment systems where liabilities are typically -with the payment service provider, Taler shifts some liability to the -consumer: if a consumer's system is compromised, the attacker may spent the -consumers CBDC, just like a burglar may steal a physical wallet full of cash. - - -\subsection{Focus area 5: Ongoing monitoring, and incorporating learnings and -perspectives from other central banks and related local and international -forums} - -\paragraph{Continued participation and research in global developments pertaining to CBDC.} - -Taler Systems SA is involved in various academic communities (W3C, IETF, -Bankademia) and will continue to evolve Taler to try to best meet the business -and regulatory requirements of our customers. - -\paragraph{Incorporating learnings and perspectives from other global participants in CBDC - in the SARB CBDC project, where relevant.} - -Taler Systems SA will continue its engagement with commercial -and central banks on a global scale, and of course feed this -experience into any engagement with SARB. - -\paragraph{Ongoing engagement with key stakeholders (local and international) on the topic -of CBDC to broaden the knowledge base and relationships.} - -We know that three European central banks are quite interested in -Taler, and while they have made no decisions on CBDCs, we expect -them to closely watch any experiments with a Taler CBDC in SA. - -\section{Conclusion} - -Taler effectively provides electronic cash and thus solves the problem -of gaining access to risk-free assets. As the SARB supervises the -CBDC escrow funds (either directly or by auditing the private -operator), the government can assure citizens that they can always -exchange CBDCs back to cash. Thus, in Taler's design, the government -acts as a trust anchor. - -Taler removes inefficiencies the current system creates through fraud -risks inherent in register-based systems. In Taler, citizens only -ever authenticate to their bank (or social services). By avoiding -disclosing personally identifying information or even performing -credit card-style authentication via third parties, Taler improves -usability and eliminates most vectors of authentication token -compromise. - -Further information about the Taler system can be found at -\begin{center} - \url{https://taler.net/} -\end{center} - - -\section*{Contact} - -\renewcommand\logo{} - -\begin{center} - \includegraphics[width=0.5\textwidth]{../presentations/comprehensive/taler-logo-2018.pdf} - \vfill - {\Large \url{https://taler.net/}} - \vfill - -\begin{tabular}{l l} - Dr. C. Grothoff & grothoff@taler.net \\ - Dr. F. Dold & dold@taler.net \\ - L. Schumacher & schumacher@taler.net \\ - M. Widmer & widmer@taler.net \\ -\end{tabular} -\end{center} - -\vfill - -\includegraphics[width=0.2\textwidth]{../presentations/investors/partner-logos/ashoka.png} -\hfill -\includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/inria.png} -\hfill -\includegraphics[width=0.1\textwidth]{../presentations/comprehensive/bfh.png} -\hfill -\includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/tum.png} -\hfill -\includegraphics[width=0.1\textwidth]{../presentations/investors/partner-logos/gnu.jpeg} - -\end{document} - - - -\subsection*{What would a solution for a register-based CBDC look like?} - - -\subsection*{What would a solution for a value-based CBDC look like?} - - -\section*{What is your vision for an CBDC?} -% Are there other possible solutions than register-based and value-based that you consider to be more appropriate?} - - - - -\section*{What challenges and opportunities do you envisage?} - -Taler provides the advantages of cash while supporting taxation and -limiting criminal abuse, as recipients of payments are identifiable. -Furthermore, Taler transactions are faster, easier and more secure -than cash or credit card transactions. - -The main challenge is the integration of the Taler merchant backend -into the diverse POS systems that exist today. While integrating -Taler can be done with a few hundred lines of code, NFC-enabled POS -systems would require at least a firmware update. Convincing vendors -to upgrade their systems will thus require a major up-front -investment. - -Taler also requires further development to ensure that wallets are -available on all relevant platforms. However, consumer systems are -much less diverse and hence this effort is significantly smaller. - -Deploying Taler at scale should have no major impact on monetary -policy because the issued CBDC would be 1:1 backed by rand -in the escrow account at the SARB. However, if there is a -significant shift from the use of credit-cards to CBDC, there might -be a reduction in M2 from fractional reserve banking as CBDC is -debit-based while credit-cards are credit-based. Thus, instead of -commercial bank money being created from debts, consumers may -effectively hold CBDC claims against the escrow account at the -central bank. The resulting reduction in M2, and the loss of revenue -at banks from credit-card interest payments, may require adjustments -in monetary policies. - - -\section*{What is missing in our concept?} - - -A key requirement for governments considering electronic payment -systems is the preservation of the Commons. Cash is a Commons as all -market participants have equal liberties in handling cash. If cash is -replaced by proprietary solutions such as Visa's credit card system or -ApplePay, these companies have exclusive control over critical -infrastructure, which often leads to high fees. Worse, such payment -service providers may discriminate against individuals or certain -businesses and can refuse service to individuals or businesses without -judicial oversight. - -In contrast, Taler is implemented as Free Software distributed under -the GNU General Public License, and without patent encumbrances. This -ensures that any government retains sovereignty after deploying Taler, -as it can liberally inspect, use and modify the software. In -particular, no foreign government or company can impose their own -restrictions or regulatory regime. Governments can foster competition -between multiple Taler exchange operators, or run a Taler exchange as -a government monopoly equivalent to a government mint for coins. - - - -\section{Addressing CBDC Requirements} - -We now sketch how the Taler components map to a Centrally Banked Digital -Currency system run by the ECB or national central banks (NCBs), according to -the draft requirements. Taler is a value-based payment system (as opposed to -an account-based system), and thus we will address the common requirements -C1-C8 and requirements V1-V4 specific to the value-based model. - -\paragraph{C1. Tokenization:} \emph{Units of digital currency (CBDC units) are only created against money -blocked on a transit account, which will be held by ECB/NCBs}. - -The ECB/NCBs would simultaneously take the role of the Taler Exchange -and Taler Auditor (or could outsource operations to qualified third parties). - -\paragraph{C2. Issuance:} \emph{A central authority creates new CBDC units on -the reception of the transfer of an equivalent EUR amount from the -participating bank to the transit account. The same logic applies to the -destruction of existing CBDC units, where the central authority destroys CBDC -and releases EUR that were previously held by the ECB/NCBs in the transit -account.} - -The ECB/NCBs create new CBDC units by issuing Taler digital coins, -and destroy CBDC units by accepting digital coin deposits from merchants, subsequently releasing -funds blocked in the escrow account and sending them to the merchant's bank account. - -\paragraph{C4. 1-on-1 parity rule:} \emph{The parity rule applies when CBDC units are newly created or destroyed, -meaning that for each EUR blocked in (released from) the transit account there will be exactly -one CBDC created (destroyed). The parity rule also applies when CBDC are exchanged for -commercial bank deposits or physical cash, and vice versa.} - -Digital coins in GNU Taler correspond 1-on-1 to a -value in a fiat currency such as the Euro. - -\paragraph{C4. Two-tier structure:} \emph{The central authority issues CBDC only to entities entitled to deposit funds -in the transit account held at ECB/NCBs in exchange for newly issued CBDC units. Also, end- -users’ access to the CBDC payment system is intermediated via other entitled entities, acting as -gateways. All these entities, hereafter “tier-2 entities”, could be commercial banks or non-banks -(for example, payment service providers (PSPs), wallet providers etc.).} - - -With Taler, national banks could serve as -the primary Tier-2 entity, establish customer's identities (KYC) during bank -account setup, and facilitate the transfer from a customer's bank -account to the exchange's escrow account. A secondary Tier-2 entity are the wallet providers. -Banks can serve as wallet providers, but other third party businesses could offer -a wallet backup/sync/restore services as well. Customers are also given the option to be -responsible for the security of their wallet on their own, and manage private keys directly -and on their own device. - - -\paragraph{C5. Compliance with AML regulation:} \emph{Transactions with amounts above a certain threshold must be -disclosed to relevant parties as required by the AML regulation. In general, the system must be -designed in a way that discourages end-users from using it for anonymous large-value -transactions.} - -Strict withdrawal limits can -be placed on customers' bank accounts. Merchants can be required to collect -customer data for critical transactions. Due to the technical measures -that provide transparency of cash flows to merchants, the compliance of -merchants is easy to verify. - -\paragraph{C6. Fees:} \emph{The system should enable fee collection. The issuance of CBDC to banks and the -destruction of returned CBDC are free of charge for the entitled tier-2 entities (i.e. banks). Tier-2 -entities can, however, charge fees to end-users for services they provide, such as their -involvement in the transfers of CBDC and/or the exchange of EUR into CBDC and vice versa.} - -Taler has a flexible fee structure that is easily configured so that Tier-2 banks -can charge for CBDC creation and other activities. - - -\paragraph{C7. Availability:} \emph{Payments are processed 24 hours a day, 7 days a week, 365 days a year, without -operational downtimes.} - -Taler requires no manual processing and can be made highly -available with standard software deployment and operations techniques. - - -\paragraph{C8. Throughput, transaction time and micropayments:} \emph{The -payment system must be able to handle a sufficiently large amount of -transactions. Each transaction must be processed real-time (to be compliant -with the SEPA Instant Credit Transfer (SCT Inst) scheme, the transaction time -would have to be maximum ten seconds). Furthermore, the payment system -should/could enable micropayments (low value, large volume, low cost, real time -transactions).} - -Transactions -with Taler are processed in the order of milliseconds. Unlike DLTs, Taler can -be easily scaled both horizontally (sharding, more processing nodes) and -vertically (faster machines). Since multiple payments to a merchant can be aggregated into -one bank transfer, even micropayments with fractions of a cent are possible. All coins -are issued with expiration dates, ensuring that the exchange may eventually delete ancient -transactions. - -\paragraph{V1. Non-interest-bearing:} \emph{In the value-based model, holdings of CBDC do not bear interest - neither -positive nor negative.} - -In Taler, digital coins do not bear interest; however, -when coins expire it is possible to charge fees when the electronic wallets trade -expiring coins for fresh coins. This feature may be used to -provide a mechanism for negative interest rates (for non-circulating coins). - - -\paragraph{V2. Limitation of bank runs:} \emph{In the value-based model, to avoid a situation, in which end-users -(suddenly) shift large amounts of their commercial bank deposits to CBDC, daily (potentially also -weekly or monthly) limits should be imposed on the amount that can be converted from -commercial bank deposits into CBDC.} - -Bank runs are discouraged and limited with Taler: (1) Withdrawal -limits can be imposed by the Tier-2 banks on the withdrawal of CBDC units; (2) wallet providers may place limits -on how much money can be stored in online wallets; (3) customers that mange their own wallet are discouraged from -storing large amounts of CBDC units in their wallets, as they must ensure its safety similar to a physical wallet; -(4) modest expiration times with modest refresh fees make hoarding coins unattractive. - - -\paragraph{V3. Anonymity and AML:} \emph{The system should allow anonymous low-value transactions (below a -certain amount used as threshold). Moreover, it should be possible to trace large-value -transactions and link them to the identities of the participants (through KYC). Furthermore, as -countermeasure against splitting large-value transactions into multiple low-value anonymous -transactions, it should be possible to identify multiple low-value transactions which are -processed within a certain period of time and which sum up to an amount greater than the -chosen threshold.} - -The exchange does not know which customer owns which coin -due to the use of blind signatures during the withdrawal process. -AML measures are based on the \emph{income transparency} feature, -where cash flows to merchants are visible to the exchanges (and -thus ECB/NCBs). As the merchant redeems CBDC units with a transaction to their bank account, the KYC process -already happened when the merchant opened their SEPA bank account. Furthermore, the -deposit permissions are linked to the contract with the customer, allowing authorities -to validate the plausiblity of the transaction during tax audits. -With Taler, ownership of digital coins between mutually distrusting parties can only be securely transferred with a digital coin deposit via the exchange. -This discourages ``invisible'' payments by sharing digital coins between wallets -without involving the exchange. - -\paragraph{V4. Ownership and spending rights of CBDC:} \emph{In the value-based model, units of CBDC are held by -end-users themselves. Each end-user has cryptographic information (e.g. private keys, other -secrets) without which CBDC units associated with that particular cryptographic information -material cannot be spent. Spending rights are defined by technology (e.g. if you have private -keys you can spend).} - -Technically literate -users have the option to manage their own wallets and private keys, whereas -other users can use wallet backup/sync/restore providers. - -\section*{Contrast and Relationship to DLT-based Systems} - -The Taler payment system is independent from Distributed Leder -Technology (DLT) systems. In particular, Taler payments are not -necessarily backed by any blockchain or cryptocurrency. Even though -Taler uses cryptographically secured payment tokens, it is distinct -from ``cryptocurrencies'': Taler is a very efficient electronic -payment system with certain characteristics like cash, but it is not a -currency. Taler is designed to serve as a payment instrument for -retail commerce, in contrast to DLTs which are generally used more as -a long-term stores-of-value or as speculative assets. - -Some technological advancements made by DLTs could potentially benefit Taler. -For example, public cryptographic key material and data relevant for auditing -could be further secured by a distributed ledger. Yet a distributed ledger is -not mandatory to operate Taler, as payments are facilitated by a federation of -trusted entities, with oversight from each other and/or a central institution, -not too dissimilar from how traditional banking systems work. diff --git a/sa/tender.pdf b/sa/tender.pdf Binary files differ.
