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

\documentclass{beamer}

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

\title{Scriptless Scripts}
\author{Andrew Poelstra}
\institute{Research Director, Blockstream\\\texttt{scriptless@wpsoftware.net}}
\date{May 18, 2018}

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

\begin{document}
\frame{ \maketitle }

\frame
{
  \frametitle{Mimblewimble and Scriptless Scripts}
  \begin{itemize}
  \item Mimblewimble, proposed in 2016 by Tom Elvis Jedusor\\~\\
  \item No scripts, only signatures.\\~\\
  \item ``What script support is possible? We would need to translate script operations into
  some sort of discrete logarithm information.''
  \end{itemize}
}

\frame
{
  \frametitle{Not Just Mimblewimble}
  \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 The details of the script are visible forever, compromising privacy and
        fungibility.\\~\\
  \item With scriptless scripts, the only visible things are public keys (i.e.
        uniformly random curvepoints) and digital signatures.\\~\\
  \end{itemize}
}

\frame
{
  \frametitle{Adaptor Signatures}
  \begin{itemize}
  \item In a Schnorr multisignature, parties first exchange ``public nonces'' then
        exchange ``partial signatures''.\\~\\
  \item Partial signatures are objects that, when added to other partial signatures,
        produce total signatures. This property is publicly verifiable.\\~\\
  \item You can also make objects that, when added to arbitrary-but-precommitted values,
        produce total or partial signatures. These are {\color{blue} adaptor signatures}.\\~\\
  \item With an adaptor signature, when you learn the partial signature you also learn
        the precommitted value, and vice-versa.
  \end{itemize}
}

% atomic swaps
% reblindability
% blind swaps
% ZKCPs
\frame
{
  \frametitle{Example: Atomic (Cross-chain) Swaps}

  \begin{itemize}
  \item Suppose Alice wants to trade 10 $A$-coins for 5 of Bob's $B$-coins.\\~\\
  \item On their respective chains, each moves the coins to outputs that can only be spent
        by a 2-of-2 multisignature with both Alice and Bob.\\~\\
  \item They do sign the multisignature protocols in parallel, except that in both cases
        Bob gives Alice adaptor signatures using a commitment $T$ to a secret value $t$.\\~\\
  \item Bob replaces one of the signatures $(s, R)$ with $(s+t, R)$ and publishes it, to
        take his coins. Alice sees this, learns $t$, then does the same thing on the
        other chain to take her coins.
  \end{itemize}
}

\frame
{
  \frametitle{Example: Blind Swaps (Nick 2017)}

  \begin{itemize}
  \item Suppose now that Alice is a mixing service who receives coins and sends coins,
        but does not want to be able to link sends to receives.\\~\\
  \item She can precommit to a \emph{blind signature} sending coins to a user Bob, and
        give an adaptor signature to this blind signature.\\~\\
  \item Similar to the atomic swap, Bob sends Alice coins that can only be redeemed by
        her revealing the corresponding real signature.
  \end{itemize}~\\
  {\tiny \texttt{https://github.com/jonasnick/scriptless-scripts/blob/blind-swaps/md/partially-blind-swap.md}}
}

\frame
{
  \frametitle{Example: zk-Contingent Payments (Maxwell 2011)}

  \begin{itemize}
  \item Suppose now that Alice is a computational service who wants to sell the solution
        to some hard problem.\\~\\
  \item She can make a commitment $T$ to a value $t$, and provide a \emph{zero-knowledge proof}
        that $t$ is the encryption key to a solution of the problem. (Also she provides
        the encrypted solution.)\\~\\
  \item She then sends an adaptor signature to $T$ to Bob, for a signature that would
        redeem coins jointly owned by her and Bob. Bob can now sign.
  \end{itemize}
}


\frame
{
  \frametitle{Features of Adaptor Signatures}
  \begin{itemize}
  \item By attaching auxiliary proofs to $T$ to ensure $t$ is some necessary data
        for a separate protocol, arbitrary steps of arbitrary protocols can be made
        equivalent to signature production.\\~\\
  \item In particular, by using the same $T$ in multiple adaptor signatures it is
        possible to make arbitrary sets of signatures atomic with other arbitrary sets,
        enabling multi-hop payment channels.\\~\\
  \item You can re-blind commitments between hops while retaining the atomicity, for
        improved privacy.
  \end{itemize}
}

\frame
{
  \frametitle{Features of Adaptor Signatures}
  \begin{itemize}
  \item After a signature hits the chain, anyone can make up a commitment $T$ and compute a
        corresponding ``adaptor signature'' for it, so such schemes are \emph{deniable}.\\~\\
  \item Unlike hash-preimages, the secret $t$ is revealed only to a party in possession
        of an adaptor signature, who can efficiently prove knowledge of it. This gives
        a \emph{transferrable proof} that a protocol (e.g. a Lightning invoice) was
        completed correctly.\\~\\
  \item Existing multisignature outputs can be used with adaptor signatures, no need to
        precommit to a specific protocol.
  \end{itemize}
}

\frame
{
  \frametitle{New Developments}
  \begin{itemize}
  \item Lightning with scriptless scripts (AJ Towns and others, lightning-dev 2018)\\~\\
  \item ECDSA rather than Schnorr (Moreno-Sanchez, Kate 2018)
  \end{itemize}
}

\frame
{
  \frametitle{~}

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

\end{document}