gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-marketing] branch master updated: more Berna feedback


From: gnunet
Subject: [taler-marketing] branch master updated: more Berna feedback
Date: Sat, 25 Feb 2023 20:07:54 +0100

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

grothoff pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new 39ff430  more Berna feedback
39ff430 is described below

commit 39ff430d979e4d20b28385fe2466d9fb4cac0539
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Feb 25 20:06:57 2023 +0100

    more Berna feedback
---
 presentations/comprehensive/sic.tex | 111 +++++++++++++++++++++++++-----------
 1 file changed, 77 insertions(+), 34 deletions(-)

diff --git a/presentations/comprehensive/sic.tex 
b/presentations/comprehensive/sic.tex
index 165b993..b52a772 100644
--- a/presentations/comprehensive/sic.tex
+++ b/presentations/comprehensive/sic.tex
@@ -291,7 +291,8 @@ Taler is
     \item \emph{not} a long-term store of value
     \item \emph{not} a network or instance of a system
     \item \emph{not} decentralized
-    \item \emph{not} based on proof-of-work or proof-of-stake
+%    \item \emph{not} based on proof-of-work or proof-of-stake
+    \item combinable with a DLT back-end if requested
   \end{itemize}
 \end{frame}
 
@@ -300,7 +301,7 @@ Taler is
   \framesubtitle{https://taler.net/en/principles.html}
 GNU Taler must ...
 \begin{enumerate}
-  \item {... be implemented as {\bf free software}.}
+  \item {... be implemented as {\bf free software} (but {\em available} under 
a commercial license).}
   \item {... protect the {\bf privacy of buyers}.}
   \item {... must enable the state to {\bf tax income} and crack down on
     illegal business activities.}
@@ -310,7 +311,7 @@ GNU Taler must ...
   \item {... be usable.}
   \item {... be efficient.}
   \item {... avoid single points of failure.}
-  \item {... foster {\bf competition}.}
+  \item {... foster {\bf competition} in associated services.}
 \end{enumerate}
 \end{frame}
 
@@ -413,6 +414,19 @@ GNU Taler must ...
 \end{frame}
 
 
+\begin{frame}{Launch Timeline}
+  \begin{description}
+    \item[2022] Internal deployment at BFH
+    \item[Q1'2023] Deployment using Bitcoin at BFH (running, but not yet 
announced)
+    \item[Q2'2023] Internal deployment in Basel by \url{https://netzbon.ch/}
+    \item[Q3'2023] Public deployment in Basel by \url{https://netzbon.ch/}
+    \item[Q4'2023] Public deployment in Switzerland by Taler Operations AG
+    \item[2024] German bank executes ``new product process'' for launch in 
Eurozone
+  \end{description}
+\end{frame}
+
+
+
 \section{Component Zoo}
 
 \begin{frame}
@@ -456,16 +470,16 @@ GNU Taler must ...
   The {\bf Exchange} is the core logic of the payment system.
 
   \begin{itemize}
-    \item One exchange must be operated per currency
+    \item One exchange at minimum must be operated per currency
     \item Offers a REST API for merchants and customers
     \item Uses several helper processes for configuration and to
           interact with RTGS and cryptography
     \item KYC support via OAuth 2.0, KycAID or Persona APIs
     \item Implemented in C on top of GNU libmicrohttpd
   \end{itemize}
-  Scalability: 28'500 transactions/second measured in BS-thesis
+  Scalability: 28'500 transactions/second measured % in BS-thesis
   in 2022 using two servers on Grid5000. Likely several times
-  higher today (but we did not measure recently).
+  higher today (but we did not re-measure recently).
 \end{frame}
 
 
@@ -601,11 +615,11 @@ GNU Taler must ...
 
   \begin{itemize}
     \item LibEuFin provides both a generic access layer and an
-      implementation of the Taler Wire Gateway API for the exchange
-    \item currently, only EBICS 2.5 is supported
+      implementation of the Wire Gateway for the exchange
+    \item Supports EBICS 2.5
     \item other APIs such as FinTS or PSD2-style XS2A APIs can be added
       without requiring changes to the Exchange
-    \item tested with a GLS business account
+    \item tested with German bank GLS business account and real Euros
   \end{itemize}
   \vfill
   \begin{itemize}
@@ -639,12 +653,14 @@ GNU Taler must ...
 
 
 \begin{frame}{Depoloymerization}
-  Depolymerization is a bridge between GNU Taler and blockchains.
+  Depolymerization is a bridge between GNU Taler and blockchains,
+  making Taler a layer 2 system for crypto-currencies (like Lightning).
 
   \begin{itemize}
-    \item Supports Bitcoin and Ethereum as the ``RTGS''
+    \item Currently implemented for Bitcoin and Ethereum
+          crypto-currencies, with the DLTs as the ``RTGS''
     \item Provides same API to Exchange as LibEuFin
-    \item Transaction rate and speed limited by the underlying blockchain
+%   \item Transaction rate and speed limited by the underlying blockchain
     \item Implemented in Rust
   \end{itemize}
   \begin{center}
@@ -653,6 +669,23 @@ GNU Taler must ...
 \end{frame}
 
 
+\begin{frame}{TalDir (WiP)}
+  TalDir is an extension to the existing
+  peer-to-peer payment functionality.
+
+  \begin{itemize}
+    \item Registry to associate wallets with network addresses
+    \item Extensible to different types of network services:
+      \begin{itemize}
+    \item E-mail
+    \item SMS
+    \item Twitter
+    \item ...
+     \end{itemize}
+    \item Send payments or invoices to wallets associated with network address
+    \item Will {\bf not} require sending wallet to use same network service
+  \end{itemize}
+\end{frame}
 
 
 \section{Basic Cryptography}
@@ -669,7 +702,7 @@ GNU Taler must ...
 
 
 \begin{frame}{How does it work?}
-We use a few ancient constructions:
+We use a few well established and tested constructions:
   \begin{itemize}
   \item Cryptographic hash function (1989)
   \item Blind signature (1983)
@@ -963,7 +996,7 @@ But of course we use modern instantiations.
   \vfill
   \pause
   \begin{center}
-  {\bf Taler is an online payment system.}
+  {\bf This step requires communication with the exchange.}
   \end{center}
   \vfill
 \end{frame}
@@ -1389,12 +1422,18 @@ But of course we use modern instantiations.
 \end{frame}
 
 
-\section{Age restrictions}
+\section{Illustration of Programmable Money: Age Restrictions}
 
 \begin{frame}
   \vfill
   \begin{center}
-    {\bf Part V: Age restrictions}
+    \vfill
+    {\bf Part V:}
+    \vfill
+    {\bf Illustration of Programmable Money}
+    \vfill
+    {\bf Zero-knowledge Age Restrictions}
+    \vfill
   \end{center}
   \vfill
 \end{frame}
@@ -2315,6 +2354,10 @@ The exchange needs the database to detect double 
spending.
       should be sufficient.  This copy can also serve as an
       additional (off-site?) backup.
 \end{itemize}
+\begin{center}
+  The database can also be replaced with a DLT if customer
+  insists on it.
+\end{center}
 \end{frame}
 
 
@@ -2506,19 +2549,22 @@ The exchange needs the database to detect double 
spending.
 \end{frame}
 
 
-
-\begin{frame}{Offline Payments}
-\framesubtitle{\url{https://taler.net/papers/euro-bearer-online-2021.pdf}}
-\begin{itemize}
-    \item Offline capabilities are sometimes cited as a requirement for 
digital payment solutions
-    \item All implementations must either use restrictive hardware elements 
and/or introduce
-      counterparty risk.
-    \item[$\Rightarrow$] Permanent offline features weaken a digital payment 
solution (privacy, security)
-    \item[$\Rightarrow$] Introduces unwarranted competition for physical cash 
(endangers emergency-preparedness).
-\end{itemize}
+\begin{frame}{Fully Offline Payments {\bf (WiP)}}
+\framesubtitle{\url{https://docs.taler.net/design-documents/030-offline-payments.html}}
+Offline capabilities are sometimes desired for digital payment solutions.
+\vfill
+\noindent
+Three possible approaches:
+\begin{enumerate}
+  \item Trust-based offline payments (has counterparty and/or privacy risks)
+  \item Full HSM Taler wallet (has hardware costs)
+  \item Light-weight HSM balance register
+\end{enumerate}
+\vfill
 \end{frame}
 
-\begin{frame}{Offline Payments with GNU Taler}
+
+\begin{frame}{Partially Offline Payments with GNU Taler}
 We have filed for a patent to address situations where only the merchant is 
offline:
 \begin{enumerate}
   \item Customer pays by scanning static QR code and entering amount on mobile 
phone.
@@ -2527,9 +2573,8 @@ We have filed for a patent to address situations where 
only the merchant is offl
 \begin{center}
 {\bf Point-of-sale needs only $\approx$ \EUR{10} COSTS hardware.}
 \end{center}
-\vfill
-{\small 
\url{https://docs.taler.net/design-documents/030-offline-payments.html} 
specifies
-additional options for offline payments where both parties are offline.}
+\vfill \pause
+Largely implemented, only UI support missing. Expected to ship in Q1'2023.
 \end{frame}
 
 
@@ -2611,7 +2656,7 @@ additional options for offline payments where both 
parties are offline.}
         \column{0.47\paperwidth}
         \begin{block}{Settlement layer}
             \begin{itemize}
-                \item This work, Blockchain!
+                \item RTGS $\equiv$ Blockchain!
             \end{itemize}
         \end{block}
         \begin{block}{Taler payment system}
@@ -3061,9 +3106,7 @@ Future work:
   \item[{\bf Fakebank:}] high-performance in-memory RTGS emulator
   \item[{\bf libbrandt:}] Escrow-based programmability extensions (e.g. for 
auctions)
   \item[{\bf twister}:] Man-in-the-middle fault-injection for testing
-  \item[{\bf mch}:] Taler for embedded devices ({\bf WIP})
-  \item[{\bf taldir}:] Wallet address resolution for P2P payments ({\bf WIP})
-  \item[{\bf mailbox}:] Send messages to Taler wallets for P2P payments ({\bf 
WIP})
+  \item[{\bf mch}:] Taler for embedded devices ({\bf WiP})
   \end{description}
 \end{frame}
 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]