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

\documentclass{beamer}

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

\title{Taproot: Who, How and Why}
\author{Andrew Poelstra}
\institute{\texttt{schnorr@wpsoftware.net}}
\date{March 7, 2020}

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

\begin{document}
\frame{ \frametitle{}
\begin{center}
{\small MIT Bitcoin Expo, March 7, 2020}~\\~\\~\\~\\
\includegraphics[scale=0.3]{taproot_umlauts_slant.png}\\
{\color{darkred}
\huge Who $\cdot$ How $\cdot$ Why}\\~\\~\\
Andrew Poelstra\\
{\tiny Director of Research, Blockstream}\\
\end{center} }

\newcommand{\G}{{\color{black}G}}
\newcommand{\wG}{{\color{white}G}}
\newcommand{\mui}{{\color{blue}\mu_i}}
\newcommand{\wmui}{{\color{white}\mu_i}}
\newcommand{\m}{{\color{blue}m}}
\newcommand{\x}{{\color{red}x}}
\renewcommand{\t}{{\color{red}t}}
\renewcommand{\k}{{\color{red}k}}
\renewcommand{\P}{{\color{blue}P}}
\newcommand{\R}{{\color{blue}R}}
\newcommand{\Rz}{{\color{purple}R^0}}
\renewcommand{\c}{{\color{purple}c}}
\newcommand{\T}{{\color{blue}T}}
\newcommand{\s}{{\color{blue}s}}
\newcommand{\e}{{\color{blue}e}}

\newcommand{\gm}[1]{{\color{red}\gamma_{#1}}}
\newcommand{\poly}[1]{{\color{red}p_{#1}}}
\newcommand{\share}[2]{{\color{red}\zeta_{#1,#2}}}
\newcommand{\boxthing}{{\color{red}\left[\vdots\qquad\vdots\right]_j}}


%% Outline - 25 mins, early morning, MIT
%
% Part 1: Taproot
% Spending Conditions: Scripts and Keys
% Key Tricks: Thresholds and Adaptors and Hidden Commitments
% Taproot Assumption
% Taproot: p2c + MAST
%
% Part 2: Designing for Bitcoin
% Is Bitcoin Dead?
% The weight of protocol changes
% Tradeoffs suck (no wasted bytes)
% Political things
% A Brief comment about segwit deployment
%

%%%% Begin part one
\frame
{
  \begin{center}
  \huge\color{brown}
  \textit{\underline{\"one}}\\
  \Huge\color{darkred}
  What is Taproot?
  \end{center}
}

\frame
{
  \frametitle{Spending Conditions: Keys and Scripts}
  \begin{itemize}
  \item To spend bitcoins one must satisfy the coins' \alert{spending conditions}\\~\\
  \item These conditions are specified using \alert{Bitcoin Script}\\~\\
  \item Conditions include: signature checks, hashlocks, timelocks\\~\\
  \item Not included: velocity limits, spend destinations, refund mechanisms (future work?)
  \end{itemize}
}

\frame
{
  \frametitle{Spending Conditions: Scripts and Witnesses}
  \begin{itemize}
  \item A script may specify a wide set of spending conditions, but ultimately
      only one is used\\~\\
  \item For privacy and scalability, alternates should not be revealed\\~\\
  \item Since 2012 this idea (MAST) has been floated, but never implemented. Why?
  \end{itemize}
}

\frame
{
  \frametitle{Spending Conditions: Keys Tricks}
  \begin{itemize}
  \item Signature check (against a key) is the most common condition\\~\\
  \item Keys can express much more than sig checks\\~\\
  \item \alert{Multisignatures}, threshold signatures, hashlocks, commitments\\~\\
  \item $\P \to \P + H(\P,\m)\cdot\G$
  \end{itemize}
}

\frame
{
  \frametitle{Spending Conditions: Taproot Assumption}
  \begin{center}
  {\huge\color{brown}\underline{Taproot Assumption}}\\~\\
  If all interested parties agree, no other conditions matter.
  \end{center}
}

\frame
{
  \frametitle{Taproot}
  \begin{itemize}
  \item Use MAST to hide conditions behind a Merkle root\ldots\\~\\
  \item \ldots then hide the Merkle root with a key-commitment\ldots\\~\\
  \item \ldots and allow direct spends with the key
  \end{itemize}
}


%%%% Begin part two
\frame
{
  \begin{center}
  \huge\color{brown}
  \textit{\underline{tw\"o}}\\
  \Huge\color{darkred}
  Designing for Bitcoin
  \end{center}
}

\frame
{
  \frametitle{Is Bitcoin Dead?}
  \begin{itemize}
  \item Public perception is that Bitcoin development is very slow\\~\\
  \item \emph{Deployment} on Bitcoin is indeed slow, with good reason\\~\\
  \item (Is it slow enough?)\\~\\
  \item The pace of \alert{research} is overwhelming
  \end{itemize}
}

\frame
{
  \frametitle{The Unbearable Heaviness of Protocol Changes}
  \begin{itemize}
  \item Every change must be accepted by the \alert{entire community}\\~\\
  \item Miners, protocol developers, wallet developers, HSM developers,
      retail users, institutional users, exchanges, custodians, etc., etc.\\~\\
  \item If a change makes their lives meaningfully worse, it won't happen\\~\\
  \item Requiring a software update is probably ``making lives meaningfully worse''
  \end{itemize}
}

\frame
{
  \frametitle{The Unbearable Heaviness of Protocol Changes}
  \begin{itemize}
  \item Bitcoin is worth about about \$170bn\\~\\
  \item Mistakes (probably) \alert{can't be undone}\\~\\
  \end{itemize}
}

\frame
{
  \frametitle{Tradeoffs Suck}
  \begin{itemize}
  \item Cryptography lets us do many things with \alert{no additional resources}\\~\\
  \item But not everything (?)\\~\\
  \item Even a few wasted bytes can be the difference when adopting a
      proposal (want a win for as many people as possible)\\~\\
  \item There is also a complexity cost
  \end{itemize}
}

\frame
{
  \frametitle{Political Things}
  \begin{itemize}
  \item Segwit saw some dramatic political posturing, but ordinary
      politics are less exciting\\~\\
  \item Many participants are afraid of change or complexity for
      consensus risk\\~\\
  \item Many developers do not want to learn and implement new crypto
      (increased cost, risk of mistakes, user confusion)\\~\\
  \item Bikeshedding, demand for proofs, generating excitement, etc.
  \end{itemize}
}

\frame
{
    \frametitle{~}
    \begin{center}
    Andrew Poelstra\\
    \texttt{coronavirus@wpsoftware.net}\\~\\~\\
    \includegraphics[scale=0.5]{blockstream.png}
    \end{center}
}

\end{document}