[taler-marketing] branch master updated: Fix the citation of the question

[gnunet]

This is an automated email from the git hooks/post-receive script.

emmanuel-benoist pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new ace6398  Fix the citation of the question
     new a5e16a9  merge conflict
ace6398 is described below

commit ace6398394f24c6ea8ee3a449776140ab2d670fd
Author: Emmanuel Benoist <emmanuel.benoist@bfh.ch>
AuthorDate: Fri Jan 28 18:09:30 2022 +0100

    Fix the citation of the question
---
 2022-privacy/privacy.tex | 60 ++++++++++++++++++++++++------------------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
index aae409b..88e6347 100644
--- a/2022-privacy/privacy.tex
+++ b/2022-privacy/privacy.tex
@@ -169,10 +169,24 @@ sovereign: the European citizens.
 
 The French report~\cite{french2021} correctly states that a Digital Euro based
 on accounts poses ``democratic risks'' and could allow ``state surveillance of
-all transactions of every individual''.  The use of the term ``surveillance''
-here actually understates the negative impact of an account-based CBDC, as
-with an account-based CBDC the central bank would likely also be in a position
-to prevent individuals from spending money and to manipulate their balances,
+all transactions of every individual''. 
+Subsequently the wording of the French report is misleading, as it turns the
+possibility of privacy-invasive monitoring into a mandatory feature of any
+CBDC, which is demonstrably false: There are many digital currencies and
+payment systems that do not allow comprehensive
+surveillance~\cite{monero,dold2019}.  Thus, it is wrong for the authors of the
+French report to take a possible design choice of an account-based system as a
+necessity, for example when they write that ``the centralization and data
+tracking of central bank digital currency projects leads to a loss of privacy
+that coupled with the programmability of the currency can have serious
+consequences.''  Using the indicative here is a serious mistake, as it is
+understood that any CBDC design would necessarily lead to a loss of privacy,
+when this is false.
+
+Furthermore, the use of the term ``surveillance'' in the French report actually
+understates the negative impact of an account-based CBDC, as with an
+account-based CBDC the central bank would likely also be in a position to
+prevent individuals from spending money and to manipulate their balances,
 thereby gaining comprehensive power over the economic activities of
 individuals going far beyond mere analytical capabilities. The use of
 permissioned blockchains does not inherently prevent such manipulations as
@@ -182,33 +196,19 @@ ignore this danger and must reestablish the principles of 
personal
 responsibility, personal independence and subsidiarity in the design processes
 for critical infrastructure created by European institutions.
 
-Here the wording of the French report is confusing, as it suggests that
-privacy-invasive monitoring would be a mandatory component of any CBDC, which
-is demonstrably false: There are many digital currencies and payment systems
-that do not allow comprehensive surveillance~\cite{monero,dold2019}.  Thus, it
-is wrong for the authors of the French report to take a possible design choice
-of an account-based system as a necessity, for example when they write that
-``the centralization and data tracking of central bank digital currency
-projects leads to a loss of privacy that coupled with the programmability of
-the currency can have serious consequences.''  Using the indicative here is a
-serious mistake, as it is understood that any CBDC design would necessarily
-lead to a loss of privacy, when this is false.
-
 Since this far-fetched assumption is taken as true while counterexamples
-exists, the conclusion of the first part of the French report follows a 
logical fallacy.
-In it, the authors ask ``Should the objectives, mandate and governance of 
central banks be redefined?'',
-% FIXME: this is a bad quote, we should quote not a question on 'should',
-% but their specific conclusion THAT the mandate needs a redefinition (if they 
make such a conclusion).
-implying that the deployment of a CBDC would be impossible in the current
-state.  But adaptations of central bank missions to include ``absolute control
-over the rules and regulations of the use'' of money via the issuance of a
-CBDC (as envisioned by Agustin Carstens of the Bank of International
-Settlement\footnote{See speach given on October 19th 2020 on ``Cross-Border
-Payment -- A vision for the future''}) are dangerous if the central bank can
-choose to void privacy assurances.  Carsten's reasons include that the
-central bank should have the ability to know about every payment. As he
-states that the central bank would be able to strictly enforce its rules
-and regulations, this implies the bank could arbitrarily block
+exists, the conclusion of the first part of the French report follows a
+logical fallacy.  The authors assert that ``the new properties of CBDC raise
+political questions'' which implies that the deployment of a CBDC would be
+impossible in the current state.  But adaptations of central bank missions to
+include ``absolute control over the rules and regulations of the use'' of
+money via the issuance of a CBDC (as envisioned by Agustin Carstens of the
+Bank of International Settlement\footnote{See speach given on October 19th
+  2020 on ``Cross-Border Payment -- A vision for the future''}) are dangerous
+if the central bank can choose to void privacy assurances.  Carsten's reasons
+include that the central bank should have the ability to know about every
+payment. As he states that the central bank would be able to strictly enforce
+its rules and regulations, this implies the bank could arbitrarily block
 payments by private citizens. The repressive potential of a government with
 such a capability is so large that it must be firmly rejected.
 

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