diff --git a/chapter-smpc/chapter.tex b/chapter-smpc/chapter.tex
index 06d6de1..1977f5f 100644
--- a/chapter-smpc/chapter.tex
+++ b/chapter-smpc/chapter.tex
@@ -166,7 +166,7 @@
 \dominitoc
 \faketableofcontents
 
-\chapter{Secure Multiparty Computation in Scalable Hardware Security Modulese}
+\chapter{Multiparty Computation in Scalable Hardware Security Modules}
 \ifdefined\thesispreviewmode
 {\Large \textbf{Draft build}, git revision \texttt{\input{version.tex}}}
 \fi
@@ -174,7 +174,114 @@
 \newpage
 \setstretch{1.3}
 
-\section{Trust by Committee}
+\section{Fast MPC and Slow HSMs}
+
+Multiparty Computation (MPC) is a cryptographic construct that allows several networked parties to jointly perform a
+computation in such a way that the inputs to the computation remain private to the parties providing them, and no single
+party must be trusted for the computation to produce the correct result. Conceptually, MPC is similar to a secret
+sharing scheme that shares computation instead of data between untrusted parties. The computation primitive MPC offers
+is a cryptographic answer to the issue of bootstrapping trust in a computing system. 
+
+%The most challenging scenarios in computing arise when multiple 
+%parties such as manufacturers and operators, servers and clients, or sellers and buyers need to interact through
+%computation. In many practical situations, it is impossible to create a single computer that can be trusted by every
+%participant. MPC is a generic solution to a multitude of such scenarios reducing the problem of creating a single,
+%shared computer everyone can trust simultaneously to everyone creating their own computer that they only can trust.
+
+We can deconstruct the problem of trust in computing into two largely disjunct parts: Establishing trust in a computing
+system during its creation is one, and maintaining this trust throughout its life is the other. For the second part of
+this problem, maintaining trust in a system once trusted, we have an ample supply of good methods such as encryption,
+authentication, and formally proven protocols. In contrast, establishing trust in a computing system is largely
+intractable and despite a large corpus of academic research on approaches such as hardware trojan detection and
+physicaly unclonable functions, only two approaches find practical adoption: In one, we build the system ourselves from
+the ground up, making sure to leave no part vulnerable to third-party compromise. In the other, we arbitrarily buy a
+computer from a randomly chosen physical store, assuming that while an attacker can target any particular system, they
+cannot target all systems simultaneously and we give them too little time to target the system we buy.
+
+A limitation of both approaches is that in either case, while the party creating or acquiring the system can trust it,
+they cannot prove its trustworthiness to other parties. MPC solves this issue by allowing every party to contribute
+their trusted system to the protocol, cryptographically bootstrapping common trust in the computation and its
+output\footnote{
+    In fact, MPC does more than just bootstrapping from each participant trusting their own system to a trusted shared
+    computation. In an MPC protocol providing semi-honest or better security, MPC even \emph{relaxes} each party's trust
+    requirement from trusting their own system to trusting that any $n$-of-$k$ out of all systems contributing to the
+    protocol.
+}.
+
+MPC is a uniquely powerful cryptographic primitive, yet it has still not found widespread practical adoption. This is
+because MPC is extremely resource-intensive to run. MPC protocols exist on a continuum trading off between extreme
+memory and bandwidth requirements on one end and intense computational requirements on the other end. At a first glance,
+MPC and Hardware Security Modules look like they would complement each other well, but HSMs cannot keep up with the
+intense computational requirements posed by MPC.
+
+Commercially available HSMs are quoted to perform between X and Y\todo{Look up number range} individual cryptographic
+operations per second. Meanwhile, an MPC protocol doing something as simple as a single AES encryption, corresponding to
+X\todo{look up numbers} logic gates or Y\todo{look up numbers} x86-64 instructions, requires
+\emph{millions}\todo{Validate and add citation} of cryptographic operations when performed in MPC. As a result, applying
+conventional HSMs to MPC at any practical scale is infeasible by multiple orders of magnitude.
+
+HSMs are slow compared to contemporary computers because they are limited in their power dissipation, and power
+dissipation is largely proportional to processing speed. In the limited fields where HSMs have found commercial
+application, this limitation was never considered important and market forces pushing towards faster HSMs remain
+light\todo{Can we find a citation here?}. Fundamentally, conventional HSMs must envelope the entire payload in a tamper
+sensing mesh to detect drilling attacks, but a tamper sensing mesh that is impermeable to a drill is also impermeable to
+air. As a result, any heat conducted from the HSMs processor to the outside world must pass through the mesh. At the
+same time, the mesh cannot be thinned either because thinning it would enable micro-drilling attacks. The result of
+these constraints is a high thermal resistance between the HSM's processor and an external heat sink, which limits
+maximum power dissipation to a fraction of what is achieved in modern CPUs or even GPUs.
+
+Inertial HSMs solve this issue since they allow their payload to be air cooled without compromising security, and they
+expand the feasible security boundary size from the several hundred milliliters offered by conventional HSMs to several
+liters and more, enabling the integration of standard, off-the-shelf server components such as mainboards, CPUs, CPU
+coolers, and power supplies. In this chapter, we will first provide a short overview of the theory of MPC before
+elaborating a design of an IHSM tailored to MPC tasks including performance calculations and unique design aspects. We
+will conclude with an outlook of applications unlocked by our design as well as promising areas for future improvements
+of our design. 
+
+\section{The Fundamentals of Multiparty Computation}
+
+\subsection{Fundamental Primitives}
+\subsubsection{Secret Sharing}
+\subsubsection{Oblivious Transfer}
+
+\subsection{Boolean MPC}
+% Yao's Garbled Circuits
+
+\subsection{Arithmetic MPC}
+% BGW
+
+\subsection{Practical Application}
+\subsubsection{Preprocessing and Online Phases}
+\subsubsection{OT extensions}
+\subsubsection{Constant-Round MPC}
+
+\subsection{Security Models in MPC}
+
+\subsection{Performance}
+
+\subsection{Practical Deployments}
+
+\subsection{MPC in HSMs}
+
+\subsection{HSM Construction}
+
+\subsection{Solutions}
+
+\section{A High-Performance IHSM for MPC Applications}
+
+\subsection{A Practical Performance Target}
+
+\subsection{Hardware Requirements}
+
+\subsection{A Joint Cooling and IHSM Envelope Powertrain}
+
+\subsection{Rotation-Invariant Envelope Power Supply}
+% Twisted Inductor paper
+
+\subsection{Software Considerations}
+
+\subsection{Fast Zeroization of Non-Customizable Memories}
+% Thermite experiements and paper
 
 \section{Outlook}