[GNUnet-SVN] [taler-marketing] branch master updated: comments and fixes

[gnunet]

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

dold pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new f0d252a  comments and fixes
f0d252a is described below

commit f0d252af44f00232eaca026933a378a5e2176894
Author: Florian Dold <address@hidden>
AuthorDate: Sat May 25 17:07:53 2019 +0200

    comments and fixes
---
 sa/sa.tex | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 58 insertions(+), 13 deletions(-)

diff --git a/sa/sa.tex b/sa/sa.tex
index 6bf4c59..cd22e96 100644
--- a/sa/sa.tex
+++ b/sa/sa.tex
@@ -25,12 +25,17 @@
 
 \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
+  % FIXME(dold):  I stumbled over the "reducing" here, even though it
+  % is technically correct.
   customers to the same merchant, thereby reducing the transaction rate in the
   register-based accounting system.  Taler provides privacy for consumers
   and accountability for businesses receiving payments.
@@ -43,8 +48,8 @@ Taler Systems SA is developing an online payment system 
called Taler, that
 broadly fits the requirements of SARB's CBDC project.  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.
+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
@@ -55,16 +60,18 @@ data retention periods have expired).
 The USPs of Taler are:
 
 \begin{itemize}
-\item All operations provide cryptographically secured, with mathematical
+\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
+% FIXME(dold): Widely used systems sound awkward here
 \item Linear scalability ensures Taler handles transaction volumes of widely 
used systems
 \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 Open standard protocol without patents, with free reference 
implementation
+\item The patent-free, open standard protocol and the free reference 
implementation provide
+  long-term sustainability and technological independence from foreign 
providers
 \end{itemize}
 
 The Taler architecture includes a register-based system of bank accounts
@@ -130,7 +137,7 @@ 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 limits.  When withdrawing electronic coins, they are blindly signed by the
+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
@@ -174,13 +181,15 @@ acting as issuing authorities under the regulatory 
oversight of the SARB.}
 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.}
-  Taler is intended for consumers. It is unclear to us what the value would be
-  in restricting distribution to commercial banks and service providers only
-  and thus excluding consumers.
+  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.}
+  % FIXME(dold): do you have a citation for this?
   Recent developments in California 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
@@ -212,7 +221,7 @@ cash to some extent over time.}
 {\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, convenience, competition, and privacy.
+  improved security, sustainability, convenience, competition, and privacy.
 \item
 {\bf CBDC must be ubiquitous and accepted as a means of payment by all sizes of
 business and by the government.}
@@ -243,6 +252,8 @@ Monetary Area (CMA).}
   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 to receive payments.
+  % ^^ FIXME(dold): What about pay-to-kyc-reserve?  This would allow 
KYC-audited
+  % wallets to receive payments without having a real bank account.
 \item
 {\bf Consumers and businesses must be provided with the channels to obtain or 
return
   CBDC in exchange for cash and commercial bank money.}
@@ -272,6 +283,10 @@ policy positions in future.}
 \item
 {\bf CBDC must be unique in its design and its SARB ownership must be clear and
   evident.}
+  % FIXME(dold):  This should be phrased differently to be less
+  % off-putting.  We should explain that while Taler is an existing and
+  % free protocol, the *deployment* of Taler in SA can be completely 
SARB-branded
+  % and owned.
   SARB is welcome to create any particular branding, especially for
   consumer-facing products. However, the
   Taler {\em protocol} will be a global commons (Free Software) and other
@@ -294,6 +309,10 @@ policy positions in future.}
 \item
 {\bf It must enable immediate person-to-person transfer of value without 
clearing and
   settlement in today’s terms.}
+  % FIXME(dold): Are we interpreting this too strongly?
+  %   To me, "immediate person-to-person transfer" does not imply offline.
+  %   Just as we require electricity to be available, we could assume the same
+  %   about connectivity.
   Taler enables offline person-to-person transfers without the involvement of 
third parties
   only if those individuals form an economic union, that is trust each other to
   behave honestly. Basically, such transfers are not transactions in that the 
sender
@@ -314,10 +333,13 @@ policy positions in future.}
 \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.
+  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.}
+  % FIXME(dold):  Isn't this underselling it a bit?  Using a backup+sync
+  % provider for larger sums, I can have the same security as for a bank 
account.
   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,
@@ -326,7 +348,7 @@ policy positions in future.}
   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 RTT, concluding with
+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
@@ -335,6 +357,14 @@ the absence of connectivity/Internet/data, consumers must 
be able to transfer va
 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.}
+  % FIXME(dold): mention that this is inherent (without HSMs or having to 
trace down
+  % criminals after they double-spent).  Also mention that for certain 
transactions
+  % (buying a service that is delivered later or long-standing trust / 
business relationship),
+  % offline-payments can be done, but do not provide finality.
+  %
+  % In fact even the question mentions "reconcile transaction data once online"
+  %
+  % If the budget is available ;-), special offline hardware wallets *could* 
provide this
   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.
@@ -376,7 +406,7 @@ payment system.}
   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 sale of weapons, drugs, chemicals or high-value goods) 
merchants may
+  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
@@ -399,7 +429,7 @@ payment system.}
 \item
 {\bf CBDC must be issued using highly secure and trusted modern cryptographic
   mechanisms.}
-Taler is only using modern cryptography (RSA, SHA-512, EdDSA/Curve25519).
+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
@@ -418,6 +448,11 @@ configurable.  The protocol includes versioning features 
to enable future update
 \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,
@@ -427,10 +462,14 @@ or suspected counterfeiting or theft.}
 {\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.
 \item
 {\bf CBDC must be simple and user friendly.}
 The Taler wallet enables one-click payments.  We have successfully
@@ -579,6 +618,9 @@ available technology to provid off-line transactions with a 
purely
 software-based (and hence cost-efficient) solution without creating systemic
 risks from deferred double-spending detection.
 
+% FIXME(dold):  privacy itself is usually not desireable
+% for policy makers.  maybe we should argue from the view point of
+% data protection and data breaches.
 We are also surprised that privacy for citizens using the system is
 not listed as a principle objective and urge the SARB to consider
 adding privacy considerations to their requirements.
@@ -588,6 +630,9 @@ 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 in the solution.
 
+% FIXME(dold):  can we somehow emphasize more the technological independence
+% and sustanability aspect?
+
 \section{Proposed approach and methodology}
 
 \subsection{Proposed approach to support the objectives}

-- 
To stop receiving notification emails like this one, please contact
address@hidden