commit 43c6795d4f53ee251f81c6045fcf31dbb47d811d
parent 7d88d81e18f3f12e5b4e96e3ffd93607eeb59d61
Author: Florian Dold <florian.dold@gmail.com>
Date: Sun, 26 May 2019 11:56:44 +0200
resolve some fixmes
Diffstat:
| M | sa/sa.tex | | | 46 | +++++++++++++++------------------------------- |
1 file changed, 15 insertions(+), 31 deletions(-)
diff --git 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.
