...

whitepaper/Dissertation.tex

@@ -17,6 +17,7 @@
 \usepackage{amsmath}
 \usepackage{amssymb}
 \usepackage{amsthm}
+\usepackage{float}
 \usepackage{tikz}
 \usepackage{minted}
 \usepackage{lscape}
@@ -117,9 +118,9 @@ Without patching the executables, there is no way for a user to run their own se
 
 \subsection{Peer-to-peer networks}
 
-In peer-to-peer (P2P) networks, traffic may be routed directly to other peers, or servers may be operated by third parties (sometimes called "federated networks"). This form of communication is still popular in certain games or services, for example BitTorrent is primarily a P2P service; and titles from the Counter-Strike series are federated, with a wide selection of third party hosts.
+In peer-to-peer (P2P) networks, traffic may be routed directly to other peers, or servers may be operated by third parties (sometimes called "federated networks"). This form of communication is still popular in certain games or services, for example BitTorrent is primarily a P2P service; and titles from the Counter-Strike video game series may be considered federated, with a wide selection of third party hosts.
 
-The main advantage of P2P networks over centralised networks is longevity. Games such as Unreal Tournament 99 (which is federated) still have playable servers, as the servers are community-run, and so as long as people still wish to play the game, they will remain online (despite the original developers no longer making any profit from the title) \cite{eatsleeput.com_2022}.
+The main advantage of P2P networks over centralised networks is longevity. Games such as Unreal Tournament 99 (which is now federated) still have playable servers, as the servers are community-run, and so as long as people still wish to play the game, they will remain online (despite the original developers no longer officially supporting the title) \cite{eatsleeput.com_2022}.
 
 However, security can often be worse in fully P2P networks than that of fully centralised networks. Peers may send malicious communications, or behave in ways that violate the general rules of the service. As there is no trusted server, there is no easy way to validate communications to prevent peers from cheating.
 
@@ -139,21 +140,21 @@ For dice rolling, we want that \begin{itemize}
     \item No peer can change the probable outcome of the dice (random),
     \item No peer can deny having rolled the dice (non-repudiation).
 \end{itemize}
-We apply the concept of bit commitment schemes to form these guarantees.
+We apply the concept of bit-commitment schemes to form these guarantees.
 
-\subsection{Bit commitment schemes}
+\subsection{Bit-commitment schemes}
 
-Bit commitment schemes provide a mechanism for one party to commit to some hidden value and reveal it later. This can be achieved through the use of commutative cryptographic algorithms and with one-way functions.
+Bit-commitment schemes provide a mechanism for one party to commit to some hidden value and reveal it later. This can be achieved through the use of commutative cryptographic algorithms and with one-way functions.
 
 \subsubsection{Commutative cryptography}
 
-Protocols exist that utilise bit commitment to play poker \cite{Shamir1981}. They offer a bit commitment scheme using commutative encryption algorithms based on modular arithmetic. This scheme works by each player encrypting cards, and decrypting in a different order as to obscure the value of the actual cards until all players have decrypted.
+Protocols exist that utilise bit-commitment to play poker \cite{Shamir1981}. They offer a bit-commitment scheme using commutative encryption algorithms based on modular arithmetic. This scheme works by each player encrypting cards, and decrypting in a different order as to obscure the value of the actual cards until all players have decrypted.
 
 However, almost all well-documented encryption schemes are not commutative. One alternative is to use some well-known one-way function, such as SHA, with randomly generated salts.
 
-\subsubsection{Bit commitment with one-way functions}
+\subsubsection{Bit-commitment with one-way functions}
 
-Bit commitment schemes can also be implemented using one-way functions: \begin{enumerate}
+Bit-commitment schemes can also be implemented using one-way functions: \begin{enumerate}
     \item The first party decides on the value $m$ to be committed to.
     \item The first party generates some random value $r$.
     \item The first party generates and publishes some value $c = H(m, r)$, where $H$ is an agreed-upon public one-way function.
@@ -163,7 +164,7 @@ Bit commitment schemes can also be implemented using one-way functions: \begin{e
 
 Protocols exist for flipping fair coins "across a telephone", which is isomorphic to selecting a random value from a set of two values \cite{blum1983coin}. This cannot be simply repeated though to generate numbers in the range of 1-6, as 6 is not a power of 2.
 
-However, a similar protocol can be used where each player commits to a single value $x \in \mathbb{Z}_6$. As the distribution of outcomes of addition in the group $\mathbb{Z}_n$ is fair, we can then sum the values of $x$ committed to by both players to deduce a final value for the roll. This is a standard application of bit commitment, and nicely generalises Blum's original paper.
+However, a similar protocol can be used where each player commits to a single value $x \in \mathbb{Z}_6$. As the distribution of outcomes of addition in the group $\mathbb{Z}_n$ is fair, we can then sum the values of $x$ committed to by both players to deduce a final value for the roll. This is a standard application of bit-commitment, and nicely generalises Blum's original paper.
 
 \subsection{Zero-knowledge proofs}
 
@@ -298,7 +299,7 @@ The downside of using the Fiat-Shamir heuristic in our implementation is that an
 The implementation provided uses WebSockets as the communication primitive. This is therefore a centralised implementation. However, no verification occurs in the server code, which instead simply "echoes" messages received to all connected clients.
 
 Despite this approach being centralised, it does emulate a fully P2P environment, and has notable benefits: \begin{itemize}
-    \item There is no need for hole-punching or port-forwarding.
+    \item There is no need for NAT hole-punching or port-forwarding.
     \item WebSockets are highly flexible in how data is structured and interpreted.
 \end{itemize}
 
@@ -382,8 +383,22 @@ The game is broken down into three main stages, each of which handles events in
 	\draw[very thick,dashed,->] (Ready)-- node[right] {All players ready} ++(MoveStage1);
 	\draw[very thick,->] (MoveStage1) -- (Random1);
 
-	% Player connect handling
+	% Player act handling
-	\node[draw=blue!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Act1) at (56pt, -50pt) {Player acts};
+	\node[draw=blue!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Act1) at (60pt, -58pt) {Current player acts};
+
+    \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Claim) at (60pt, -114pt) {Claim region};
+
+    \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Reinf) at (200pt, -114pt) {Reinforce region};
+
+    \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (End1) at (200pt, -148pt) {End turn};
+
+    \draw[very thick,->] (Reinf) -- (End1);
+    \draw[very thick,->,dashed] (Act1)-- node[right] {Not all regions claimed} ++(Claim);
+    \draw[very thick,->,dashed] (Act1) -- (200pt, -67.5pt)-- node[right] {All regions claimed} ++(Reinf);
+
+    \node[draw=black!50,fill=white,rotate=270,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Update2) at (0.5\paperwidth + 60pt, -155.5pt) {Update game stage};
+
+    \draw[very thick,->,dashed] (End1)-- node[below] {All reinf. placed} ++(Update2);
 \end{tikzpicture}\end{landscape}
 
 \section{Message structure}
@@ -412,14 +427,12 @@ As \texttt{BigInt}'s V8 implementation does not optimise modular exponentiation
 
 The number of operations is dependent primarily on the size of the exponent. For an exponent of bit length $L$, somewhere between $L$ and $2L$ multiply-and-modulo operations are performed, which gives overall a logarithmic time complexity supposing bit-shifts and multiply-and-modulo are constant time operations.
 
-\subsection{Generating large primes}
-
-Generating primes is a basic application of the Rabin-Miller primality test \cite{RABIN1980128}. This produces probabilistic primes, however upon completing sufficiently many rounds of verification, the likelihood of these numbers actually not being prime is dwarfed by the likelihood of some other failure, such as hardware failure.
-
 \subsection{Public key}
 
 In the Paillier cryptosystem, the public key is a pair $(n, g)$ where $n = pq$ for primes $p, q$ satisfying $\gcd(pq, (p - 1)(q - 1)) = 1$ and $g \in \mathbb{Z}^*_{n^2}$. The range of plaintexts $m$ is restricted to $0 < m < n$.
 
+Generating primes is a basic application of the Rabin-Miller primality test \cite{RABIN1980128}. This produces probabilistic primes, however upon completing sufficiently many rounds of verification, the likelihood of these numbers actually not being prime is dwarfed by the likelihood of some other failure, such as hardware failure.
+
 The Paillier cryptosystem is otherwise generic over the choice of primes $p, q$. However, by choosing $p, q$ of equal length, the required property of $pq$ and $(p - 1)(q - 1)$ being coprime is guaranteed.
 
 \begin{proposition}
@@ -572,7 +585,7 @@ The encryption function used must also guarantee the integrity of decrypted ciph
 
 This extends inductively to support $n-1$ cheating participants, even if colluding. Finally, we must consider how to reduce random noise to useful values.
 
-\subsection{Modular bias}
+\subsection{Resampling}
 
 A common approach is to take the modulus of the random noise. This causes modular bias to appear however, where some values are less likely to be generated.
 
@@ -635,7 +648,7 @@ The first proof to discuss is the honest-verifier protocol to prove knowledge th
 
 A proof for the following homologous problem can be trivially constructed: given some ciphertext $c = g^mr^n \mod n^2$, prove that the text $cg^{-m} \mod n^2$ is an encryption of 0. The text $cg^{-m}$ is constructed by the verifier. The prover then proceeds with the proof as normal, since $cg^{-m}$ is an encryption of 0 under the same noise as the encryption of $m$ given.
 
-This is used in point (2), as one player can then convince a neighbour in zero-knowledge of the number of units within their region.
+This is used in point (2), as one player can then convince a neighbour in zero-knowledge of the number of units within their region. It is also used throughout the other proofs presented.
 
 \subsection{Proving reinforcement}
 
@@ -806,7 +819,7 @@ Validating $E(m)$ is done with the proof of zero. Then it remains to prove that
 	\end{enumerate}
 \end{protocol}
 
-The downside of this proof over the BCDG proof \cite{bcdg1987} is that the time to perform and verify this proof grows linearly with $|m|$. However, in most cases $|m|$ should be small: i.e, $|m| \leq 5$.
+The downside of this proof over the BCDG proof \cite{bcdg1987} is that the time to perform and verify this proof grows linearly with $|m|$. However, in most cases $|m|$ should be "small": i.e, $|m| \leq 5$.
 
 Range proof is used in points (3), (4), and (5). In (3), this is to convince other players that the number of units is sufficient for the action. In (4), this is to show that the region is not totally depleted. In (5), this is to ensure the number of units being fortified is less than the strength of the region. All of these are performed using \hyperref[protocol4]{Protocol~\ref*{protocol4}} and by using the additive homomorphic property to subtract the lower range from $m$ first.
 
@@ -814,7 +827,7 @@ Range proof is used in points (3), (4), and (5). In (3), this is to convince oth
 
 Point (5) still remains, as the range proof alone only works to prevent negative values from appearing in the resolution of a fortify action. Fortify actions need to be of form $\{ k, -k, 0, \dots, 0 \}$) and the regions corresponding to $k, -k$ amounts must be adjacent.
 
-\begin{figure}[htp]
+\begin{figure}[H]
 \centering
 \begin{tikzpicture}
     \tikzstyle{style}=[circle,minimum size=15mm,draw=black,fill=white]
@@ -844,7 +857,7 @@ Point (5) still remains, as the range proof alone only works to prevent negative
 \caption{Example state change from fortify action.}
 \end{figure}
 
-\begin{figure}[htp]
+\begin{figure}[H]
     \centering
     \begin{tikzpicture}
         \tikzstyle{style}=[circle,draw=black,minimum size=10mm,fill=white]