diff --git a/whitepaper/zssp.tex b/whitepaper/zssp.tex
index ca3b7dd..33633ad 100644
--- a/whitepaper/zssp.tex
+++ b/whitepaper/zssp.tex
@@ -227,7 +227,7 @@ If Alice has corrupted their storage, Alice can either send the empty string or
 ZSSP is a stack of three closely related, but independent protocols. These are the \emph{Zeta Key Exchange} (ZKE), the \emph{ZeroTier Challenge Protocol} (ZCP) and the \emph{ZeroTier Fragmentation Protocol} (ZFP), described in \figureref{fig:protocol_stack}. The Zeta Key Exchange is the most complex and most essential from this stack: It is the part of ZSSP that implements Noise XK and Noise KK and directly interfaces with the upper protocol. For that reason we are going to describe it first, in isolation from the lower protocols.
 
 \begin{figure}
-	\caption{The protocol stack of ZSSP. When the upper protocol sends a packet, it must pass down the protocol stack from the top to the bottom, where each layer may modify or adds to the packet in some way. When the datagram protocol receives a packet, it passes is up towards the top of the protocol stack. Any layer may consume the incoming packet and not pass it upwards. The Zeta Key Exchange performs key exchanges to provide authenticated encryption to packets. The ZCP protects any key exchange protocol above it from CPU exhaustion DOS attacks. And the ZeroTier Fragmentation Protocol fragments packets to fit within the MTU of the protocol below it, in a way that mitigates common fragmentation DOS attacks.}\label{fig:protocol_stack}
+	\caption{The protocol stack of ZSSP. When the upper protocol sends a packet, it must pass down the protocol stack from the top to the bottom, where each layer may modify or adds to the packet in some way. When the datagram protocol receives a packet, it passes it up towards the top of the protocol stack. Any layer may consume the incoming packet and not pass it upwards. The Zeta Key Exchange performs key exchanges to provide authenticated encryption to packets. The ZCP protects any key exchange protocol above it from CPU exhaustion DOS attacks. And the ZeroTier Fragmentation Protocol fragments packets to fit within the MTU of the protocol below it, in a way that mitigates common fragmentation DOS attacks.}\label{fig:protocol_stack}
 	\centering
 	\begin{tikzpicture}[stack/.style={rectangle split, rectangle split parts=#1,draw, anchor=center}]
 		\node[stack=5]  {
@@ -243,7 +243,7 @@ ZSSP is a stack of three closely related, but independent protocols. These are t
 The next section will be dedicated to describing ZKE in explicit detail. We will be making heavy use of common mathematical notions and notation surrounding Deterministic Finite Automata, State Machines and AKE security. The goal with this section is to describe ZKE at a level of detail necessary both to allow someone to implement ZKE, and to aide future mathematical analysis of ZKE.
 
 \begin{definition}[ZKE packet types]
-	We define 8 different packet types that essential for the functioning of ZKE.
+	We define 8 different packet types that are essential for the functioning of ZKE.
 	\begin{itemize}
 		\item $X_1$: This packet type contains the first message of Noise XK. It is identified internally with packet type number `0'.
 		\item $X_2$: This packet type contains the second message of Noise XK. It is identified internally with packet type number `1'.
@@ -462,7 +462,7 @@ At the end of this section we will have defined $\zeta$, which is the high-level
 	\end{itemize}
 	\sectionref{sec:trans_alg} discusses how these packets are structured, and what algorithms are used to create and process each packet.
 
-	$\zeta$ has a timer system to automatically and locally trigger state transitions or packet resends. This system exists primarily as a solution to the ``two generals problem''. Since ZKE assumes a out-of-order, lossy transport environment it is necessary to have a system of resending lost messages and timing out those resends, similar to TCP. The ZKE timer system is designed to be lightweight, security focused, and simple. It provides strong guarantees about the maximum amount of time that may pass until certain security critical events, such as completing a handshake or ratcheting a session key, must occur.
+	$\zeta$ has a timer system to automatically and locally trigger state transitions or packet resends. This system exists primarily as a solution to the ``two generals problem''. Since ZKE assumes an out-of-order, lossy transport environment it is necessary to have a system of resending lost messages and timing out those resends, similar to TCP. The ZKE timer system is designed to be lightweight, security focused, and simple. It provides strong guarantees about the maximum amount of time that may pass until certain security critical events, such as completing a handshake or ratcheting a session key, must occur.
 
 	We assume that the underlying computer running $\zeta$ exposes some mechanism for creating a \emph{timer} which can be \emph{set} to some amount of time, and the computer will \emph{trigger} the timer after approximately that amount of real time has passed.
 	\begin{itemize}