final?

whitepaper/Dissertation.bib

@@ -88,6 +88,19 @@ doi={10.1109/SP.2014.36}}
 	isbn="978-3-642-02384-2"
 }
 
+@misc{monero,
+author = {Monero Research Lab},
+title = {What is {Monero} ({XMR})?}
+howpublished = {\url{https://www.getmonero.org/get-started/what-is-monero/}}
+}
+
+@misc{zcash,
+author = {Electric Coin Company},
+organization = {Electric Coin Company},
+title = {{Zcash Basics -- Zcash Documentation}},
+howpublished = {\url{https://zcash.readthedocs.io/en/latest/rtd_pages/basics.html}}
+}
+
 @article{10.1145/116825.116852,
 	author = {Goldreich, Oded and Micali, Silvio and Wigderson, Avi},
 	title = {Proofs That Yield Nothing but Their Validity or All Languages in NP Have Zero-Knowledge Proof Systems},
@@ -480,3 +493,32 @@ doi={10.1109/SP.2014.36}}
 	title = {{Bitcoin Cash -- Peer-to-peer Electronic Cash}},
 	howpublished = {\url{https://bitcoincash.org}}
 }
+
+@misc{epic,
+author = {{Epic Games}},
+title = {Epic is turning off online services for some older games},
+howpublished = {https://www.epicgames.com/site/en-US/news/epic-is-turning-off-online-services-and-servers-for-some-older-games}}
+
+@article{bitcoin08,
+    author = {Nakamoto, Satoshi},
+    year = {2008},
+    month = {10},
+    pages = {},
+    title = {Bitcoin: A Peer-to-Peer Electronic Cash System},
+    journal = {Cryptography Mailing list at https://metzdowd.com}
+}
+
+@article{bitcoindeanon,
+author = {Bohannon, John},
+title = {Why criminals can't hide behind {Bitcoin}},
+year = {2016},
+month = {03},
+day = {09},
+howpublished = {\url{https://www.science.org/content/article/why-criminals-cant-hide-behind-bitcoin}}
+}
+
+@misc{slsk,
+author = {"Nir"},
+title = {Frequently Asked Questions | Soulseek},
+howpublished = {\url{http://www.soulseekqt.net/news/faq-page#t10n606}}
+}

whitepaper/Dissertation.tex

@@ -120,7 +120,7 @@ Without patching the executables, there is no way for a user to run their own se
 However, centralised services have a number of major downsides. \begin{itemize}
 	\item \textbf{User freedom.} Users often cannot audit or modify the underlying source code. Furthermore, users must follow rules enforced by the platform, which can be arbitrarily set and enforced.
 
-	\item \textbf{Liability.} In some jurisdictions, platforms are held legally responsible for content on their platforms. This means that platform operators may be forced to invade the privacy of their users, and consequences are felt by the platform and not the user.
+	\item \textbf{Liability.} In some jurisdictions, platforms are held legally responsible for content on their platforms. This means that consequences of illegal activities are sometimes felt by the platform and not the criminal user, and this encourages platforms to invade the privacy of their users.
 
 	\item \textbf{Ownership.} The service is owned by the operators. If the operators wish to close the service, it is at their own discretion.
 \end{itemize}
@@ -134,22 +134,22 @@ In P2P networks, traffic may be routed directly to other peers. In federated net
 P2P and federated networks address each of the disadvantages listed above. \begin{itemize}
 	\item \textbf{User freedom.} The platform is run by its users. Whilst this doesn't require that the source code is available, it allows the auditing of data collected, and the network may diverge to meet the needs of different groups of users. For example, Bitcoin Cash is a fork from Bitcoin intended to address concerns over transaction fees \cite{bch}.
 
-	\item \textbf{Liability.} Users are legally responsible for their own behaviours. This can result in legal consequence against users themselves rather than the platform \cite{bittorrent2008}.
+	\item \textbf{Liability.} Users are legally responsible for their own behaviours. This results in legal consequence against criminal users, and relative immunity of the platform \cite{bittorrent2008}.
 
-	\item \textbf{Ownership.} 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}.
+	\item \textbf{Ownership.} Games such as Unreal Tournament 99 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,epic}.
 \end{itemize}
 
-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.
+However, general privacy can often be worse in fully P2P networks than that of fully centralised networks. As there is no trusted server, there is no easy way to hide traffic of certain users or maintain, validate, and operate on private state. For example, most popular cryptocurrencies (such as Bitcoin and Ethereum) are public-ledger, meaning transactions can be publicly tracked. This is far less private than services such as banks or cash \cite{bitcoin08,bitcoindeanon}.
 
-Some P2P services try to address issues with security. In file-sharing protocols such as BitTorrent, a tracker supplies hashes of the file pieces to validate the file being downloaded \cite{cohen_2017}. However, the downside of this approach is that a trusted party (in this case the tracker) is still required. A malicious tracker could supply bad hashes, or an outdated tracker may expose peers to security vulnerabilities.
+Some P2P services try to address issues with privacy. Monero and Zcash are privacy coins that use cryptographic protocols to obscure transaction amounts \cite{monero,zcash}. The P2P file-sharing protocol Soulseek keeps a user's download history private by using direct communication between the two peers \cite{slsk}. The downside of this approach is that if the first user goes offline, files will no longer be available. BitTorrent overcomes this by pooling peers with the file into a "seed pool". The disadvantage of this approach is that the users who download files is now public knowledge \cite{cohen_2017}.
 
 \subsection{Untrusted setups}
 
 Currently, there exists an online centralised version of the board game Risk.
 
-We aim to apply bit-commitment schemes, zero-knowledge proofs, and homomorphic encryption to an online P2P variant of Risk, to allow peers to play the game whilst preventing cheating and needing no trusted parties. The variant of the game that is of interest is the "fog of war" variant, where a player cannot see the unit counts of regions besides those that they own or are neighbouring.
+We aim to apply bit-commitment schemes, zero-knowledge proofs, and homomorphic encryption to an online P2P variant of Risk. This will allow peers to play the game whilst preventing cheating and needing no trusted parties. The variant of the game that is of interest is the "fog of war" variant, where a player cannot see the unit counts of regions besides those that they own or are neighbouring: this introduces private state to be operated on.
 
-\section{Literature review}
+\chapter{Literature review}
 
 Centralised systems can securely perform the generation of random values, through using a cryptographically secure random number generator on the server-side, and distributing the values to the clients. This is how dice rolls are processed in centralised online games. However, in a P2P system, another approach must be taken to simulate the randomness, to ensure all peers receive the same random value.
 
@@ -159,17 +159,17 @@ For such randomness, we also want that \begin{itemize}
 \end{itemize}
 We apply the concept of bit-commitment schemes to form these guarantees.
 
-\subsection{Bit-commitment schemes}
+\section{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.
 
-\subsubsection{Commutative cryptography}
+\subsection{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.
 
 However, almost all well-documented encryption schemes are not commutative. One alternative is to use a well-known one-way function, such as SHA \cite{FIPS202}, with randomly generated salts.
 
-\subsubsection{Bit-commitment with one-way functions}
+\subsection{Bit-commitment with one-way functions}
 
 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.
@@ -183,7 +183,7 @@ Protocols exist for flipping fair coins "across a telephone", which is isomorphi
 
 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 to form a "secret sharing" protocol.
 
-\subsection{Zero-knowledge proofs}
+\section{Zero-knowledge proofs}
 
 Informally, zero-knowledge proofs can be considered to be protocols between two parties (the prover and the verifier) that operate on some given statement. The protocol holds the following three properties: \begin{itemize}
 	\item \textbf{Completeness.} If the statement is true, an honest verifier will be convinced of its truth by a prover.
@@ -214,7 +214,7 @@ Zero-knowledge proofs are particularly applicable to the presented problem. They
 
 One solution to this is to transform a proof into a non-interactive zero-knowledge proof. The Fiat-Shamir transformation \cite{fiatshamir} converts an interactive zero-knowledge proof into a non-interactive zero-knowledge proof. In this process, the ability for a verifier to behave maliciously is lost, as the verifier no longer produces challenges themselves. However, this relies strongly upon the random-oracle model \cite{randomoracle}. As the random-oracle model is not realistically attainable, it must be approximated, typically by a cryptographic hash function. This introduces greater ability for the prover to cheat if they know a preimage in the hash function used.
 
-\subsubsection{Games as graphs}
+\subsection{Games as graphs}
 
 The board used to play Risk can be viewed as an undirected graph. Each region is a node, with edges connecting it to the adjacent regions. For convenience, we also consider the player's hand to be a node, which has all units not in play placed upon it.
 
@@ -234,13 +234,13 @@ The main game protocol can be considered as the following graph mutations for a
 
 The goal is to identify ways to secure this protocol by obscuring the edges and weights, whilst preventing the ability for the player to cheat.
 
-\subsubsection{Graphs \& zero-knowledge proofs}
+\subsection{Graphs \& zero-knowledge proofs}
 
 A typical example for zero-knowledge proofs is graph isomorphism \cite{10.1145/116825.116852}.
 
 Identifying Risk as a graph therefore enables us to construct isomorphisms as part of the proof protocol. For example, when a player wishes to commit to a movement, it is important to prove that the initial node and the new node are adjacent. This can be proven by communicating isomorphic graphs, and constructing challenges based on the edges of the original graph.
 
-\subsubsection{Cheating with negative values}
+\subsection{Cheating with negative values}
 
 Zerocash is a ledger system that uses zero-knowledge proofs to ensure consistency and prevent cheating. Ledgers are the main existing use case of zero-knowledge proofs, and there are some limited similarities between ledgers and Risk in how they need to obscure values of tokens within the system.
 
@@ -262,7 +262,7 @@ Bulletproofs have advantages in size and "batch verification", where a verifier
 
 In general, this approach uses a decomposition of the plaintext message $m$ into its bits. This allows a verifying party to reconstruct an encryption of $m$, and check the bit length, without discovering $m$ \cite[Section~1.2.1]{Boudot2000EfficientPT}.
 
-\subsubsection{Additive homomorphic cryptosystems}
+\section{Additive homomorphic cryptosystems}
 
 Some cryptosystems admit an additive homomorphic property: that is, given the public key and two encrypted values $\sigma_1 = E(m_1), \sigma_2 = E(m_2)$, the value $\sigma_1 + \sigma_2 = E(m_1 + m_2)$ is the ciphertext of the underlying operation.
 
@@ -290,13 +290,13 @@ Exponentials of the fixed base $h_n$ can then be pre-computed to speed up expone
 
 Jurik states that the optimised form can lead to a theoretic four times speedup over Paillier's original form.
 
-\subsubsection{Zero-knowledge proofs in Paillier cryptosystem}
+\subsection{Zero-knowledge proofs in Paillier cryptosystem}
 
 There exist honest-verifier zero-knowledge proofs for proving a given value is 0 \cite[Section~5.2]{damgard2003}. Hence, proving a summation $a + b = v$ can be performed by proving $v - a - b = 0$, which is possible by the additive homomorphic property.
 
 Therefore, using Paillier's scheme to obscure edge weights should enable verification of the edge values without revealing their actual values.
 
-\subsubsection{Reducing communication}
+\subsection{Reducing communication}
 
 In the presented algorithms, interaction is performed fairly constantly, leading to a large number of communications. This will slow the system considerably, and make proofs longer to perform due to network latency.
 
@@ -585,7 +585,7 @@ Paillier is implemented by four classes: \texttt{PubKey}, \texttt{PrivKey}, \tex
 
 A large part of Risk involves random behaviour dictated by rolling some number of dice. To achieve this, a fair protocol must be used to generate random values consistently across each peer without any peer being able to manipulate the outcomes.
 
-This is achieved through bit-commitment and properties of $\mathbb{Z}_n$. The protocol for two peers is as follows, and generalises to $n$ peers.
+This is achieved with a standard application of bit-commitment, and properties of $\mathbb{Z}_n$. The protocol for two peers is as follows, and generalises to $n$ peers.
 
 \begin{protocol}[Shared random values]\label{protocol2}
 \begin{center}
@@ -1290,6 +1290,8 @@ Using a language that can interact with the operating system would have further
 
 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,086}
+
 \bibliography{Dissertation}
 
 \end{document}