diff --git a/whitepaper/Dissertation.pdf b/whitepaper/Dissertation.pdf
index 98a83fd..0ef76c7 100644
Binary files a/whitepaper/Dissertation.pdf and b/whitepaper/Dissertation.pdf differ
diff --git a/whitepaper/Dissertation.tex b/whitepaper/Dissertation.tex
index e4da6e6..c5466cc 100644
--- a/whitepaper/Dissertation.tex
+++ b/whitepaper/Dissertation.tex
@@ -1082,6 +1082,26 @@ Paillier is broken if factoring large numbers is computationally feasible \cite[
 
 The proof of zero is honest-verifier \cite[Section~5.2]{damgard2003}. However, applying the Fiat-Shamir heuristic converts such a proof into a general zero-knowledge proof \cite[Section~5]{fiatshamir}. This means that, supposing the choice of transform used is appropriate, \hyperref[protocol1]{Protocol~\ref*{protocol1}} should also be general zero-knowledge. However, the interactive proofs performed as part of the game are still only honest-verifier. Consequently, a malicious verifier may be able to extract additional information from the prover (such as the blinding value used).
 
+\section{Security}
+
+\subsection{Soundness}
+
+Assuming $t = 24$, the chance of an undetected cheater in a single execution of a multi-round protocol is $2^{-24} \approx 6.0 \times 10^{-8}$.
+
+It is possible that even if a prover cheats a proof at one point, the cheat would be detected later on in the game. For example, suppose a player cheated the range proof during an attack, and as a result won the attack. This instance of cheating is likely to be detected in the final range proofs to prove that regions are non-negative in value at the end of a turn.
+
+We previously discussed the soundness issues relating to the BCDG proof \cite{bcdg1987}. These issues are overcome by \hyperref[protocol4]{Protocol~\ref*{protocol4}}, which instead aims to fix an upper bound on the bit length of a value, rather than prove a value falls within a specific range.
+
+From the additive homomorphic property, this proof can be easily manipulated to cover other ranges without affecting the soundness: for example, to prove a value is in the range $[1, 256]$, each party first multiplies the ciphertext by $g^{-1} \mod n^2$, and then proceeds with the proof as normal.
+
+\subsection{Collusion}
+
+Assuming $n$ players, we discussed that \hyperref[protocol2]{Protocol~\ref*{protocol2}} is resistant to $n-1$ colluding parties. Similarly, as the Fiat-Shamir heuristic is used for most proofs, colluding parties cannot agree beforehand to use specific challenges, which would allow cheating of proofs.
+
+The only instance of a zero-knowledge proof that doesn't use Fiat-Shamir is the proof of neighbouring values. However, this proof is not important to the integrity of the game, as all state-changing actions are verified by the other non-interactive multi-round proofs.
+
+Colluding players could agree to not verify each other's proofs. However, this would just result in the colluding players' games diverging from the games of the players who are playing fairly, effectively ending the game session for the non-colluding players.
+
 \section{Efficiency}
 
 \subsection{Storage complexity}
@@ -1094,10 +1114,10 @@ The interactive proof of zero uses two Paillier ciphertexts (each size $2|n|$),
 
 On the other hand, the non-interactive variant needs not communicate the challenge (as it is computed as a function of other variables). So the non-interactive proof size is $5|n|$.
 
-The non-interactive \hyperref[protocol1]{Protocol~\ref*{protocol1}} requires multiple rounds. Assume that we use 48 rounds: this provides a good level of soundness, with a cheat probability of $\left(\frac{1}{2}\right)^{-48} \approx 3.6 \times 10^{-15}$. Additionally, assume that there are five regions to verify. Each prover round then requires five Paillier ciphertexts, and each verifier round five non-interactive proofs of zero plus some negligible amount of additional storage for the bijection.
+The non-interactive \hyperref[protocol1]{Protocol~\ref*{protocol1}} requires multiple rounds. Assume that we use 48 rounds: this provides a good level of soundness, with a cheat probability of $2^{-48} \approx 3.6 \times 10^{-15}$. Additionally, assume that there are five regions to verify. Each prover round then requires five Paillier ciphertexts, and each verifier round five non-interactive proofs of zero plus some negligible amount of additional storage for the bijection.
 This results in a proof size of $(10|n| + 10|n|) \times 48 = 960|n|$. For key size $|n| = 2048$, this is 240kB. This is a fairly reasonable size for memory and network, but risks exceeding what can be placed within a processor's cache, leading to potential slowdown during verification.
 
-This could be overcome by reducing the number of rounds, which comes at the cost of increasing the probability of cheating. In a protocol designed to only facilitate a single game session, this may be acceptable to the parties involved. For example, reducing the number of rounds to 24 will increase the chance of cheating to $\left(\frac{1}{2}\right)^{-24} \approx 6.0 \times 10^{-8}$, but the size would reduce by approximately half.
+This could be overcome by reducing the number of rounds, which comes at the cost of decreasing the soundness. In a protocol designed to only facilitate a single game session, this may be acceptable to the parties involved. For example, reducing the number of rounds to 12 will increase the chance of cheating to $\frac{1}{4096}$, but the size would reduce by approximately half.
 
 Each of these calculations is in an ideal situation without compression or signatures: in the implementation presented, the serialisation of a ciphertext is larger than this, since it serialises to a string of the hexadecimal representation and includes a digital signature for authenticity. In JavaScript, encoding a byte string as hexadecimal should yield approximately a four times increase in size, as one byte uses two hexadecimal characters, which are encoded as UTF-16. Results for the actual sizes of each proof are given in \hyperref[table3]{Table~\ref*{table3}}. Some potential solutions are discussed here.
 
@@ -1228,7 +1248,7 @@ Multi-round proofs combining set membership and graph isomorphism are among the
 
 \section{Domain}
 
-The protocols devised are effective in the target domain of online games. With multi-round proofs of 24 rounds, players can be reasonably confident that other players are not cheating. The chance of an undetected cheater in a single execution of
+The protocols devised are effective in the target domain of online games. With multi-round proofs using 24 rounds, players can be reasonably confident that other players are not cheating.
 
 For the most part, the protocols shown run in a time-frame that would not disrupt the experience, with the exception of the bit length proof. With additional work, this proof could be replaced with a Bulletproof \cite{bulletproofs}, which may use less bandwidth and perform faster.
 
@@ -1291,7 +1311,7 @@ Using a language that can interact with the operating system would also have adv
 
 The P2P implementation requires more processing power and more bandwidth on each peer than a client-server implementation would. This is the main limitation of the P2P implementation. The program ran in a reasonable time, using a reasonable amount of resources on the computers I had access to, but these are not representative of the majority of computers in use today. Using greater processing power increases power consumption, which is undesirable. In a client-server implementation, the power consumption should be lower than the P2P implementation presented as no processing time is spent validating proofs or using the Paillier cryptosystem, which is less efficient than the hybrid cryptosystems used in standard online communication.
 
-\emph{Final word count: 9,190}
+\emph{Final word count: 9,405}
 
 \bibliography{Dissertation}