commit 52b51d371bfa485961454c22c1d925185ab735dc
parent 96a22e685eb29c0d43b46f05c64744cc97c6009a
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Tue, 7 Mar 2023 12:54:46 +0100
cut
Diffstat:
1 file changed, 5 insertions(+), 731 deletions(-)
diff --git a/presentations/comprehensive/sbb.tex b/presentations/comprehensive/sbb.tex
@@ -234,7 +234,7 @@
\begin{textblock*}{8cm}(4.7cm,6.7cm) % {block width} (coords)
{\hfill {{\bf Dr. Emmanuel Benoist} \\
\hfill {\bf Dr. Florian Dold} \\
- \hfill {\bf Dr. Andreas Habegger} \\
+ \hfill {\bf Prof. Andreas Habegger} \\
\hfill {\bf Dr. Christian Grothoff} \\ }
\hfill \{benoist,dold,habegger,grothoff\}@taler.net }
\end{textblock*}
@@ -1440,7 +1440,7 @@ But of course we use modern instantiations.
\end{frame}
-\begin{frame}{Refresh protocol properties}
+\begin{frame}<1-| handout:0>{Refresh protocol properties}
\begin{itemize}
\item Customer asks exchange to convert old coin to new coin
\item Protocol ensures new coins can be recovered from old coin
@@ -2212,202 +2212,12 @@ Searching for functions \uncover<2->{with the following signatures}
\end{frame}
-\section{Measures against Advanced Attacks}
-
-\begin{frame}
- \vfill
- \begin{center}
- {\bf Part VI: Measures against Advanced Attacks}
- \end{center}
- \vfill
-\end{frame}
-
-
-\begin{frame}{Warranting deposit safety}
- Exchange has 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, a malicious 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}{Key management}
-Taler has many types of keys:
-\begin{itemize}
-\item Coin keys
-\item Denomination keys
-\item Online message signing keys
-\item Offline key signing keys
-\item Merchant keys
-\item Auditor key
-\item Security module keys
-\item Transfer keys
-\item Wallet keys
-\item {\em TLS keys, DNSSEC keys}
-\end{itemize}
-\end{frame}
-
-
-\begin{frame}{Offline keys}
-Both exchange and auditor use offline keys.
-\begin{itemize}
-\item Those keys must be backed up and remain highly confidential!
-\item We recommend that computers that have ever had access to those
- keys to NEVER again go online.
-\item We recommend using a Raspberry Pi for offline key operations.
- Store it in a safe under multiple locks and keys.
-\item Apply full-disk encryption on offline-key signing systems.
-\item Have 3--5 full-disk backups of offline-key signing systems.
-\end{itemize}
-\begin{center}
-\includegraphics[scale=0.1]{pi.png}
-\end{center}
-\end{frame}
-
-
-\begin{frame}{Protecting online keys}
-The exchange needs keys to be available for online signing.
-\begin{itemize}
-\item {\tt taler-exchange-secmod-\{cs,eddsa,rsa\}}
- are the only processes that must have access to the private keys.
-\item The secmod processes should run under a different UID, but share
- the same GID with the exchange.
-\item The secmods generate the keys, allow {\tt taler-exchange-httpd} to sign with
- them, and eventually delete the private keys.
-\item Communication between secmods and {\tt taler-exchange-httpd} is via
- a UNIX domain socket.
-\item Online private keys are stored on disk (not in database!) and should
- NOT be backed up (RAID should suffice). If disk is lost, we can always
- create fresh replacement keys!
-\end{itemize}
-\end{frame}
-
-
-\begin{frame}{Online keys}
-\begin{center}
-\includegraphics[width=0.9\textwidth]{taler-diagram-signatures.png}
-\end{center}
-\end{frame}
-
-\begin{frame}{Online keys}
-The exchange needs keys to be available for online signing:
-\begin{itemize}
-\item Knowledge of these private keys will allow an adversary to
- mint digital cash, possibly resulting in financial losses
-% (eventually, this will be detected by the auditor, but only
-% after some financial losses have been irrevocably incurred).
-\item The corresponding public keys are certified using
- Taler's public key infrastructure (which uses offline-only keys).
-\end{itemize}
-\vfill
-{\tt taler-exchange-offline} can also be used to {\bf revoke} the
-online signing keys, if we find they have been compromised.
-\vfill
-\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}
-\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 a malicious 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}
-
-
-\begin{frame}{Database}
-The exchange needs the database to detect double spending.
-\begin{itemize}
-\item Loss of the database will allow technically skilled people
- to double-spend their digital cash, possibly resulting in
- significant financial losses.
-\item The database contains total amounts customers withdrew and
- merchants received, so sensitive private banking data. It
- must thus not become public.
-\item The auditor must have a (current) copy. Asynchronous replication
- 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
- requires it.
-\end{center}
-\end{frame}
-
-
\section{Component Architecture}
\begin{frame}
\vfill
\begin{center}
- {\bf Part VII: Component Architecture}
+ {\bf Part VI: Component Architecture}
\end{center}
\vfill
\end{frame}
@@ -2556,7 +2366,7 @@ backend,draw]{\tiny Backoffice};
\begin{frame}
\vfill
\begin{center}
- {\bf Part VIII: Integration considerations}
+ {\bf Part VII: Integration considerations}
\end{center}
\vfill
\end{frame}
@@ -2626,535 +2436,12 @@ Largely implemented, only UI support missing. Expected to ship in Q1'2023.
\end{frame}
-\section{Blockchain Integration}
-
-\begin{frame}
- \vfill
- \begin{center}
- {\bf Part IX: Blockchain Integration}
- \end{center}
- \vfill
- Antoine d’Aligny, Emmanuel Benoist and Christian Grothoff: ``{\em Project Depolymerization: Tokenization of Blockchains}''. {\bf 4th Conference on Blockchain Research \& Applications for Innovative Networks and Services}, 2022
- \vfill
-\end{frame}
-
-
-\begin{frame}{Blockchain based cryptocurrencies}
- \begin{tikzpicture}[remember picture,overlay]
- \node (N1)[above right=5mm and 25mm of current page.center] {\includegraphics[width=34mm]{media/news1.png}};
- \node (N0)[below=-3mm of N1] {\includegraphics[width=34mm]{media/news0.png}};
- \node (N2)[below left=-26mm and -2.5mm of N1] {\includegraphics[width=34mm]{media/news2.png}};
- \end{tikzpicture}
- \begin{block}{Biggest cryptocurrencies}
- \begin{itemize}
- \item \textbf{BTC} Bitcoin
- \item \textbf{ETH} Ethereum
- \end{itemize}
- \end{block}
- \begin{block}{Common blockchain limitations}
- \begin{itemize}
- \item \textbf{Delay} block and confirmation delay
- \item \textbf{Cost} transaction fees
- \item \textbf{Scalability} limited amount of transaction per second
- \item \textbf{Ecological impact} computation redundancy
- \item \textbf{Privacy}
- \item \textbf{Regulatory risk}
- \end{itemize}
- \end{block}
-\end{frame}
-
-\begin{frame}{Layer 2 solutions: Taler vs. Lightning}
-
-\begin{minipage}{5.5cm}
-{\bf Taler:}
-\begin{itemize}
-\item[\checkmark] can be used with any currency or asset
-\item[\checkmark] can make payments instantly between any two parties
-\item[\checkmark] has income transparency and can accommodate KYC, AML and CFT
-\item[\checkmark] has cryptographic privacy protections
-\item[\checkmark] can be used immediately to make instant payments
-\item[\checkmark] uses one or more central exchange service providers
-\end{itemize}
-\end{minipage}
-\hfill
-\begin{minipage}{5.5cm}
-{\bf Lightning:}
-\begin{itemize}
-\item[$\times$] only works with Bitcoin
-\item[$\times$] requires payment route establishment, which can fail
-\item[$\times$] cannot enforce regulatory requirements
-\item[$\times$] requires money to be locked in payment channels
-\item[$\times$] requires expensive Bitcoin node or trusted service to transact
-\item[$\times$] claims to be decentralized, but uses few and centralized nodes in practice
-\end{itemize}
-\end{minipage}
-\end{frame}
-
-\begin{frame}<1-| handout:0>{Taler}{Architecture}
- \begin{columns}
- \column{0.5\paperwidth}
- \begin{tikzpicture}[
- rect/.style={circle, draw=black},
- sym/.style={-stealth, shorten >= 2pt, shorten <= 2pt}
- ]
- % Taler payment system
- \node[rect](1) {Exchange};
- \node[rect,below left=1.5cm and 0.7cm of 1](2) {Customer};
- \node[rect,below right=1.5cm and 0.7cm of 1](3) {Merchant};
-
- \draw[sym] (1) -- node [midway, above, sloped] {\tiny Withdraw coins} (2);
- \draw[sym] (2) -- node [midway, above, sloped] {\tiny Spend coins} (3);
- \draw[sym] (3) -- node [midway, above, sloped] {\tiny Deposit coins} (1);
-
- % Settlement layer
- \node[left=2cm of 1](E1){};
- \node[right=2cm of 1](E2){};
- \draw[sym] (E1) -- node [midway, above] {\tiny Deposit money} (1);
- \draw[sym] (1) -- node [midway, above] {\tiny Withdraw money} (E2);
-
- % Auditor
- \node[above= of 1](A){Auditor};
- \draw[sym] (A) -- node [midway, right] {\tiny Verify} (1);
-
- % Separator
- \node[below=1mm of E1] (S1S) {};
- \node[below=1mm of E2] (S1E) {};
- \node[above=6mm of E1] (S2S) {};
- \node[above=6mm of E2] (S2E) {};
-
- \draw[dotted] (S1S) -- (S1E);
- \draw[dotted] (S2S) -- (S2E);
-
- \node[below right=-2mm and -1.5mm of S2S] {\tiny{\emph{Settlement Layer}}};
- \node[below right=-2mm and -1.5mm of S1S] {\tiny{\emph{Taler payment system}}};
- \end{tikzpicture}
- \column{0.47\paperwidth}
- \begin{block}{Settlement layer}
- \begin{itemize}
- \item RTGS $\equiv$ Blockchain!
- \end{itemize}
- \end{block}
- \begin{block}{Taler payment system}
- \begin{itemize}
- \item Realtime transactions, 1 RTT
- \item Scalable microtransactions
- \item Blind signatures (privacy)
- \end{itemize}
- \end{block}
-
- \end{columns}
-\end{frame}
-
-\begin{frame}{Taler}{Blockchain settlement layer}
- \begin{center}
- \begin{tikzpicture}[
- rect/.style={rectangle, draw=black, minimum width=30mm},
- sym/.style={stealth-stealth, shorten >= 2pt, shorten <= 2pt},
- block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
- ]
-
- %% Architecture
- \node(Tt){Taler};
- \node[rect,below=0cm of Tt](Tc){Exchange};
- \node[rect,fit={(Tt) (Tc)}](T){};
-
- \node[rect,below=7mm of Tc](D) {\textbf{Depolymerization}};
-
- \node[rect,below=7mm of D](Bc){Node};
- \node[below=0cm of Bc](Bt){Blockchain};
- \node[rect,fit={(Bt) (Bc)}](B){};
-
- \draw[sym] (T) -- (D);
- \draw[sym] (D) -- (B);
-
- %% Blockchain
- \node[block,right=8mm of B] (1){};
- \node[block,right=4mm of 1] (2){};
- \node[block,right=4mm of 2] (3){};
- \node[block,right=4mm of 3] (4){};
- \node[block,right=4mm of 4] (5){};
- \node[block,right=4mm of 5] (6){};
- \draw[-stealth] (1) -- (2);
- \draw[-stealth] (2) -- (3);
- \draw[-stealth] (3) -- (4);
- \draw[-stealth] (4) -- (5);
- \draw[-stealth] (5) -- (6);
-
- \node[left=4mm of 1] (S){};
- \node[right=4mm of 6] (E){};
- \draw[-stealth] (S) -- (1);
- \draw[-stealth] (6) -- (E);
-
- %% Taler
- \node[block, below right=-7.5mm and 20.5mm of T] (off){Off-chain transactions};
- \node[above=-0.5mm of off] {\includegraphics[height=7mm]{taler-logo-2021-inkscape.pdf}};
-
- %% Depolymerization
- \node[right=11mm of D] {\small{Credit}};
- \node[right=50mm of D] {\small{Debit}};
- \draw[dashed,-stealth] (1.north) |- (off.west);
- \draw[dashed,-stealth] (off.east) -| (6.north);
- \end{tikzpicture}
- \end{center}
-\end{frame}
-
-\begin{frame}<1-| handout:0>{Challenges}
- \begin{block}{Taler Metadata}
- \begin{itemize}
- \item Metadata are required to link a wallet to credits and
- allow merchant to link deposits to debits
- \item Putting metadata in blockchain transactions can be tricky
- \end{itemize}
- \end{block}
- \begin{block}{Blockchain based cryptocurrencies}
- \begin{itemize}
- \item Blockchain transactions lack finality (fork)
- \item Transactions can be stuck for a long time (mempool)
- \end{itemize}
- \end{block}
-\end{frame}
-
-\begin{frame}<1-| handout:0>{Blockchain challenges}{Chain reorganization}
- \begin{center}
- \begin{tikzpicture}[
- block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
- ar/.style={-stealth}
- ]
- % Common
- \node[block](1){};
- \node[block,right=5mm of 1](2){$D_0$};
- \node[block,right=5mm of 2](3){};
- \draw[ar] (1) -- (2);
- \draw[ar] (2) -- (3);
-
- % Current
- \node [block,right=5mm of 3](4){};
- \node[block,right=5mm of 4](5){};
- \node[block,right=5mm of 5](6){$D_1$};
- \draw[ar] (3) -- (4);
- \draw[ar] (4) -- (5);
- \draw[ar] (5) -- (6);
-
- % Fork
- \node [block,above=7mm of 4](4p){};
- \node[block,right=5mm of 4p](5p){$D_2$};
- \node[block,right=5mm of 5p](6p){};
- \node[block,right=5mm of 6p](7p){};
- \draw[ar] (3.east) -- (4p.west);
- \draw[ar] (4p) -- (5p);
- \draw[ar] (5p) -- (6p);
- \draw[ar] (6p) -- (7p);
-
- % Indication
- \node [right=5mm of 7p]{\emph{fork}};
- \node [right=17mm of 6]{\emph{active}};
- \end{tikzpicture}
- \end{center}
- A fork is when concurrent blockchain states coexist. Nodes will follow
- the longest chain, replacing recent blocks if necessary during a
- blockchain reorganization. If a deposit transaction disappears from the
- blockchain, an irrevocable withdraw transactions would no longer be backed
- by credit.
-\end{frame}
-
-\begin{frame}<1-| handout:0>{Blockchain challenges}{Stuck transactions}
- We want confirmed debits within a limited time frame.
- \begin{figure}
- \centering
- \only<1> {
- \begin{tikzpicture}[
- dot/.style={circle,fill,inner sep=1pt,}
- ]
- \node (I) {\includegraphics[width=\textwidth]{media/fee.png}};
- \node [below left=-2.5mm and -1.5cm of I] (Tx) {\small Tx};
- \node [dot,above=8.4mm of Tx](D) {};
- \draw [dotted,thick] (Tx) -- (D);
- \node [left=-4.5cm of Tx] (C) {\small conf};
- \node [dot,above=8.4mm of C](D1) {};
- \draw [dotted,thick] (C) -- (D1);
- \end{tikzpicture}
- }
- \only<2> {
- \includegraphics[width=\textwidth]{media/fee_var.png}
- \caption{Bitcoin average transaction fee over 6 months {\tiny (ychart)}}
- }
- \end{figure}
- \only<1>{When we trigger a debit with a fee too small, it may not be
- confirmed in a timely fashion.}
- \only<2>{However, transaction fees are unpredictable.}
-\end{frame}
-
-
-\begin{frame}{Depolymerization}{Architecture}
- \begin{center}
- \begin{tikzpicture}[
- rect/.style={rectangle, draw=black, minimum height=6mm, minimum width=28mm},
- sym/.style={stealth-stealth, shorten >= 2pt, shorten <= 2pt}
- ]
- \node[rect](1) {Taler Exchange};
- \node[rect,below=of 1](2) {Wire Gateway};
- \node[rect,right=of 2](3) {PostgreSQL};
- \node[rect,right=of 3](4) {DLT Adapter};
- \node[rect,above=of 4](5) {DLT Full Node};
-
- \draw[sym] (1) -- node [midway,right] {\tiny HTTP} (2);
- \draw[sym] (2) -- node [midway,above] {\tiny SQL} (3);
- \draw[sym] (3) -- node [midway,above] {\tiny SQL} (4);
- \draw[sym] (4) -- node [midway,left ] {\tiny RPC} (5);
-
-
- \node[above= 2mm of 1]{\small{\emph{Wire Gateway API}}};
- \node[above= 2mm of 5]{\small{\emph{DLT specific}}};
- \node[above=22mm of 3](T) {};
- \draw[dotted] (3) -- (T);
- \end{tikzpicture}
- \end{center}
- \begin{itemize}
- \item Common database to store transactions state and communicate
- with notifications
- \item Wire Gateway for Taler API compatibility
- \item DLT specific adapter
- \end{itemize}
-\end{frame}
-
-\begin{frame}{Storing metadata}{Bitcoin}
- \begin{block}{Bitcoin - Credit}
- \begin{itemize}
- \item Transactions from code
- \item Only 32B + URI
- \item \textbf{OP\_RETURN}
- \end{itemize}
- \end{block}
- \begin{block}{Bitcoin - Debit}
- \begin{itemize}
- \item Transactions from common wallet software
- \item Only 32B
- \item \textbf{Fake Segwit Addresses}
- \end{itemize}
- \end{block}
-\end{frame}
-\begin{frame}{Storing metadata}{Ethereum}
- \begin{block}{Smart contracts}
- \begin{itemize}
- \item Logs in smart contract is the recommend way {\tiny (ethereum.org)}
- \item Expensive (additional storage and execution fees)
- \item Avoidable attack surface (error prone)
- \end{itemize}
- \end{block}
- \begin{block}{Custom input format}
- Use input data in transactions, usually used to call smart contract, to
- store our metadata.
- \end{block}
-\end{frame}
-
-\begin{frame}{Handling blockchain reorganization}
- \begin{center}
- \begin{tikzpicture}[
- block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
- conf/.style={draw=black!60!green,fill=black!60!green!10},
- nconf/.style={dotted},
- err/.style={draw=black!60!red,fill=black!60!red!10},
- ar/.style={-stealth}
- ]
- % Common
- \node[block,conf](1){};
- \node[block,conf,right=5mm of 1](2){$D_0$};
- \node[block,conf,right=5mm of 2](3){};
- \draw[ar] (1) -- (2);
- \draw[ar] (2) -- (3);
-
- % Current
- \only<1>{
- \node [block,nconf,right=5mm of 3](4){};
- }
- \only<2->{
- \node [block,conf,right=5mm of 3](4){\only<3>{$D_3$}};
- }
- \node[block,nconf,right=5mm of 4](5){};
- \node[block,nconf,right=5mm of 5](6){$D_1$};
- \draw[ar] (3) -- (4);
- \draw[ar] (4) -- (5);
- \draw[ar] (5) -- (6);
-
- % Fork
- \only<-2>{
- \node [block,nconf,above=7mm of 4](4p){};
- }
- \only<3>{
- \node [block,dashed,err,above=7mm of 4](4p){$D_3'$};
- }
- \node[block,nconf,right=5mm of 4p](5p){$D_2$};
- \node[block,nconf,right=5mm of 5p](6p){};
- \node[block,nconf,right=5mm of 6p](7p){};
- \draw[ar] (3.east) -- (4p.west);
- \draw[ar] (4p) -- (5p);
- \draw[ar] (5p) -- (6p);
- \draw[ar] (6p) -- (7p);
-
- % Indication
- \node [right=5mm of 7p]{\emph{fork}};
- \node [right=17mm of 6]{\emph{active}};
- \end{tikzpicture}
- \end{center}
- \only<1>{As small reorganizations are common, Satoshi already recommended to
- apply a confirmation delay to handle most disturbances and attacks.}
- \only<2>{If a reorganization longer than the confirmation delay happens,
- but it did not remove credits, Depolymerizer is safe and automatically
- resumes.}
- \only<3>{If a fork removed a confirmed debit, an attacker may create a
- conflicting transaction. Depolymerizer suspends operation until lost
- credits reappear.}
-\end{frame}
-
-\begin{frame}{Adaptive confirmation}
- \begin{center}
- \begin{tikzpicture}[
- block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
- conf/.style={draw=black!60!green,fill=black!60!green!10},
- nconf/.style={dotted},
- conft/.style={text=black!60!green},
- confl/.style={draw=black!60!green},
- ar/.style={-stealth}
- ]
- % Common
- \node(0){};
- \node[block,conf,right=5mm of 0](1){};
- \node[block,conf,right=5mm of 1](2){};
- \draw[ar] (0) -- (1);
- \draw[ar] (1) -- (2);
-
- % Current
- \node[block,conf,right=5mm of 2](3){};
- \node[block,nconf,right=5mm of 3](4){};
- \node[block,nconf,right=5mm of 4](5){};
- \node[block,nconf,right=5mm of 5](6){};
- \draw[ar] (2) -- (3);
- \draw[ar] (3) -- (4);
- \draw[ar] (4) -- (5);
- \draw[ar] (5) -- (6);
-
- % Fork
- \node[block,nconf,above=7mm of 3](3p){};
- \node[block,nconf,right=5mm of 3p](4p){};
- \node[block,nconf,right=5mm of 4p](5p){};
- \node[block,nconf,right=5mm of 5p](6p){};
- \node[block,nconf,right=5mm of 6p](7p){};
- \draw[ar] (2.east) -- (3p.west);
- \draw[ar] (3p) -- (4p);
- \draw[ar] (4p) -- (5p);
- \draw[ar] (5p) -- (6p);
- \draw[ar] (6p) -- (7p);
-
- % Indication
- \node[right=5mm of 7p]{\emph{fork}};
- \node[right=17mm of 6]{\emph{active}};
-
- % Confirmation
- \path (0) -- (1) node[conft,midway, below=6mm] (M) {Max};
- \path (2) -- (3) node[conft,midway, below=6mm] (N) {New};
- \path (3) -- (4) node[conft,midway, below=6mm] (I) {Initial};
- \node[above=25mm of M] (Mp) {};
- \node[above=25mm of N] (Np) {};
- \node[above=25mm of I] (Ip) {};
- \draw[confl,thick,dotted](M) -- (Mp);
- \draw[confl](N) -- (Np);
- \draw[confl,thick,dotted](I) -- (Ip);
- \end{tikzpicture}
- \end{center}
- If we experience a reorganization once, its likely for another
- reorganization of a similar scope to happen again.
- Depolymerizer learns from reorganizations by increasing its confirmation delay.
-\end{frame}
-
-
-
-\begin{frame}<1-| handout:0>{DLT Adapter}{Architecture}
- \begin{block}{Event system}
- \begin{itemize}
- \item \textbf{Watcher} watch and notify for new blocks with credits
- \item \textbf{Wire Gateway} notify requested debits
- \item \textbf{Worker} operates on notifications updating state
- \end{itemize}
- \end{block}
-\end{frame}
-
-
-\begin{frame}<1-| handout:0>{DLT Adapter state machine}
- \begin{columns}
- \column{0.5\paperwidth}
- \begin{figure}
- \begin{tikzpicture}[
- rect/.style={rectangle, draw=black, minimum height=6mm, minimum width=50mm},
- ]
-
- \node[rect](wo1) {Wait for notifications};
- \node[rect, below=4mm of wo1](wo2) {Reconcile local DB with DLT};
- \node[rect, below=4mm of wo2](wo3) {Trigger debits};
- \node[rect, below=4mm of wo3](wo4) {Reissue stuck debits};
- \node[rect, below=4mm of wo4](wo5) {Bounce malformed credits};
- \draw[-stealth] (wo1) -- (wo2);
- \draw[-stealth] (wo2) -- (wo3);
- \draw[-stealth] (wo3) -- (wo4);
- \draw[-stealth] (wo4) -- (wo5);
- \draw[-stealth] (wo5) .. controls ([xshift=-0.4cm] wo5.west) and ([xshift=-0.4cm] wo1.west) .. (wo1);
- \end{tikzpicture}
- \caption{Worker loop}
- \end{figure}
- \column{0.47\paperwidth}
- \begin{block}{DLT reconcialisation}
- \begin{itemize}
- \item List new and removed transactions since last reconciliation
- \item Check for confirmed credits removal
- \item Register new credits
- \item Recover lost debits
- \end{itemize}
- \end{block}
- \end{columns}
-\end{frame}
-
-\begin{frame}<1-| handout:0>{Related work}
- \begin{block}{Centralization - Coinbase off-chain sending}
- \begin{itemize}
- \item [$+$] Fast and cheap: off chain transaction
- \item [$-$] Trust in Coinbase: privacy, security \& transparency
- \end{itemize}
- \end{block}
- \begin{block}{Layering - Lightning Network}
- \begin{itemize}
- \item [$+$] Fast and cheap: off-chain transactions
- \item [$-$] Requires setting up bidirectional payment channels
- \item [$-$] Fraud attempts are mitigated via a complex penalty system
- \end{itemize}
- \end{block}
-\end{frame}
-
-\begin{frame}{Project Depolymerization Summary}
- Taler can be used as a layer 2 for existing
- crypto-currencies and stablecoins with Depolymerizer:
-
- \begin{itemize}
- \item [$-$] Trust exchange operator or auditors
- \item [$+$] Fast and cheap
- \item [$+$] Realtime: transactions with milliseconds of latency
- \item [$+$] Linear scalability
- \item [$+$] Ecological
- \item [$+$] Privacy when it can, transparency when it must (avoid tax evasion and money laundering)
- \end{itemize}
-%Future work:
-% \begin{itemize}
-% \item Universal auditability, using sharded transactions history
-% \item Smarter analysis, update confirmation delay based on currency network behavior
-% \item Multisig by multiple operator for transactions validation
-% \end{itemize}
-\end{frame}
-
-
\section{Conclusion}
\begin{frame}
\vfill
\begin{center}
- {\bf Part X: Conclusion}
+ {\bf Part VIII: Conclusion}
\end{center}
\vfill
\end{frame}
@@ -3253,19 +2540,6 @@ Largely implemented, only UI support missing. Expected to ship in Q1'2023.
\end{frame}
-\begin{frame}{Rights}
- \begin{itemize}
- \item GNUnet e.V. shared copyrights of their AGPLv3+ licensed code with Taler Systems SA
- \item Taler Systems SA holds copyrights to entire GNU Taler code base (AGPLv3+, GPLv3+,
- dual-licensing exclusive domain of Taler Systems SA)
- \item Taler Systems SA applied for patent on offline payment solution
- \item Taler Systems SA holds trademark on ``Taler''.
- \item FSF holds trademark on ``GNU'', we are authorized to use ``GNU Taler''.
- \item Taler Systems SA owns {\tt taler.net} and {\tt taler-systems.com}.
- \end{itemize}
-\end{frame}
-
-
\begin{frame}{Summary of Taler Solution}
\begin{enumerate}
