[taler-marketing] branch master updated: NYC update

[gnunet]

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 75804f8  NYC update
75804f8 is described below

commit 75804f8bceb7249f7b6b1c7248f7f90e721d1c57
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Tue May 18 17:00:53 2021 +0200

    NYC update
---
 presentations/comprehensive/nyc.tex | 201 ++++++++++++++++--------------------
 1 file changed, 89 insertions(+), 112 deletions(-)

diff --git a/presentations/comprehensive/nyc.tex 
b/presentations/comprehensive/nyc.tex
index 3f671f0..6a36176 100644
--- a/presentations/comprehensive/nyc.tex
+++ b/presentations/comprehensive/nyc.tex
@@ -612,12 +612,6 @@ But of course we use modern instantiations.
   \end{minipage}
 \end{frame}
 
-\begin{frame}{Withdrawing coins on the Web}
-  \begin{center}
-    \includegraphics[height=0.9\textheight]{figs/taler-withdraw.pdf}
-  \end{center}
-\end{frame}
-
 
 \begin{frame}{Customer: Build shopping cart}
   \begin{center}
@@ -654,18 +648,6 @@ But of course we use modern instantiations.
 \end{frame}
 
 
-\begin{frame}{Merchant Integration: Contract}
-  % \begin{figure*}[t!]
-  {\tiny
- \lstset{language=JavaScript}
- \lstinputlisting{figs/taler-contract.json}
-%   \caption{Minimal Taler contract over a digital article with a value of 
\EUR{0.10}. The merchant will pay transaction fees up to \EUR{0.01}.  The hash 
over the wire transfer information was truncated to make it fit to the page.}
-%   \label{listing:json-contract}
- % \end{figure*}
- }
-\end{frame}
-
-
 \begin{frame}{Merchant: Propose contract (EdDSA)}
    \begin{minipage}{6cm}
    \begin{enumerate}
@@ -762,13 +744,6 @@ But of course we use modern instantiations.
 \end{frame}
 
 
-\begin{frame}{Payment processing with Taler}
-  \begin{center}
-    \includegraphics[height=0.9\textheight]{figs/taler-pay.pdf}
-  \end{center}
-\end{frame}
-
-
 \begin{frame}{Giving change}
   It would be inefficient to pay EUR 100 with 1 cent coins!
   \begin{itemize}
@@ -1173,93 +1148,6 @@ But of course we use modern instantiations.
 
 
 
-\begin{frame}{Warranting deposit safety}
-  Exchange has {\em another} online signing key $W = wG$:
-  \begin{center}
-    Sends $EdDSA_w(M,H(D),FDH(C))$ to the merchant.
-  \end{center}
-  This signature means that $M$ was the {\em first} to deposit
-  $C$ and that the exchange thus must pay $M$.
-  \vfill
-  \begin{center}
-     Without this, an evil exchange could renege on the deposit
-     confirmation and claim double-spending if a coin were
-     deposited twice, and then not pay either merchant!
-  \end{center}
-\end{frame}
-
-
-\begin{frame}{Online keys}
-\begin{itemize}
-\item The exchange needs $d$ and $w$ to be available for online signing.
-\item The corresponding public keys $W$ and $(e,n)$ are certified using
-      Taler's public key infrastructure (which uses offline-only keys).
-\end{itemize}
-\begin{center}
-\includegraphics[width=0.5\textwidth]{taler-diagram-signatures.png}
-\end{center}
-\vfill
-\begin{center}
-{\bf What happens if those private keys are compromised?}
-\end{center}
-\vfill
-\end{frame}
-
-
-\begin{frame}{Denomination key $(e,n)$ compromise}
-\begin{itemize}
-\item An attacker who learns $d$ can sign an arbitrary number of illicit coins
-      into existence and deposit them.
-\item Auditor and exchange can detect this once the total number of deposits
-      (illicit and legitimate) exceeds the number of legitimate coins the
-      exchange created.
-\item At this point, $(e,n)$ is {\em revoked}.  Users of {\em unspent}
-      legitimate coins reveal $b$ from their withdrawal operation and
-      obtain a {\em refund}.
-\item The financial loss of the exchange is {\em bounded} by the number of
-      legitimate coins signed with $d$.
-\item[$\Rightarrow$] Taler frequently rotates denomination signing keys and
-      deletes $d$ after the signing period of the respective key expires.
-\end{itemize}
-\begin{center}
-\includegraphics[width=0.5\textwidth]{taler-diagram-denom-expiration.png}
-\end{center}
-\end{frame}
-
-
-\begin{frame}{Online signing key $W$ compromise}
-\begin{itemize}
-\item An attacker who learns $w$ can sign deposit confirmations.
-\item Attacker sets up two (or more) merchants and customer(s) which 
double-spend
-      legitimate coins at both merchants.
-\item The merchants only deposit each coin once at the exchange and get paid 
once.
-\item The attacker then uses $w$ to fake deposit confirmations for the 
double-spent
-      transactions.
-\item The attacker uses the faked deposit confirmations to complain to the 
auditor
-      that the exchange did not honor the (faked) deposit confirmations.
-\end{itemize}
-The auditor can then detect the double-spending, but cannot tell who is to 
blame,
-and (likely) would presume an evil exchange, forcing it to pay both merchants.
-\end{frame}
-
-
-\begin{frame}{Detecting online signing key $W$ compromise}
-\begin{itemize}
-\item Merchants are required to {\em probabilistically} report
-      signed deposit confirmations to the auditor.
-\item Auditor can thus detect exchanges not reporting signed
-      deposit confirmations.
-\item[$\Rightarrow$] Exchange can rekey if illicit key use is detected,
-      then only has to honor deposit confirmations it already provided
-      to the auditor {\em and} those without proof of double-spending
-      {\em and} those merchants reported to the auditor.
-\item[$\Rightarrow$] Merchants that do not participate in reporting
-      to the auditor risk their deposit permissions being voided in
-      cases of an exchange's private key being compromised.
-\end{itemize}
-\end{frame}
-
-
 
 
 \section{Competitor analysis}
@@ -1749,6 +1637,95 @@ General notions:
 
 
 
+\begin{frame}{Warranting deposit safety}
+  Exchange has {\em another} online signing key $W = wG$:
+  \begin{center}
+    Sends $EdDSA_w(M,H(D),FDH(C))$ to the merchant.
+  \end{center}
+  This signature means that $M$ was the {\em first} to deposit
+  $C$ and that the exchange thus must pay $M$.
+  \vfill
+  \begin{center}
+     Without this, an evil exchange could renege on the deposit
+     confirmation and claim double-spending if a coin were
+     deposited twice, and then not pay either merchant!
+  \end{center}
+\end{frame}
+
+
+\begin{frame}{Online keys}
+\begin{itemize}
+\item The exchange needs $d$ and $w$ to be available for online signing.
+\item The corresponding public keys $W$ and $(e,n)$ are certified using
+      Taler's public key infrastructure (which uses offline-only keys).
+\end{itemize}
+\begin{center}
+\includegraphics[width=0.5\textwidth]{taler-diagram-signatures.png}
+\end{center}
+\vfill
+\begin{center}
+{\bf What happens if those private keys are compromised?}
+\end{center}
+\vfill
+\end{frame}
+
+
+\begin{frame}{Denomination key $(e,n)$ compromise}
+\begin{itemize}
+\item An attacker who learns $d$ can sign an arbitrary number of illicit coins
+      into existence and deposit them.
+\item Auditor and exchange can detect this once the total number of deposits
+      (illicit and legitimate) exceeds the number of legitimate coins the
+      exchange created.
+\item At this point, $(e,n)$ is {\em revoked}.  Users of {\em unspent}
+      legitimate coins reveal $b$ from their withdrawal operation and
+      obtain a {\em refund}.
+\item The financial loss of the exchange is {\em bounded} by the number of
+      legitimate coins signed with $d$.
+\item[$\Rightarrow$] Taler frequently rotates denomination signing keys and
+      deletes $d$ after the signing period of the respective key expires.
+\end{itemize}
+\begin{center}
+\includegraphics[width=0.5\textwidth]{taler-diagram-denom-expiration.png}
+\end{center}
+\end{frame}
+
+
+\begin{frame}{Online signing key $W$ compromise}
+\begin{itemize}
+\item An attacker who learns $w$ can sign deposit confirmations.
+\item Attacker sets up two (or more) merchants and customer(s) which 
double-spend
+      legitimate coins at both merchants.
+\item The merchants only deposit each coin once at the exchange and get paid 
once.
+\item The attacker then uses $w$ to fake deposit confirmations for the 
double-spent
+      transactions.
+\item The attacker uses the faked deposit confirmations to complain to the 
auditor
+      that the exchange did not honor the (faked) deposit confirmations.
+\end{itemize}
+The auditor can then detect the double-spending, but cannot tell who is to 
blame,
+and (likely) would presume an evil exchange, forcing it to pay both merchants.
+\end{frame}
+
+
+\begin{frame}{Detecting online signing key $W$ compromise}
+\begin{itemize}
+\item Merchants are required to {\em probabilistically} report
+      signed deposit confirmations to the auditor.
+\item Auditor can thus detect exchanges not reporting signed
+      deposit confirmations.
+\item[$\Rightarrow$] Exchange can rekey if illicit key use is detected,
+      then only has to honor deposit confirmations it already provided
+      to the auditor {\em and} those without proof of double-spending
+      {\em and} those merchants reported to the auditor.
+\item[$\Rightarrow$] Merchants that do not participate in reporting
+      to the auditor risk their deposit permissions being voided in
+      cases of an exchange's private key being compromised.
+\end{itemize}
+\end{frame}
+
+
+
+
 \end{document}
 
 

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