[GNUnet-SVN] [taler-marketing] branch master updated: resolve some fixmes

[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 43c6795  resolve some fixmes
     new c3c5af3  Merge branch 'master' of ssh://git.taler.net/marketing
43c6795 is described below

commit 43c6795d4f53ee251f81c6045fcf31dbb47d811d
Author: Florian Dold <address@hidden>
AuthorDate: Sun May 26 11:56:44 2019 +0200

    resolve some fixmes
---
 sa/sa.tex | 46 +++++++++++++++-------------------------------
 1 file changed, 15 insertions(+), 31 deletions(-)

diff --git a/sa/sa.tex b/sa/sa.tex
index bd38b41..a43f9d7 100644
--- a/sa/sa.tex
+++ b/sa/sa.tex
@@ -34,9 +34,7 @@
   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
+  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}
@@ -274,17 +272,12 @@ policy positions in future.}
 \subsection{Branding}
 \item
   {\bf CBDC must be branded and its ownership by the SARB as issuer must be 
evident.}
-  Given that the CBDC is denominated in rand, this should be trivial.
-  We can also create SARB-branded software if desired.
+  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.}
-  % 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.
-  % "completely owned" might be wrong here, as the underlying code would not be
-  % owned by SARB.
   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
@@ -309,13 +302,9 @@ 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.
-%  RE: True, but offline is mentioned later. So I figured it would make sense 
to look at both cases here.
   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
+  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.
 
@@ -357,20 +346,15 @@ 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
-% RE: tried to address it.
-  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.  
+  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.

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