\def\hs{\hspace{0.4 cm}}

\documentclass{beamer}

\usetheme{Warsaw}
\usecolortheme{beaver}
\setbeamertemplate{footline}[page number]
\beamertemplatenavigationsymbolsempty

\title{Using Chains for what They're Good For}
\author{Andrew Poelstra}
\institute{\texttt{usingchainsfor@wpsoftware.net}}
\date{Scaling Bitcoin, November 5, 2017}

\usepackage{amsfonts,amsmath,latexsym,color,epsfig,graphicx,multirow,rotating}

\begin{document}
\frame{ \maketitle }

\frame
{
  \frametitle{On-Chain Smart Contracting}
  \begin{itemize}
  \item Bitcoin (and Ethereum, etc.) uses a scripting language to describe smart
        contracts and enforce their execution.\\~\\
  \item These scripts must be downloaded, parsed, validated by all full nodes on
        the network. Can't be compressed or aggregated.\\~\\
  \item Valid execution can't be assured until the transaction is confirmed:
        unpredictable, long delays.
  \end{itemize}
}

\frame
{
  \frametitle{On-Chain Smart Contracting}
  \begin{itemize}
  \item Script verification rules must be agreed upon by all participants.\\~\\
  \item The details of the script are visible forever, compromising privacy and
        fungibility.\\~\\
  \item Miners can see contract contents before including them, and may not want
        to (potential legal liability, external incentives, etc.)
  \end{itemize}
}

\frame
{
  \frametitle{On-Chain Smart Contracting}
  \begin{itemize}
  \item Most contracts need only one thing from the blockchain: \textbf{an immutable ordering
        of commitments to prevent double-spending.}
  \end{itemize}
}

\frame
{
  \frametitle{Execution vs Verification}
  \begin{itemize}
  \item Blockchain validators must check whether scripts execute successfully.\\~\\
  \item This is strictly easier than actually executing the scripts (Post's Theorem).
        May be assisted by a witness.\\~\\
  \item In crypto, we talk about (zero-knowledge) arguments that some script returns
        \textrm{true}. May be assisted by a transcript.
  \end{itemize}
}

\frame
{
  \frametitle{Verifiability vs Public Verifiability}
  \begin{itemize}
  \item Blockchain verifiers must check that coins are only spent with correct
        authorization, and only once.\\~\\
  \item They don't necessarily need to know what ``correct authorization'' means,
        they just need to agree on it.\\~\\
  \item Consider moving coins to a multisig output, where multiple distrusting
        signers check external conditions before signing to move them to their
        final destinations (Gibson 2017).
  \end{itemize}
}

\frame
{
  \frametitle{Scriptless Scripts}
  \begin{itemize}
  \item Suppose these distrusting signers want to enforce conditions on each other:
        a ``smart contract''.\\~\\
  \item The script paradigm demands they reveal witnesses to their conditions on
        the public chain, along with their signature.\\~\\
  \item But \emph{what if the signature was the witness?} Then the blockchain would
        only need to check a multisignature, or should I say\ldots a scriptless
        script.
  \end{itemize}
}
% TODO past here

\frame
{
  \frametitle{Scriptless Scripts}
  \begin{itemize}
  \item Scriptless scripts: magicking digital signatures so that they can only
        be created by faithful execution of a smart contract.\\~\\
  \item Limited in power, but not nearly as much as you might expect.\\~\\
  \item Mimblewimble is a blockchain design that supports only scriptless scripts,
        and derives its privacy and scaling properties from this.
  \end{itemize}
}

\frame
{
  \frametitle{Schnorr multi-Signatures are Scriptless Scripts}
  \begin{itemize}
  \item By adding Schnorr signature keys, a new key is obtained which can only
        be signed with with the cooperation of all parties.\\~\\
  \item The parties must interact to sign: first they agree on the message and
        nonces, then they contribute to the signatures.\\~\\
  \item (Don't try this at home: some extra precautions are needed to prevent
        adversarial choice of keys.) 
  \end{itemize}
}

\frame
{
  \frametitle{Adaptor Signatures}
  \begin{itemize}
  \item Instead use another ephemeral keypair $(t, T)$ and treat $T$ as the
        ``hash'' of $t$.\\~\\
  \item When doing a multi-signature replace the old nonce $R$ with $R + T$,
        and now the signature $s$ must be replaced by $s + t$ to be valid.\\~\\
  \item Now the original $s$ is an ``adaptor signature''. Anyone with this can
        compute a valid signature from $t$ or vice-versa. They can verify
        that it is an adaptor signature for $T$, no trust needed.
  \end{itemize}
}

\frame
{
  \frametitle{Atomic (Cross-chain) Swaps}

  \begin{itemize}
  \item Parties Alice and Bob send coins on their respective
        chains to 2-of-2 outputs. Bob thinks of a keypair $(t, T)$ and gives $T$ to
        Alice.\\~\\
  \item Before Alice signs to give Bob his coins, she demands adaptor signatures with $T$
        from him for \emph{both} his signatures: the one taking his coins and the one giving
        her coins.\\~\\
  \item Now when Bob signs to take his coins, Alice learns $t$ from one adaptor signature,
        which she can combine with the other adaptor signature to take \emph{her} coins.
  \end{itemize}
}

\frame
{
  \frametitle{Basic Lightning}

  \begin{itemize}
  \item Suppose Alice is paying David through Bob and Carol. She produces an onion-routed
        path
        \[ \textnormal{Alice} \to \textnormal{Bob} \to \textnormal{Carol} \to \textnormal{David} \]
        and asks for public keys $B$, $C$ and $D$ from each participant.\\~\\
  \item She sends coins to a 2-of-2 between her and Bob. She asks Bob for an adaptor signature
        with $B + C + D$ before signing to send him the coins.\\~\\
  \item Similarly Bob sends coins to Carol, first demanding an adaptor signature with $C + D$
        from her. Carol sends to David, demanding an adaptor signature with $D$.
  \end{itemize}
}

\frame
{
  \frametitle{Features of Adaptor Signatures}
  \begin{itemize}
  \item Adaptor signatures work across blockchains, even if they use different EC groups,
        though this requires a bit more work.\\~\\
  \item After a signature hits the chain, anyone can make up a $(t, T)$ and
        compute a corresponding ``adaptor signature'' for it, so the scheme is deniable.
        It also does not link the signatures in any way.\\~\\
  \item Adaptor signatures are re-blindable, as we saw in the Lightning example. This
        is also deniable and unlinkable.
  \end{itemize}
}

\frame
{
  \frametitle{~}

  \begin{center}
  Thank You
  ~\\~\\
  Andrew Poelstra \texttt{<whattheyregoodfor@wpsoftware.net>}
  \end{center}
}

\end{document}