\ifpdf
\graphicspath{{Chapter3/Figs/}}
\else
\graphicspath{{Chapter3/Figs/}}
\fi

\chapter{Analysis of Zerocoin}
\label{ch:Analysis of Zerocoin}
This chapter delves into the data structures and algorithms of Zerocoin and analyses the reasons behind some of its key weaknesses. A basic understanding of Zerocoin and the issues of privacy detailed in Chapter \ref{ch:Privacy in Bitcoin} and \ref{ch:Methods to Improve Privacy in Digital Currencies} are needed to appreciate the rest of this chapter. Unless otherwise stated, all technical information on Zerocoin is obtained from the original Zerocoin paper \cite{Miers2013}.

\section{Construction of Zerocoin}
\subsection{Coin as a Pederson Commitment}
\label{sec:3-Coin as a Pederson Commitment}
The key element in Zerocoin is the \kwCoin{} that is minted and redeemed in Mint and \kwTransaction{Spend }{s}. A \kwCoin{} $c$ is a Pedersen commitment \cite{Pedersen1992} of a serial number $S\in\expIntGroup{\varQComm}$ and a random trapdoor $r\in\expIntGroup{\varQComm}$ in the form $c=\expPedCommCoin\bmod{\varPComm}$. $\varPComm$ and $\varQComm$ are large primes and $\varGComm$ and $\varHComm$ are generators of the sub-group of $\expIntGroup{\varQComm}$ multiplicative group $\expMulGroup{\varPComm}$. That is to say $\varGComm^0,\varGComm^1,...,\varGComm^{\varQComm}\bmod{\varPComm}$ and $\varHComm^0,\varHComm^1,...,\varHComm^{\varQComm}\bmod{\varPComm}$ produce two sequences of distinct numbers. To satisfy this property, $\varGComm^{\varQComm} \bmod{\varPComm}=1$ and $\varHComm^{\varQComm} \bmod{\varPComm}=1$ and thus $\varQComm$ divides $\varPComm-1$ by Fermat’s Little Theorem. In Zerocoin, $\varPComm$ and $\varQComm$ are prime numbers of 1024 and 256 bits respectively \footnote{Based on the security recommendations in Section VI(B) of the Zerocoin paper \cite{Miers2013}.}, and $\varGComm$ and $\varHComm$ are computed based using the algorithm defined in the Federal Information Processing Standards (FIPS) 186-34 \cite{InformationTechnologyLaboratory2009}. For simplicity of presentation, the Pedersen commitment will be written as $c=\expPedCommCoin$, where modulus $\varPComm$ is implied for generators $\varGComm$ and $\varHComm$.

In Zerocoin, a single set of $\varGComm,\varHComm,\varPComm,\varQComm$ is generated once as public parameters during set up, and is subsequently used by all users. To mint a \kwCoin{}, a user generates a random serial number $S\in\expIntGroup{\varQComm}$ and another random trapdoor $r\in\expIntGroup{\varQComm}$, computes a Pedersen commitment $c=\expPedCommCoin$ and include $c$ in the \kwTransaction{Mint }{}. $S$ is kept secret when the \kwTransaction{Mint }{} is created and is subsequently revealed in the \kwTransaction{Spend }{} to prove the ownership of $c$ (\S\ref{sec:3-Serial Number Signature of Knowledge}), while $r$ is always secret to the creator of the \kwTransaction{Mint }{}.

After the \kwTransaction{Mint }{} is verified and published on the Blockchain, everyone can see that the creator of the transaction has minted $c$. Theoretically, an adversary can “steal” a \kwCoin{} by obtaining $S$ and $r$ from the public $c$ and creating a valid \kwTransaction{Spend }{} using $S$ and $r$. However the adversary can only succeed with negligible probability in practice as solving $S$ and $r$ from a known $c$ where $c=\expPedCommCoin$ is believed to be hard under the Discrete Logarithm assumption \cite{Paar2010}. Due to this property, it is also hard to solve $c$ from $S$ without the knowledge of $r$. Since $r$ is secret to the owner of the \kwCoin{} at all times, an adversary is also unable to attribute the $S$ in the \kwTransaction{Spend }{s} to a $c$ in the \kwTransaction{Mint }{s} on the Blockchain. This preserves the anonymity property that the redeemer (payee) of a \kwCoin{} cannot be linked to its creator (payer).

\subsection{Public Accumulator}
\label{sec:3-Public Accumulator}
An accumulator “summarises” a large number of values into one value, and given a short witness a specific value can be proven to be accumulated in the accumulator. The accumulator in Zerocoin is a public data structure that contains every minted \kwCoin{} in history. As such, given a witness any nodes in the peer-to-peer network can verify that a \kwCoin{} has been minted using the accumulator. The size of the accumulator remains constant as more \kwCoin{s} are accumulated, thus it can be distributed and stored efficiently by the peer-to-peer network. The accumulator used in Zerocoin is a dynamic accumulator proposed by Camenisch and Lysyanskaya \cite{JanCamenisch12002} that extends the study by Baric and Pfitzmann \cite{BariC1997}. The 3 main functions provided by this accumulator scheme are explained below.

$\eqnAccum{u}{C}$ accumulates a set of \kwCoin{s} $C=\lbrace \expOneToN{c}{n} \mid c_i \in [A,B] \wedge c_i \: is \: prime \rbrace$ using parameters $(N,u)$ to produce an accumulator $A=u^{\expOneToN{c}{n}}\bmod{N}$. Like the parameters used in the Pedersen commitment for \kwCoin{s} (\S\ref{sec:3-Coin as a Pederson Commitment}), $(N,u)$ are public parameters that are generated once during set up. $N$ is a product of 2 large primes while $u$ is a quadratic residue modulo $N$ \footnote{A quadratic residue modulo N is the square of any integer modulo N.}. $N$ is recommended is to be 3072 bits long \footnote{Based on the security recommendations in Section VI(B) of the Zerocoin paper \cite{Miers2013}.}. $\mathfrak{A}$ and $\mathfrak{B}$ \footnote{$\expAFrak,\expBFrak$. $k'$ and $k''$ are set at 160 and 128 respectively. The reasons behind these values can be found in \cite{Miers2013} and \cite{JanCamenisch12002}.} defines the range of the values that an accumulated \kwCoin{} $c$ can take. In addition, $c$ must be prime before it can be accumulated. Hence when minting a new \kwCoin{}, different $S$ and $r$ must be tried until $c=\expPedCommCoin$ satisfies the above constraints.

Every time a new \kwCoin{} is successfully minted, nodes will accumulate the new \kwCoin{} into the public accumulator. Due to the construction of the dynamic accumulator, a new \kwCoin{} $c_{new}$ can be incrementally accumulated \cite{JanCamenisch12002} into the previous accumulator $A$ using $\eqnAccum{A}{\{c_{new}\}}$. Thus when updating the accumulator, one do not need to recompute $u^{\expOneToN{c}{n}c_{new}}\bmod{N}$ but simply compute $A^{c_{new}}\bmod{N}$ using the latest $A$, making accumulation efficient. Zerocoin proposes that each \kwBlock{} contains an accumulator called the accumulator checkpoint that contains all the \kwCoin{s} minted up till that \kwBlock{}. This way nodes do not need to compute the accumulator from scratch, and can choose an accumulator checkpoint from any \kwBlock{} and incrementally accumulate the \kwCoin{s} minted after that \kwBlock{} to obtain the latest accumulator value.

For a \kwCoin{} $c\in C$, $\eqnGenWit{c}{w}$ produces a witness $w=\eqnAccum{u}{C\setminus\{c\}}$. That is, $is$ an accumulation of all the \kwCoin{s} in $C$ except $c$. In Zerocoin, $C$ is the set of all minted \kwCoin{s} in history. With $w$, one can verify that that $c$ is in $C$ using $\eqnAccVer{c}$, where $A=\eqnAccum{u}{C}$. $AccVerify$ returns 1 if and only if $A=w^{c}\bmod{N}$ and $c$ is a valid \kwCoin{} ($c$ is prime and $c\in[\mathfrak{A},\mathfrak{B}]$). It can be seen that $A=w^{c}\bmod{N}$ is the correct verification equation as $A=\eqnAccum{u}{C}=u^{\expOneToN{c}{n}c}\bmod{N}=(u^{\expOneToN{c}{n}})^c\bmod{N}=w^{c}\bmod{N}$. To ensure security, $A$ should be independently computed by each verifier, which can be achieved efficiently using the incremental method described in the previous paragraph.

In Zerocoin, $GenWitness$ is used by the creator of a \kwTransaction{Spend }{} to create a witness to prove that the redeemed \kwCoin{} is in the accumulator. $AccVerify$ is used by nodes in the Zerocoin network to verify that claim when validating the \kwTransaction{Spend }{}. However $AccVerify$ is used only in principle and not directly, because $w$ and $c$ are not revealed to the verifier in a \kwTransaction{Spend }{} in order to keep $c$ unkown. Why and how the \kwTransaction{Spend }{} is verified without the knowledge of $w$ and $c$ is discussed in \S\ref{sec:3-Accumulator Proof of Knowledge}.

\subsection{Non-Interactive Zero Knowledge (NIZK) Proofs}
\label{sec:3-Non-Interactive Zero Knowledge (NIZK) Proofs}
\subsubsection{Interactive Zero Knowledge Proofs}
\label{sec:3-Interactive Zero Knowledge Proofs}
Zerocoin relies heavily on NIZK proofs, which are a subset of zero-knowledge (ZK) proofs. ZK proof is a proof of the knowledge of an element without disclosing any information beyond the legitimacy of the proof \cite{Kiayias} The formal notation of ZK proof introduced by Camenisch and Stadler \cite{Camenisch1997a} is as follow:

$$ZKPoK\{(w):statement\ proving\ knowledge\ of\ w\}$$

$ZKPoK$ refers to Zero-Knowledge Proof of Knowledge. The proof statement is enclosed in the curly brackets. The element in parenthesis is the information that the prover wishes to show knowledge of, but cannot be disclosed. This notation will be used for all zero knowledge proofs in this paper.

ZK proofs often surrounds an NP-hard problem. In general, a prover wants to prove that he has a secret solution $w$ to the NP-hard problem $y$. The prover first sends a random problem $t$ that has a solution $v$ that is unrelated to $w$. The verifier then sends a random challenge $\varChallenge$ to the prover, and the prover replies with a response $s$ that looks random but in fact is a combination of $v$, $w$ and $\varChallenge$. The verifier verifies the proof by composing $s$ with $\varChallenge$ and the original problem $y$. $s$ is constructed in a way such that if the prover knows $w$, it will cancel out $y$, leaving behind only the random problem $t$. Hence by checking that the result of the proof is $t$ the verifier is able to verify the proof, but does not learn anything about $w$ since all he sees are random values. The above is a form of interactive ZK proof which involves the verifier communicating the challenge $\varChallenge$ to the prover. A simple example of an interactive ZK proof for the knowledge of discrete logarithm can be found online \cite{Unknown2016}. This proof is chosen as an example as it is closely related to the proofs used in the Zerocoin protocol.

\subsubsection{Transforming Interactive Zero Knowledge Proofs to NIZK Proofs}
\label{sec:3-Transforming Interactive Zero Knowledge Proofs to NIZK Proofs}
NIZK proof is a special kind of ZK proof that removes the need for the verifier to interact with the prover. The prover can achieve this by a generating a challenge $\varChallenge$ from $y$ and $t$ using a random oracle \footnote{A theoretical black box that responds to every unique query with a truly random response chosen uniformly from its output domain. If a query is repeated it responds the same way every time that query is submitted. \cite{Unknown2016a}}, and treat this $\varChallenge$ as the challenge that the verifier sends in the interactive version the ZK proof. The prover then computes $s$ based on the generated $\varChallenge$ and sends the proof containing $y$, $t$ and $s$ to the verifier. Upon receiving the proof, the verifier recomputes $\varChallenge$ from the received $y$ and $t$ using the random oracle, and verifies the proof in the same way as the interactive version of the ZK proof. Since there is no interaction between the prover and the verifier, the NIZK is achieved.

The Fiat-Shamir heuristics \cite{Fiat1987} is a popular technique to transform interactive ZK proofs into NIZK proofs. Using the Fiat-Shamir heuristics, the random oracle is implemented as a cryptographic hash function \cite{Bellare1993}, and $\varChallenge$ is obtained by hashing $y$ and $t$ together with and other parameters. The NIZK proofs used in Zerocoin and the proofs proposed by this research all use the Fiat-Shamir heuristics in one way or another. The same online resource that illustrates interactive ZK proof for the knowledge of discrete logarithm also shows how the proof can be modified into a NIZK form using the Fiat-Shamir heuristics \cite{Unknown2016}.

\subsubsection{Properties of Zero-Knowledge Proofs}
\label{sec:3-Properties of Zero-Knowledge Proofs}
All ZK proofs (NIZK proofs included) need to fulfil the below properties \cite{Kiayias}:
\begin{enumerate}
	\item \textbf{\textit{Completeness}}: If the prover indeed knows the secret $w$, and both the prover and verifier follow the procedures of the proof, then the proof will always be verified.
	\item \textbf{\textit{Soundness}}: If the prover does not know the secret $w$, and both the prover and verifier follow the procedures of the proof, then the proof will not be verified. This property can be proven if a hypothetical program called the knowledge extractor that can extract $w$ from the prover using two accepting proofs that uses the same $t$ but different $\varChallenge$ and $s$. In order to do this, the knowledge extractor has access to the prover’s program (but not the $w$ itself) and can “rewind” the proof to obtain another set of $\varChallenge$ and $s$. The success of the knowledge extractor is needed to prove for soundness because if a prover who does not know $w$ manages to prove the knowledge of $w$, there is no way that a knowledge extractor can extract a $w$ that is non-existent in the proof.
	\item \textbf{\textit{Statistical Zero-Knowledge}}: The verifier does not gain any knowledge after interacting with the prover. This can be proven if a hypothetical program called a simulator with no knowledge of the secret $w$, is able to generate a response $s'$ to the challenge $\varChallenge$, such that $s'$ is statistically indistinguishable from the actual response $s$ generated by the prover. In this way the verifier does not learn anything more from the $s$ sent by the prover than from the $s$ sent by the simulator.
\end{enumerate}

\subsubsection{NIZK Proofs in Zerocoin}
\label{sec:3-NIZK Proofs in Zerocoin}
NIZK proofs are used in Zerocoin to prove the ownership of a valid unredeemed \kwCoin{} in a \kwTransaction{Spend }{}. The proof needs to be zero-knowledge so that the verifier or anyone who sees the \kwTransaction{Spend }{} does not know which \kwCoin{} is being spent. The proof also needs to be non-interactive because a \kwTransaction{Spend }{} can be verified by any node in the Zerocoin network at any time, and it is not possible for a verifier to interact with the creator of the transaction. The three NIZK proofs in a \kwTransaction{Spend }{} are:

\begin{enumerate}
	\item \textbf{\textit{Accumulator Proof of Knowledge (AccPoK)}}: Proves that a \kwCoin{} $c$ has been minted, without disclosing $c$. This is achieved by proving that $c$ is contained in the public accumulator in which every \kwCoin{} that has been minted should have been included in. Details of this proof is discussed in \S\ref{sec:3-Accumulator Proof of Knowledge}.
	\item \textbf{\textit{Serial Number Signature Proof of Knowledge (SNSoK)}}: Proves the knowledge of the serial number $S$ and the secret trapdoor $r$ that are committed in the redeemed \kwCoin{} $c$, without disclosing $r$ and $c$. Since only the owner of a \kwCoin{} knows its $S$ and $r$, this proof shows that the prover owns the \kwCoin{} being proven for. This proof also acts as a digital signature for the \kwTransaction{Spend }{}. A digital signature is needed to prevent the contents of the \kwTransaction{Spend }{}, which contains the public key address that the redeemed \kwCoin{} should be paid to, from being tampered with. Details of this proof is discussed in \S\ref{sec:3-Serial Number Signature of Knowledge}.
	\item \textbf{\textit{Commitment Proof of Knowledge (CommPoK)}}: Proves that the \kwCoin{} being proven for in the accumulator Proof of Knowledge and the \kwCoin{} being proven for in the Serial Number Signature of Knowledge are the same \kwCoin{}. This ensures the \kwCoin{} which the prover is proving to be minted is the same \kwCoin{} that he is proving ownership for. With this proof, one cannot redeem a minted \kwCoin{} that he does not own. Details of this proof is discussed in \S\ref{sec:3-Commitment Proof of Knowledge}.
\end{enumerate}

\subsubsection{Accumulator Proof of Knowledge}
\label{sec:3-Accumulator Proof of Knowledge}
For a \kwCoin{} to be spent, it must first be proven that the \kwCoin{} has been minted. The Accumulator Proof of Knowledge (AccPoK) proves this claim using the public accumulator which contains all the minted \kwCoin{s} in history.

As seen in \S\ref{sec:3-Public Accumulator}, the claim that a \kwCoin{} $c$ is in the set of minted \kwCoin{s} can be verified by presenting $AccVerify$ with the witness $w$. However this cannot be done directly in Zerocoin as $c$ needs to be secret in order to preserve unlinkability between the minter and the redeemer of $c$. In addition, $w$ also needs to be secret as it can be used to obtain $c$. This is possible because all the minted \kwCoin{s} in history are publicly available in the \kwTransaction{Mint }{s} on the Blockchain. An adversary can run $\eqnGenWit{c'}{w'}$ repeatedly using all $c'\in C$, where $C$ is all the minted \kwCoin{s} in history, and the $c'$ that produced a $w=w'$ is the \kwCoin{} that is being proven for. Hence to hide $c$ and $w$, the AccPoK is as such:

$$\eqnAccPoK$$

The implementation of the AccPoK is adapted from an interactive version of the proof by Camenisch and Lysyanskaya \cite{JanCamenisch12002} and modified to a non-interactive form using the Fiat-Shamir heuristics. The rest of the section describes the implementation details.

In order to hide $c$ and $w$, the prover creates the following commitments of $c$ and $w$ using random trapdoors:

\begin{enumerate}
	\item $\varAccPoKCoinComm$, a commitment of $c$ with a random trapdoor $ \varphi\in\expIntGroup{\lfloor N/4 \rfloor}$ such that $\varAccPoKCoinComm=\varAccPoKGComm^{c}\varAccPoKHComm^{\varphi}\bmod{\varAccPoKPComm}$. $\varAccPoKGComm$ and $\varAccPoKHComm$ are generators for sub-group $\expIntGroup{\varAccPoKQComm}$ of multiplicative group $\expIntGroup{\varAccPoKPComm}^{*}$, where $\varAccPoKQComm >2\mathfrak{B}$.
	\item $\varAccPoKProofComm{c}$, another commitment of $c$ with a random trapdoor $ \eta\in\expIntGroup{\lfloor N/4 \rfloor}$ such that $\varAccPoKProofComm{c}=\varAccPoKGProof^{c}\varAccPoKHProof^{\eta}\bmod{N}$. $\varAccPoKGProof$ and $\varAccPoKHProof$ are quadratic residues modulo $N$.
	\item $\varAccPoKProofComm{w}$, a commitment of the witness $w$ with a random trapdoor $ \epsilon\in\expIntGroup{\lfloor N/4 \rfloor}$ such that $\varAccPoKProofComm{w}=w\varAccPoKHProof^{\epsilon}\bmod{N}$.
	\item $\varAccPoKProofComm{r}$, a commitment of $\epsilon$ with a random trapdoor $\zeta\in\expIntGroup{\lfloor N/4 \rfloor}$ such that $\varAccPoKProofComm{r}=\varAccPoKGProof^{\epsilon}\varAccPoKHProof^{\zeta}\bmod{N}$.
\end{enumerate}

Like the parameters used in the accumulator (\S\ref{sec:3-Public Accumulator}), $\varAccPoKGComm,\varAccPoKHComm,\varAccPoKGProof,\varAccPoKHProof,\varAccPoKPComm,\varAccPoKQComm$ are public parameters that are generated once during set up. For simplicity of presentation, the modulus of the above commitments are omitted and implied. With these commitments, the prover implements the AccPoK by constructing a NIZK proof that shows that $\varAccPoKCoinComm$ and the accumulator $A$ contains the same $c$ in the following form:

\eqnAccPoKActual

The proof follows the standard flow of a NIZK proof described in \S\ref{sec:3-Transforming Interactive Zero Knowledge Proofs to NIZK Proofs}. Since there are 8 sub proofs in the NIZK proof, the prover first commits some random values $v_i$ to create commitments $\varAccPoKCoinComm,\varAccPoKProofComm{c},\varAccPoKProofComm{w},\varAccPoKProofComm{r}$ that are not related to,for each of the sub-proof. Following the principle of the Fiat-Shamir heuristics, the prover computes the challenge string $\varChallenge=H(\expConcatAccPoK)$ \footnote{$H$ denotes the SHA-256 hash function used by Zerocoin. $\|$ denotes a concatenation operation} and further computes $s_i$ that correspond to each $t_i$ using $\varChallenge$. The final $\varAccPoKCoinComm,\varAccPoKProofComm{c},\varAccPoKProofComm{w},\varAccPoKProofComm{r},t_i,s_i$ are written into the \kwTransaction{Spend }{} and broadcasted to the Zerocoin network to be verified. Upon receiving the \kwTransaction{Spend }{}, the nodes re-computes $\varChallenge=H(\expConcatAccPoK)$ using the received $\varAccPoKCoinComm,\varAccPoKProofComm{c},\varAccPoKProofComm{w},\varAccPoKProofComm{r},t_i,s_i$ and the public parameters $\varAccPoKGComm,\varAccPoKHComm,\varAccPoKGProof,\varAccPoKHProof$,. The verifier then verifies the proof by checking if each received $t_i$ equals to the $t'_i$ computed from $\varChallenge$ and $s_i$ using some verification formulas. The verification formulas are detailed in Appendix A of \cite{JanCamenisch12002}. The completeness, soundness and statistical zero-knowledge properties of the proof are also detailed in the \S3.3 of the same study.

\subsubsection{Serial Number Signature of Knowledge}
\label{sec:3-Serial Number Signature of Knowledge}
Proving that a \kwCoin{} has been accumulated in the public accumulator only shows that the prover knows some \kwCoin{} has been minted, but does not legitimise his ownership of the \kwCoin{}. Anyone who looks at the Blockchain can simply take a \kwCoin{} from any past \kwTransaction{Mint }{s}, obtain a witness for the \kwCoin{} using $GenWitness$ and construct a valid AccPoK for that \kwCoin{}. Hence, the creator of a \kwTransaction{Spend }{} must also prove that he owns the redeemed \kwCoin{}. This is done using the Serial Number Signature of Knowledge (SNSoK) where the prover proves that he knows the serial number $S$ and the random trapdoor $r$ that are committed a \kwCoin{} $c$ without disclosing $r$ and $c$. Since $r$ is secret to the owner of $c$ at all times, only the owner of the $c$ can produce a valid proof. This proof is a “signature” because it binds to the other contents of the \kwTransaction{Spend }{} such as the public key address of the payee. As the SNSoK becomes invalid once the contents of the \kwTransaction{Spend }{} changes, adversaries cannot tamper with the \kwTransaction{Spend }{}. Given the above objectives and constraints, the SNSoK in Zerocoin is as such:

$$\eqnSNSoK$$

The $m$ enclosed in the square brackets denotes the contents in the \kwTransaction{Spend }{} to be signed. As the serial number $S$ of the redeemed $c$ is disclosed in the proof, the trapdoor $r$ must be kept secret to prevent $c$ from being computed by observers of the Blockchain. The implementation of the SNSoK is adapted from the proof by Camenisch \cite{No1998}.

In order to hide $c$, the prover creates $y$, a Pedersen commitment of $c$ using a random trapdoor $z\in\expIntGroup{\varQSok}$, such that $y=\expSoKCoinComm{c}\bmod{\varPSok}=\expSoKCoinComm{\expPedCommCoin}\bmod{\varPSok}$. As per Pedersen commitment scheme, $\varGSok$ and $\varHSok$ are generators of the sub-group $\expIntGroup{\varQSok}$ of multiplicative group $\expMulGroup{\varPSok}$, and $\varQSok|\varPSok-1$. As the exponent in a Pederson commitment must be an element of $\expIntGroup{q}$ \cite{Pedersen1992}, $c\in\expIntGroup{\varQSok}$ and since $c$ is a value modulo $\varPComm$ (\S\ref{sec:3-Coin as a Pederson Commitment}), it is required that $\varQSok=\varPComm$. Like the parameters used in the Pedersen commitment for \kwCoin{s} (\S\ref{sec:3-Coin as a Pederson Commitment}), $\varGSok,\varHSok,\varPSok,\varQSok$ are public parameters that are generated once during set up. For simplicity of presentation, the modulus $\varPSok$ is omitted and implied for $\varGSok$ and $\varHSok$. With $y$, the prover implements the SNSoK by constructing a NIZK proof that shows that $y$ contains a $c$ that is a commitment to the serial number $S$ and trapdoor $r$ in the following form:

$$\eqnSNSoKActual$$

The flow of the NIZK proof is largely similar to the standard NIZK proof under the Fiat-Shamir heuristics described in \S\ref{sec:3-Non-Interactive Zero Knowledge (NIZK) Proofs}, but has a slightly different way of computing and using the challenge $\varChallenge$. The prover first creates $t_i$ for $i$ from 0 to $\varLambdaSec$ using random numbers $u_i\in\expIntGroup{\varQComm}$ and $v_i\in\expIntGroup{\varQSok}$ such that $t_i=\varGSok^{\varGComm^{S}\varHComm^{u_i}}\varHSok^{v_i}$. To ensure security, the Zerocoin paper recommends that $\varLambdaSec=80$ \footnote{Based on the security recommendations in Section VI(B) of the Zerocoin paper \cite{Miers2013}.}. Following the principle of the Fiat-Shamir heuristics, the prover then computes the challenge string $\varChallenge=H(\expConcatSNSoK)$. The inclusion of $m$ in the hash $\varChallenge$ ensures that the contents of the \kwTransaction{Spend }{} is bound to the challenge string. Any tampering with $m$ will cause $\varChallenge$ to be invalid and the proof fail. Thus $\varChallenge$ also serves as the signature for $m$. Using $\varChallenge$ the prover then computes $s_i$ and $s'_i$ in the following manner:

\begin{algorithm}
	\begin{algorithmic}[H]
		\For{$i\gets 1, \varLambdaSec$}
		\If{$i^{th}$ bit in $\varChallenge=0$}
		\State $s_i=(u_i-r)$; $s'_i=(v_i-z\varHComm^{u_i-r})$
		\Else
		\State $s_i=u_i$; $s'_i=v_i$
		\EndIf
		\EndFor
	\end{algorithmic}
\end{algorithm}

The prover writes $y,\varChallenge,t_1,\cdots,t_{\varLambdaSec},s_1,\cdots,s_{\varLambdaSec},s'_1,\cdots,s'_{\varLambdaSec}$ and the transaction content $m$ into the \kwTransaction{Spend }{} and broadcast it to the Zerocoin network to be verified. Upon receiving the \kwTransaction{Spend }{}, the nodes computes $\varChallenge'=H(\expConcatPrimeSNSoK)$ where:

\begin{algorithm}
	\begin{algorithmic}[H]
		\For{$i\gets 1, \varLambdaSec$}
		\If{$i^{th}$ bit in $\varChallenge'=0$}
		\State $t'_i=y^{\varHComm^{s_i}}\varHSok^{s'_i}$
		\Else
		\State $t_i=\varGSok^{\varGComm^{S}\varHComm^{s_i}}\varHSok^{s'_i}$
		\EndIf
		\EndFor
	\end{algorithmic}
\end{algorithm}

The proof is verified if and only if $\varChallenge'$ equals to the $\varChallenge$ received. In order for $\varChallenge'=\varChallenge$, it must be the case that $t_i=t'_i$ for $i$ from 1 to $\varLambdaSec$. In addition, the $m$ used to compute $\varChallenge'$ must also be the original $m$ used to compute $\varChallenge$, and thus $\varChallenge$ acts as the signature that preserves the integrity of $m$. The details of the SNSoK are taken from Appendix B of the Zerocoin paper. The completeness, soundness and statistical zero-knowledge properties of the proof are also detailed in the same paper.

\subsubsection{Commitment Proof of Knowledge}
\label{sec:3-Commitment Proof of Knowledge}
The AccPoK and SNSoK independently proves a certain property of a \kwCoin{}. However with only these two proofs, nothing is stopping one from constructing an AccPoK and a SNSoK for two different \kwCoin{s}. A dishonest user can exploit this by constructing a valid SNSoK for an arbitrary \kwCoin{} using an arbitrary serial number and secret trapdoor, and a valid AccPoK for any minted \kwCoin{} on the Blockchain (\S\ref{sec:3-Accumulator Proof of Knowledge}). Since the \kwCoin{s} in the two proofs are not known to the verifying nodes, the dishonest user is able to spend the arbitrary \kwCoin{}, and claim that it is the minted \kwCoin{} without being found out. This is analogous to the ability to printing money in real life. Hence there must be some way to ensure that the \kwCoin{s} being proven for in the AccPoK and SNSoK are the same \kwCoin{}. This is achieved using the Commitment Proof of Knowledge (CommPoK), where the prover proves that that commitment of the \kwCoin{} $\varAccPoKCoinComm=\varAccPoKGComm^{c}\varAccPoKHComm^{\varphi}$ used in the AccPoK contains the same $c$ as the commitment of the \kwCoin{} $y=\expSoKCoinComm{c}$ used in the SNSoK. Hence the CommPoK is implemented in the following form:

$$\eqnCommPoK$$

The CommPoK is an extension of the proof by Camenisch to prove for the equality of two secret keys \cite{No1998}. The proof follows the standard flow of a NIZK proof described in \S\ref{sec:3-Transforming Interactive Zero Knowledge Proofs to NIZK Proofs}. The prover first creates commitments $t_1=\varAccPoKGComm^{v_1}\varAccPoKHComm^{v_2}$ and $t_2=\varGSok^{v_1}\varHSok^{v_3}$ using random numbers $v_1,v_2,v_3$. Following the principle of the Fiat-Shamir heuristics, the prover computes the challenge string $\varChallenge=H(\expConcatCommPoK)$ and further computes $s_1=v_1+c\varChallenge$, $s_2=v_2+\varphi\varChallenge$ and $s_3=v_3+z\varChallenge$. The prover then includes $\varAccPoKCoinComm,y,t_1,t_2,s_1,s_2,s_3$ in the \kwTransaction{Spend }{} together with the other proofs and broadcasts the transaction to the Zerocoin network. Upon receiving the proof in the \kwTransaction{Spend }{}, the verifying nodes re-compute $\varChallenge=H(\expConcatCommPoK)$ using the received $\varAccPoKCoinComm,y,t_1,t_2$ and the public parameters $\varAccPoKGComm,\varAccPoKHComm,\varGSok,\varHSok$. The verifier then verifies the proof by checking if both equalities $t_1=\varAccPoKGComm^{s_1}\varAccPoKHComm^{s_2}\varAccPoKCoinComm^{-\varChallenge}$ and $t_2=\varGSok^{s_1}\varHSok^{s3}y^{-\varChallenge}$ are true. The completeness, soundness and statistical zero-knowledge properties of the proof are detailed in the study by Camenisch \cite{No1998}.

\subsubsection{Public Parameters}
\label{sec:3-Public Parameters}
A summary of the public parameters used in the Zerocoin protocol is listed in Table~\ref{tab:pub_params}. These parameters only need to be generated once during the setup of the Zerocoin system, and are subsequently used by all nodes for creating and verifying transactions.

\begin{table}[H]
	\centering \small
	\begin{tabular}{ l | m{2cm} | m{2.5cm} | m{5.5cm} }

		& \textbf{Public Parameter} & \textbf{Recommended value/size} & \textbf{Properties}\\
		\hline
		\hline
		\multirow{4}{*}{\textbf{Coin commitment}}
		& $\varPComm$ & 1024 bits & $\varQComm|\varPComm-1$ \\
		& $\varQComm$ & 256 bits & $\varQComm|\varPComm-1$ \\
		& $\varGComm$ & N.A. & Generator for sub-group $\expIntGroup{\varQComm}$ of multiplicative group $\expMulGroup{\varPComm}$ \\
		& $\varHComm$ & N.A. & Generator for sub-group $\expIntGroup{\varQComm}$ of multiplicative group $\expMulGroup{\varPComm}$ \\
		\hline
		\multirow{4}{*}{\textbf{Public Accumulator}}
		& $N$ & 3072 bits & Product of two large primes \\
		& $[\mathfrak{A},\mathfrak{B}]$ & N.A. & $[-\varPComm2^{k'+k''+2},\varPComm2^{k'+k''+2}]$ \\
		& $k$ & 160 & \\
		& $k'$ & 128 & \\
		\hline
		\multirow{6}{*}{\textbf{AccPoK/CommPoK}}
		& $\varAccPoKPComm$ & N.A.& $\varAccPoKQComm|\varAccPoKPComm-1$ \\
		& $\varAccPoKQComm$ & $>2\mathfrak{B}$ & $\varAccPoKQComm|\varAccPoKPComm-1$ \\
		& $\varAccPoKGComm$ & N.A. & Generator for sub-group $\expIntGroup{\varAccPoKQComm}$ of multiplicative group $\expMulGroup{\varAccPoKPComm}$ \\
		& $\varAccPoKHComm$ & N.A. & Generator for sub-group $\expIntGroup{\varAccPoKQComm}$ of multiplicative group $\expMulGroup{\varAccPoKPComm}$ \\
		& $\varAccPoKGProof$ & N.A. & Quadratic residue modulo $N$ \\
		& $\varAccPoKHProof$ & N.A. & Quadratic residue modulo $N$ \\
		\hline
		\multirow{5}{*}{\textbf{SNSoK/CommPoK}}
		& $\varLambdaSec$ & 80 & \\
		& $\varPSok$ & N.A. & $\varQSok|\varPSok-1$\\
		& $\varQSok$ & N.A. & Equals $\varPComm$ \\
		& $\varGSok$ & N.A. & Generator for sub-group $\expIntGroup{\varQSok}$ of multiplicative group $\expMulGroup{\varPSok}$\\
		& $\varHSok$ & N.A. & Generator for sub-group $\expIntGroup{\varAccPoKQComm}$ of multiplicative group $\expMulGroup{\varAccPoKPComm}$\\
		\hline
	\end{tabular}
	\caption{Public parameters used in Zerocoin}
	\label{tab:pub_params}
\end{table}

\section{Zerocoin Implementation: libzerocoin}
\label{sec:3-Zerocoin Implementation: libzerocoin}
The main protocols in Zerocoin have been implemented in C++ by the Zerocoin authors and the source code is publicly available on Github under the name of libzerocoin \footnote{Code repository can be accessed at https://github.com/Zerocoin/libzerocoin}. libzerocoin is not a full-fledged digital currency system. Instead, it is a library that provides the functions of setting up Zerocoin public parameters (\S\ref{sec:3-Public Parameters}), creating (\S\ref{sec:3-Coin as a Pederson Commitment}) and accumulating \kwCoin{s} (\S\ref{sec:3-Public Accumulator}) and constructing and verifying the various zero-knowledge proofs (\S\ref{sec:3-NIZK Proofs in Zerocoin}). Since libzerocoin has implemented all of the key elements of Zerocoin, it can be used to analyse the performance of the Zerocoin in isolation. More importantly, libzerocoin provides a comprehensive set of functions to generate protocol parameters and perform cryptography-related computations such as SHA-256 and modulo arithmetic on large numbers. This allows the high level protocol of Zerocoin to be modified without the need to meddle with the details, and makes implementing improvements convenient. Hence this research builds on the code base of libzerocoin to conduct tests and make potential improvements.

\section{Performance of Zerocoin and Areas for Improvement}
\label{sec:3-Performance of Zerocoin and Areas for Improvement}
libzerocoin has been modified to test the computational and storage requirements of the key data structures and algorithms in Zerocoin. The tests are conducted using the public parameter values and sizes recommended by the Zerocoin paper (Table \ref{tab:pub_params}). The machine used to run the tests is a \_\_\_\_. The results of the tests are shown in Table~\ref{tab:zerocoin_comp_storage}.

\begin{table}[H]
	\centering
	\begin{tabular}{ l | c | c }
		\multirow{2}{*}{} & \multicolumn{2}{c}{\textit{Average over 50 iterations}} \\
		& \textbf{Time taken} & \textbf{Size of output} \\
		\hline
		\hline
		Generation of public parameters & 849ms & 2578 bytes \\
		\hline
		Creation of one \kwCoin{} & 324ms & 199 bytes \\
		Accumulation of one \kwCoin{} & 39ms & 391 bytes (accumulator size) \\
		\hline
		Construction of one AccPoK & 146ms & \textbf{6,974 bytes} \\
		Construction of one SNSoK & 146ms & \textbf{17,420 bytes} \\
		Construction of one CommPoK & 5ms & 714 bytes \\
		\hline
		Verification of one AccPoK & \textbf{100ms} & N.A. \\
		Verification of one SNSoK & \textbf{163ms} & N.A. \\
		Verification of one CommPoK & 4ms & N.A. \\
		\hline
	\end{tabular}
	\caption{Computational and storage requirements of Zerocoin}
	\label{tab:zerocoin_comp_storage}
\end{table}

The results highlighted in bold are identified as the performance weaknesses of Zerocoin which this research aims to address. With reference to Table \ref{tab:zerocoin_comp_storage}, the next two sections elaborate on why these weaknesses are identified.

\subsubsection{Computational Performance}
\label{sec:3-Computational Performance}
The computations that affect the performance of Zerocoin the most are those which need to be carried out by the Zerocoin peer-to-peer network. For the generation of public parameters, the Zerocoin network does no incur any computational costs since the parameters are generated once by the trusted party that sets up the system. Thus the cost of generating public parameters is not considered a performance issue. The creation of \kwCoin{s} and the construction of the NIZK proofs are carried out by Zerocoin users whenever they want to make a transaction. Even though the time taken for these operations is in the order of hundreds of milliseconds, the computation requirement is contained within the individual users. As such \kwCoin{} creation and proofs construction do not impose on the peer-to-peer network, and its relatively high computation requirement is still acceptable.

The accumulation of \kwCoin{s} is performed by all nodes in the Zerocoin network as they need the most updated accumulator value to verify \kwTransaction{Spend }{s}. Although the 39ms taken to accumulate a \kwCoin{} is not small, nodes only need to accumulate the newly minted \kwCoin{s} to the previous accumulator each time a new \kwBlock{} is received since the accumulator can be incrementally computed (\S\ref{sec:3-Public Accumulator}). As blocks are only added to the Blockchain every 10 minutes (as per Bitcoin), nodes only need to periodically accumulate a small subset of the minted \kwCoin{s} in history. With this optimisation, the computational requirement to accumulate a \kwCoin{} is acceptable.

On the other hand, verification of NIZK proofs is done by all nodes in the Zerocoin network whenever they receive a \kwTransaction{Spend }{}. Thus the time needed to verify \kwTransaction{Spend }{s} grows linearly with the number of \kwTransaction{Spend }{s} received. The verification time of the AccPoK (100ms) and the SNSoK (163ms), which make up the bulk of the verification time of a \kwTransaction{Spend }{}, is an area of concern. In fact, the Zerocoin paper showed that the rate at which nodes verify transactions decreases by about half when only 12.5\% of all transactions in the network are \kwTransaction{Spend }{s} and the other 12.5\% and 75\% are \kwTransaction{Mint }{s} and standard Bitcoin transactions respectively \cite{Miers2013}. In addition, a node may need to verify the same \kwTransaction{Spend }{s} twice – once before it forwards the \kwTransaction{Spend }{} to its peers, and another time when a new \kwBlock{} containing the \kwTransaction{Spend }{} is received. The longer time taken by nodes to verify \kwTransaction{Spend }{s} increases the time taken for transactions to reach mining nodes and make it to the Blockchain, and slows the Zerocoin entire network. Thus, the inefficiency in verifying the AccPoK and the SNSoK is a serious limiting factor to Zerocoin’s performance, and this research aims to reduce the time taken to verify these proofs.

\subsubsection{Storage Requirements}
\label{sec:3-Storage Requirements}
Each node in Zerocoin stores a single copy of the public parameters, thus the 2.5KB of storage required by the public parameters is negligible. The other Zerocoin data structures need to be stored by nodes on a \kwTransaction{}{} or \kwBlock{} basis as part of the Blockchain, and their sizes affect the storage requirements of Zerocoin significantly. The rest this section uses Bitcoin as a point of reference to demonstrate the storage implications of Zerocoin.

The accumulator is stored on a \kwBlock{} level. As of October 2016, the average size of one \kwBlock{} in Bitcoin is about 0.8MB \cite{Blockchain.info2016}. Thus an additional accumulator of 391 bytes for each \kwBlock{} has negligible effect on the \kwBlock{} size. On the other hand, a \kwCoin{} is stored in each \kwTransaction{Mint }{}, while the AccPoK, SNSoK and CommPoK are stored in each \kwTransaction{Spend }{}. As of 2015, the average size of one standard Bitcoin \kwTransaction{}{} in is 566 bytes \cite{TradeBlock2015}. For simplicity of analysis, the Zerocoin data structures are added to the standard Bitcoin \kwTransaction{}{} to estimate the size of Zerocoin transactions. As such, a \kwTransaction{Mint }{} is bigger than a Bitcoin \kwTransaction{}{} by the size of a \kwCoin{} (199 bytes), and a \kwTransaction{Spend }{} is bigger than a Bitcoin \kwTransaction{}{} by the total size of the AccPoK, SNSoK and CommPoK (25KB). This means that a \kwTransaction{Mint }{} increases transaction size by 35\% while a \kwTransaction{Spend }{} increases transaction size by 4,400\%.

While a 35\% increase in size for a \kwTransaction{Mint }{} is still reasonable, a 44-fold increase in size for a \kwTransaction{Spend }{} is undesirable. To illustrate, if \kwTransaction{Spend }{s} make up just 10\% of all the transactions on the Blockchain, the total size of the transactions on the Blockchain will increase by 4.4 times. Since transactions make up the bulk of Blockchain stored in every node, the Zerocoin protocol imposes an enormous storage requirement compared to Bitcoin. In addition, the large size of the Zerocoin transaction also slows down the propagation of transactions in the network. As a result, Zerocoin transactions takes longer to reach the mining nodes and make it to the Blockchain, and slows down the entire Zerocoin network. Since the \kwTransaction{Spend }{} contributes significantly the storage requirements and the AccPoK (6974 bytes) and the SNSoK (17,420 bytes) make up the bulk of a \kwTransaction{Spend }{}, this research aims to reduce the size of the AccPoK and SNSoK to improve the overall performance of Zerocoin.


\documentclass[a4paper]{article}

\input{temp}

\begin{document}

\title{Markov Chains}

\maketitle

\newpage

\tableofcontents

\newpage

\section{Markov Chain}
The notes taken during the first lecture was unfortunately lost.

\begin{thm} (Extended Markov Property) Let $X$ be a Markov chain, and $n \geq 0$. Let $H$ be an event defined in terms of $X_0,...,X_{n-1}$ (the history), and let $F$ be an event defined in terms of $X_{n+1},X_{n+2},...$ (the future). Then
\begin{equation*}
\begin{aligned}
\P \left(F|H,X_n = i\right) = \P \left(F|X_n = i\right)
\end{aligned}
\end{equation*}
\end{thm}

\newpage

\section{Transition Probabilities}
We've known that $p_{i,j}$ is the one-step transition probability,
\begin{equation*}
\begin{aligned}
\P\left(X_{n+1} = j|X_n = i\right) = \P\left(X_1 = j|X_0 = i\right)
\end{aligned}
\end{equation*}
Now it's natural to discuss the $n$-step transition probabilities
\begin{equation*}
\begin{aligned}
\P\left(X_n = j| X_0 = i\right) = p_{i,j}\left(n\right)
\end{aligned}
\end{equation*}

\begin{thm} (Chapman-Kolmogorov Equations)
\begin{equation*}
\begin{aligned}
p_{i,j}\left(m+n\right) = \sum_{k \in S} p_{i,k}\left(m\right)p_{k,j}\left(n\right)
\end{aligned}
\end{equation*}
\begin{proof}
\begin{equation*}
\begin{aligned}
p_{i,j}\left(m+n\right) &= \sum_{k\in S} \P\left(X_{m+n} = j|X_m=k\right) \P\left(X_m=k\right)\\
&= \sum_{k\in S} p_{k,j} \left(n\right) p_{i,k} \left(m\right)
\end{aligned}
\end{equation*}
\end{proof}
\end{thm}

Now let $P\left(1\right) = P = p_{i,j}$, $P\left(n\right) = p_{i,j}\left(n\right)$. Then this is just matrix multiplication: $P\left(n\right) = P^n$. To find $P\left(n\right)$ we can diagonalize the matrix. (or matrix mult + qpower!)

\begin{eg}
Let $S=\left\{1,2\right\}$,
\begin{equation*}
\begin{aligned}
P= \left(\begin{matrix}
1-\alpha & \alpha\\
\beta & 1-\beta
\end{matrix}\right)
\end{aligned}
\end{equation*}
ans assume that $0<\alpha,\beta<1$ (non-trivial).\\
Then solve $|P-\kappa I|=0$, we get $\kappa = 1$ or $\kappa = 1-\alpha - \beta$. So
\begin{equation*}
\begin{aligned}
P^n = U^{-1}\left(\begin{matrix}
1^n & 0\\
0 & \left(1-\alpha-\beta\right)^n
\end{matrix}\right)U
\end{aligned}
\end{equation*}
for some invertible $U$. Then
\begin{equation*}
\begin{aligned}
p_{1,1}\left(n\right) = A \cdot 1^n + B\left(1-\alpha-\beta\right)^n
\end{aligned}
\end{equation*}
for some $A,B$. We know that $p_{1,1}\left(1\right) = 1-\alpha$, $p_{1,1}\left(0\right) = 1$. Then we can solve for $A$ and $B$ and get
\begin{equation*}
\begin{aligned}
A=\frac{\beta}{\alpha+\beta},B=\frac{\alpha}{\alpha+\beta}
\end{aligned}
\end{equation*}
By symmetry we can get
\begin{equation*}
\begin{aligned}
P^n = \frac{1}{\alpha+\beta} \left(\begin{matrix}
\beta+\alpha\left(1-\alpha-\beta\right)^n & \alpha-\alpha\left(1-\alpha-\beta\right)^n\\
\beta-\beta\left(1-\alpha-\beta\right)^n & \alpha+\beta\left(1-\alpha-\beta\right)^n
\end{matrix}\right)
\end{aligned}
\end{equation*}

Another method is to use difference equations:
\begin{equation*}
\begin{aligned}
p_{1,1}\left(n+1\right) &= \P \left(X_{n+1} = 1|X_0=1\right)\\
&= \P \left(X_{n+1} = 1|X_n = 1,X_0=1\right) \P\left(X_n=1|X_0=1\right) + \\&\P\left(X_{n+1}=1|X_n=2,X_0=1\right) \P\left(X_n = 2|X_0=1\right)\\
&= \left(1-\alpha\right) P_{1,1}\left(n\right) + \beta p_{1,2}\left(n\right)
\end{aligned}
\end{equation*}
which is a difference equation for the sequence for $\left(p_{1,1}\left(n\right)\right)$ (note $p_{1,2}\left(n\right) = 1-p_{1,1}\left(n\right)$) solved in the normal way, subject to boundary conditions.
\end{eg}

The distributions of a Markov chain is somewhat related to linear algebra. Let $\lambda$ be the initial distribution of $X_0$, i.e. $\lambda_i = \P \left(X_0 = i\right)$. Then
\begin{equation*}
\begin{aligned}
\P\left(X_1=j\right) = \sum_i \lambda_i p_{i,j}
\end{aligned}
\end{equation*}
So the distribution of $X_1$ is $\lambda P$, and similarly $X_n$ has distribution $\lambda P^n$.

\newpage

\section{Class Structure}
We write "$i$ leads to $j$", or $i \to j$, if there exists $n \geq 0$ s.t. $p_{i,j}\left(n\right) > 0$. Write $i \leftrightarrow j$ if $i\to j$ and $j\to i$, and say that $i$ and $j$ \emph{communicate}.

\begin{prop}
$\leftrightarrow$ is an equivalence relation.
\begin{proof}
$\bullet$ $i \leftrightarrow i$ since $p_{i,i}\left(0\right) = 1 > 0$.\\
$\bullet$ $i \leftrightarrow j \to j \leftrightarrow i$ is trivial.\\
$\bullet$ If $i \leftrightarrow j$ and $j \leftrightarrow i$, in particular $i\to j$ and $j\to k$. Then there exists $m,k$ such that $p_{i,j}\left(m\right) > 0$ and $p_{j,k}\left(n\right) > 0$. Then
\begin{equation*}
\begin{aligned}
p_{i,k}\left(m+n\right) \geq p_{i,j}\left(m\right) p_{j,k}\left(n\right) > 0
\end{aligned}
\end{equation*}
By C-K equation (since each term in the sum is non-negative). So $i\to k$. Similarly $k\to i$. So $i \leftrightarrow k$.
\end{proof}
\end{prop}

\begin{defi}
Now $S$, the set of all states, has equivalence classes under $\leftrightarrow$. We call them \emph{communicating classes}, and define
\begin{equation*}
\begin{aligned}
C_i = \left\{ j \in S: i \leftrightarrow j\right\}
\end{aligned}
\end{equation*}

The space $S$, or the chain $X$, is called \emph{irreducible} if there exists a unique communicating class (which is $S$).

$C \subset S$ is called \emph{closed} if
\begin{equation*}
\begin{aligned}
i\in C, i\to j \implies j \to C
\end{aligned}
\end{equation*}
if $\left\{i\right\}$ is closed, then $i$ is called \emph{absorbing}.
\end{defi}

\begin{prop}
A set $C$ is closed if and only if $p_{i,j} = 0$ for all $i \in C, j \not\in C$.
\begin{proof}
Suppose the above condition does not hold. Then $\exists i \in C, j \not\in C$ with $p_{i,j} > 0$. But then $C$ is not closed by definition since $i \to j$.\\
Now suppose the above condition hold. Let $i \in C,i \to j$. There exists several $k_0 = i, k_1,...,k_n = j$ such that
\begin{equation*}
\begin{aligned}
p_{k_0,k_1} p_{k_1,k_2}...p_{k_{n-1},k_n} > 0
\end{aligned}
\end{equation*}
which requires $i=k_0 \to k_1$, $k_1 \to k_2$, ... $k_{n-1} \to k_n=j$. Then $k_1 \in C, k_2 \in C,... k_n = j\in C$. So $C$ is closed.
\end{proof}
\end{prop}

\begin{eg}
Let $S = \left\{1,2,...,6\right\}$, and
\begin{equation*}
\begin{aligned}
P = \left(
\begin{matrix}
\frac{1}{2} & \frac{1}{2} & 0 & 0 & 0 & 0\\
0 & 0 & 1 & 0 & 0 & 0\\
\frac{1}{3} & 0 & 0 & \frac{1}{3} & \frac{1}{3} & 0\\
0 & 0 & 0 & \frac{1}{2} & \frac{1}{2} & 0\\
0 & 0 & 0 & 0 & 0 & 1\\
0 & 0 & 0 & 0 & 1 & 0
\end{matrix}
\right)
\end{aligned}
\end{equation*}
Here $\left\{1,2,3\right\}$, $\left\{4\right\}$, $\left\{5,6\right\}$ are communicating classes.
\end{eg}

\newpage

\section{Recurrence and Transience}
We write $\P\left( \cdot | X_0 = i\right) = \P_i \left(\cdot\right)$, and similarly for expectation.

\begin{defi}
The \emph{first-passage time} of $j \in S$ is
\begin{equation*}
\begin{aligned}
T_j = \inf\left\{n \geq 1: X_n = j\right\}
\end{aligned}
\end{equation*}

The \emph{first-passage probabilities} are
\begin{equation*}
\begin{aligned}
f_{i,j}\left(n\right) = \P_i \left(T_j=n\right)
\end{aligned}
\end{equation*}
\end{defi}

\begin{defi}
The state $i \in S$ is \emph{recurrent} (or \emph{persistent}) if $\P_i\left(T_i < \infty\right) = 1$, and \emph{transient} otherwise.
\end{defi}

\begin{thm}
The state $i$ is recurrent if and only if
\begin{equation*}
\begin{aligned}
\sum_n p_{ii}\left(n\right) \to \infty.
\end{aligned}
\end{equation*}
\begin{proof}
We have
\begin{equation*}
\begin{aligned}
p_{ij}\left(n\right) = \P_i\left(x_n=j\right) &= \sum_m \P_i\left(x_n=j | T_j = m\right) \P_i\left(T_j=m\right)\\
&= \sum_{m \leq n} \P_i \left(x_n = j|x_m=j\right) \P_i\left(T_j=m\right)\\
&=\sum_{m=1}^n f_{i,j}\left(m\right) p_{jj}\left(n-m\right)
\end{aligned}
\end{equation*}
(which looks like a \emph{convolution} of $f_{i,j}$ and $p_{jj}$).

Now consider generating sequences
\begin{equation*}
\begin{aligned}
F_{ij}\left(s\right) = \sum_{n=0}^\infty f_{ij}\left(n\right) s^n\\
P_{ij}\left(s\right) = \sum_{n=0}^\infty p_{ij}\left(n\right) s^n
\end{aligned}
\end{equation*}
with $f_{ij}\left(0\right)=0$,$p_{ij}\left(0\right) = \delta_{ij}$.

Then
\begin{equation*}
\begin{aligned}
\sum_{n\geq 1} p_{ij}\left(n\right)s^n = \sum_{n\geq 1} \sum_{m=1}^n f_{ij}\left(m\right)s^m p_{jj}\left(n-m\right)s^{n-m}
\end{aligned}
\end{equation*}
So by reversing the order of the sums,
\begin{equation*}
\begin{aligned}
P_{ij}\left(s\right) - \delta_{ij} = \sum_{m=0}^\infty f_{ij}\left(m\right) s^m \sum_{n=m}^\infty p_{jj}\left(n-m\right)s^{n-m} = F_{ij}\left(s\right)P_{jj}\left(s\right)
\end{aligned}
\end{equation*}
So we've derived
\begin{thm}
$P_{ij}\left(s\right) = \delta_{ij} + F_{ij}\left(s\right)P_{jj}\left(s\right)$. ($1 < s \leq 1$, since we need the series to converge)\\
When $i=j$,
\begin{equation*}
\begin{aligned}
P_{ii}\left(s\right) = \frac{1}{1-F_{ii}\left(s\right)}
\end{aligned}
\end{equation*}
if $0\leq s < 1$.\\
Now let $s \to 1$, then
\begin{equation*}
\begin{aligned}
F_{ii}\left(s\right) \to \sum_n f_{ii}\left(n\right) = \P_i\left(T_i < \infty\right),\\
P_{ii}\left(s\right) \to \sum_n p_{ii}\left(n\right)
\end{aligned}
\end{equation*}
Therefore $i$ is recurrent iff $F_{ij}\left(s\right) = 1$, i.e. $\sum_n p_{ii}\left(n\right) \to \infty$.
\end{thm}
\end{proof}
\end{thm}

\begin{thm}
Let $C$ be a communicating class.\\
(a) For $i,j \in C$, either both of them are recurrent, or both are transient (i.e. recurrence is a class property).\\
(b) If $i\in C$ is recurrent, then $C$ is closed (i.e. a recurrent communicating class is closed).
\begin{proof}
(a) Let $i \leftrightarrow j$. Then
\begin{equation*}
\begin{aligned}
p_{ii}\left(m+k+n\right) \geq p_{ij}\left(m\right)p_{jj}\left(k\right)p_{ji}\left(n\right)
\end{aligned}
\end{equation*}
Pick $m$ s.t. $p_{ij}\left(m\right)>0$, and $n$ s.t. $p_{ji}\left(n\right)>0$. Then
\begin{equation*}
\begin{aligned}
\sum_k p_{ii}\left(m+k+n\right) \geq \alpha\sum_k p_{jj}\left(k\right)
\end{aligned}
\end{equation*}
for $\alpha > 0$.\\
Then if $j$ is recurrent, then $\sum_k p_{jj}\left(k\right) \to \infty$, and hence $\sum_k p_{ii}\left(k\right) \to \infty$, i.e. $i$ is recurrent, and vice versa.

(b) Suppose $C$ is not closed. So $\exists j \in C$, $k \not\in C$ with $p_{jk} > 0$.\\
If $i$ is recurrent, so is $j$ by (a). Then
\begin{equation*}
\begin{aligned}
1 - \P_j\left(T_j<\infty\right) = \P_j \left(\text{no return to } j\right) \geq p_{jk}
\end{aligned}
\end{equation*}
Since $k \not\in C$. However that implies $p_{jk} \leq 1-1 = 0$. Contradiction.
\end{proof}
\end{thm}

\begin{prop}
Let $i,j\in S$. If $j$ is transient, then $p_{ij}\left(n\right) \to 0$ as $n \to \infty$.
\begin{proof}
$P_{ij}\left(s\right) = \delta_{ij} + F_{ij}\left(s\right) P_{jj}\left(s\right)$ for $-1 <s<1$.\\
Now let $i \neq j$, and $s \to 1$. Then
\begin{equation*}
\begin{aligned}
P_{ij}\left(1\right) = F_{ij}\left(1\right) P_{jj}\left(1\right)
\end{aligned}
\end{equation*}
Since $j$ is transient, $F_{ij}\left(1\right) < \infty$ and $P_{jj}\left(1\right) < \infty$.\\
So $P_{ij}\left(n\right) < \infty$, and hence $p_{ij}\left(n\right) \to 0$ as $n \to \infty$.\\
The argument is similar when $i=j$.
\end{proof}
\end{prop}

\begin{thm}
If $S$ is finite, then there exists at least one recurrent state. Therefore, if the chain is irreducible, every state is recurrent.
\begin{proof}
Suppose otherwise, that every $j$ is transient. Then we have
\begin{equation*}
\begin{aligned}
1 = \sum_{j \in S} p_{ij}\left(n\right) \to 0
\end{aligned}
\end{equation*}
as $n \to \infty$. Contradiction.
\end{proof}
\end{thm}

\newpage

\section{Random walks on $\Z^d$ with $d \geq 1$}

We consider random walks on
\begin{equation*}
\begin{aligned}
\Z^d = \left\{\left(x_1,...,x_d\right):x_i \in \Z\right\}
\end{aligned}
\end{equation*}

Define two points $x,y\in\Z^d$: $x = \left(x_1,...,x_d\right)$, $y=\left(y_1,...,y_d\right)$ to be \emph{adjacent} if
\begin{equation*}
\begin{aligned}
\sum_{i=1}^d \left|x_i-y_i\right| = 1
\end{aligned}
\end{equation*}

The \emph{Random walk} on $\Z^d$ is a Markov chain with state space $\Z^d$; a walker lives at $X_n$ at time $n$, with
\begin{equation*}
\begin{aligned}
\P\left(X_{n+1}=y\right) | X_n = x,X_0 = x\left(0\right),...,X_{n-1} = x\left(n-1\right) = \left\{ \begin{array}{ll} 0 & x,y \text{ are not adjacent}\\
\frac{1}{2d} & x,y \text{ are adjacent}
\end{array}
\right.
\end{aligned}
\end{equation*}

Clearly RW is irreducible and has an infinite state space.

\begin{thm}
The random walk is recurrent if $d = 1,2$, and transient if $d \geq 3$.
\begin{proof}
$\bullet$ $d=1$: $p_{0,0}\left(2n\right) = \left(\frac{1}{2}\right)^{2n} {2n \choose n} = \left(\frac{1}{2}\right)^{2n} \frac{2n!}{\left(n!\right)^2} \sim \frac{1}{\sqrt{\pi n}}$ by Stirling formula.\\
Hence $\sum_n p_{0,0}\left(n\right) \to \infty$, i.e. $0$ is recurrent.

$\bullet$ $d=2$: Suppose we walked $m$ steps towards L/R, and $n-m$ steps towards U/D.
\begin{equation*}
\begin{aligned}
p_{0,0} \left(2n\right) &= \sum_{m=0}^n \left(\frac{1}{4}\right)^{2n} \frac{\left(2n\right)!}{m!m!\left(n-m\right)!\left(n-m\right)!}\\
&= \left(\frac{1}{4}\right)^{2n} {2n \choose n} \sum_{m=0}^n {n \choose m}^2\\
&= \left(\frac{1}{4}\right)^{2n} {2n \choose n}\\
&\sim \frac{1}{\pi n}
\end{aligned}
\end{equation*}
So $\left(0,0\right)$ is recurrent.

$\bullet$ $d=3$ (and similarly $d \geq 3$):\\
\begin{equation*}
\begin{aligned}
p_{0,0}\left(2n\right) &= \sum_{i+j+k=n} \left(\frac{1}{6}\right)^{2n} \frac{\left(2n\right)!}{\left(i!j!k!\right)^2}\\
&\leq \left(\frac{1}{2}\right)^{2n} {2n \choose n} \sum_{i+j+k=n} \left(\frac{n!}{3^n i!j!k!}\right)^2\\
&\leq \left(\frac{1}{2}\right)^{2n} {2n \choose n} M_n \sum_{i+j+k=n} \frac{n!}{3^n i!k!l!}
\end{aligned}
\end{equation*}
where
\begin{equation*}
\begin{aligned}
M_n=\max\left\{\frac{n!}{3^n i!j!k!} | i+j+k=n\right\}
\end{aligned}
\end{equation*}
The sum in the last line is $1$, since each term in the sum is the probability of $n$ balls goes in to 3 boxes, with $i,j,k$ balls in each box.\\
We see that $M_n$ is achieved when $i,j,k$ are 'as equal as possible. Then
\begin{equation*}
\begin{aligned}
p_{0,0}\left(2n\right) &\leq \left(\frac{1}{2}\right)^2n {2n \choose n} \frac{n!}{3^n \left(\lfloor n/3\rfloor !\right)^3}\\
&\sim \frac{c}{n^{3/2}}
\end{aligned}
\end{equation*}
But this sum now converges. So $\left(0,0,0\right)$ is transient.
\end{proof}
\end{thm}

\newpage

\section{Hitting probabilities}

\subsection{Gambler's Ruin}
What is the hitting probability for gambler's ruin, $h_i = h_i^{\left\{0\right\}}$?

$h_0=1$, $h_i = ph_{i+1} + qh_{i-1}$ for $i \geq 1$.

Then guess a solution $h_i = \theta^i$, so $\theta = q/p,1$. So the general solution is
\begin{equation*}
\begin{aligned}
h_i = A+B\left(q/p\right)^i
\end{aligned}
\end{equation*}
for all $i$.

Since $h_0=1$, $A+B=1$.

If $p<q$: since the $h_i$ are probability, $B=0$, $A=1$. So $h_i = 1-\left(q/p\right)^i$ for all $i$.

If $p>q$, since$h_i \geq 0$ for all $i$, we have $A \geq 0$. By minimality of $\left(h_i\right)$, $A=0$. So $h_i = \left(q/p\right)^i$.

When $p=q$: by the above arguments, $h_i \equiv 1$.

Extension: let $p_i = 1-q_i \in \left(0,1\right)$.

So $h_0=1$, $\left(p_i+q_i\right)h_i = p_i h_{i+1} + q_i h_{i-1}$. $p_i\left(h_{i+1} - h_i\right) = q_i \left(h_i-h_{i-1}\right)$.

Let $u_i = h_{i-1} - h_i$. Then $p_i u_{i+1} = q_i u_i$. So $u_{i+1} = \left(q_i/p_i\right)u_i$.

Therefore $u_{i+1}\gamma_i u_1$, where
\begin{equation*}
\begin{aligned}
\gamma_i = \frac{q_1 q_2...q_i}{p_1 p_2 ... p_i}
\end{aligned}
\end{equation*}
for $i \geq 1$, and $\gamma_0 = 1$. Then
\begin{equation*}
\begin{aligned}
u_1+u_2+...+u_i = \left(h_0-h_i\right)\\
h_i = 1-\left(u_1+...+u_i\right)=1-u_1\left(\gamma_0+\gamma_1+...+\gamma_{i-1}\right)
\end{aligned}
\end{equation*}

Let $S = \sum_{i=0}^\infty \gamma_i$. If $S=\infty$, since $h_1\geq 0$ we have $u_1 = 0$, and hence $h_i \equiv 1$.

If $S < \infty$, $u_1$ is maximised when $1-u_1 S = 0$, i.e. $u_1 = 1/S$.

\newpage

\section{Stopping times}

Consider Markov chain $X$.

\begin{defi}
A random variable $T$ taking values in $\left\{0,1,2,...,\right\}\cup\left\{\infty\right\}$ is a \emph{stopping time} (for $X$) if for $n\geq 0$, the event $\left\{T=n\right\}$ is given 'in terms of' $X_0$, $X_1$,...,$X_n$ only.
\end{defi}

Hitting times are stopping times: $\left\{H^A = n\right\} = \left\{X_n \in A \right\} \cap \left(\cap_{0\leq m< n} \left\{x_m \not\in A\right\}\right)$.

$H^A+1$ is a stopping times is a stopping time, $H^A-1$ is not in general a stopping time.

\begin{defi} (Strong Markov Property) Let $X$ be a Markov chain with transition matrix $P$, and let $T$ be a stopping time for $X$. Given $T<\infty$ and $X_T = i$, then $Y=\left(X_T,X_{T+1},...\right)$ is a Markov chain with transition matrix $P$ and initial state $Y_0 = i$, and $Y$ is independent of $\left(X_0,...,X_{T-1}\right)$.
\end{defi}

\begin{eg}
Consider a random walk with an absorbing wall at $0$,with probability $p$ going right and $q=1-p$ going left. Assume particle starts at $1$, and let $H$ be the hitting time of $0$. What is the mass function and mean of $H$?

Let
\begin{equation*}
\begin{aligned}
G\left(s\right) = \E_1\left(s^H\right) = \sum_{n=0}^\infty s^n \P_1\left(H=n\right)
\end{aligned}
\end{equation*}
if $|s|<1$.

By assuming $|s|<1$ (and using Abel's lemma when needed) we include the possibility $\P_1\left(H=\infty\right)>0$. Then
\begin{equation*}
\begin{aligned}
G\left(s\right) &= \E_1\left(s^H\right)\\
&= \E_1\left(s^H | X_1=2\right)p + \E_1\left(s^H | X_1 = 0\right)q\\
&= p\E_1\left(s^{1+H_1+H_0}\right)+qs\\
&= psG\left(s\right)^2(=\E_1\left(s^{H_1}\right)\E_1\left(s^{H_2}\right)) + qs
\end{aligned}
\end{equation*}
where $H_i$ is the time to go from $i+1$ to $i$.

So
\begin{equation*}
\begin{aligned}
G\left(s\right) = \frac{1 \pm \sqrt{1-4pqs^2}}{2ps}
\end{aligned}
\end{equation*}
for $|s|<1$.

Since $G$ is continuous, the $\pm$ sign is the same for all $s$. Since $G$ has to remain regular at $s=0$, the $\pm$ sign has to be $-$ for all $s$. So
\begin{equation*}
\begin{aligned}
G\left(s\right) = \frac{1-\sqrt{1-4pqs^2}}{2ps}
\end{aligned}
\end{equation*}
So
\begin{equation*}
\begin{aligned}
\P_1\left(H=2k-1\right)=\frac{\left(2k-2\right)!}{k!\left(k-1\right)!} \frac{\left(pq\right)^k}{p}
\end{aligned}
\end{equation*}
where $k \geq 1$.

We can also get
\begin{equation*}
\begin{aligned}
P\left(H<\infty\right) &= \lim_{s \to 1} G\left(s\right)\\
&= \frac{1-\sqrt{1-4pq}}{2p}\\
&= \frac{1-|q-p|}{2p}\\
&= \left\{\begin{array}{ll}
1 & p\leq q\\
q/p & p>q
\end{array}
\right.
\end{aligned}
\end{equation*}

Now let $p\leq q$. We want to find $\E_1\left(H\right)$. Differentiate $G$,

\begin{equation*}
\begin{aligned}
G'=pG^2+2psGG'+q\\
\implies G'\left(s\right) = \frac{pG^2+q}{1-2psG}
\end{aligned}
\end{equation*}

Take the limit $s \to 1$,
\begin{equation*}
\begin{aligned}
G'\left(s\right) \to \left\{ \begin{array}{ll}
\infty & p=q\\
\frac{1}{q-p} & p<q
\end{array}
\right.
\end{aligned}
\end{equation*}

\end{eg}

\newpage

\section{Classification of states}

\begin{defi}
(a) The \emph{mean recurrence time} of $i\in S$ is
\begin{equation*}
\begin{aligned}
\mu_i &= \E_i\left(T_i\right)\\
&=\left\{\begin{array}{ll}
\infty & i \text{ is transient}\\
\sum_{n\geq 1} n f_{i,i}\left(n\right) & i \text{ is recurrent}
\end{array}
\right.
\end{aligned}
\end{equation*}

(b) We call $i$ \emph{null} if $\mu_i = \infty$, and \emph{non-null} or \emph{positive} if $\mu_i < \infty$.

(c) The \emph{period} $d_i$ of $i \in S$ is $d_i = \gcd\left\{ n \geq 1 : p_{i,i} \left(n\right) > 0\right\}$.\\
We call $i$ \emph{aperiodic} if $d_i = 1$.

(d) A state $i \in S$ ie \emph{ergodic} if it is aperiodic and non-null recurrent.
\end{defi}

\begin{thm}
If $i \leftrightarrow j$ then\\
(a) they have the same period;\\
(b) if one is recurrent, so is the other;\\
(c) if one is positive recurrent, so is the other;\\
(d) if one is ergodic, so is the other.
\end{thm}

\end{document}


\author{Florian Müller}
\graphicspath{ {./src/chapters/developer/media/ld_live/} }
\section {opencv}

opencv can be installed via pip and used via \texttt{import cv2}.
For the scripts here, the \texttt{opencv-contrib-python} package was loaded and imported as cv.

All examples are thus called only with cv and not with cv2.

\subsection {Blur}

\texttt{image = cv.blur(img, kernel)}

The function \texttt{blur()} is used to soften an image.
A kernel is applied to each pixel in the image and computed.

This kernel is a normalized matrix filled with ones.
As an example a 3x3 normalized matrix can be considered here:

$$Kernel = \frac{1}{9}
\begin{bmatrix}
1 &1 &1 \\
1 &1 &1 \\
1 &1 &1
\end{bmatrix}
$$

\subsection {Dilate and Erode}

\texttt{kernal = cv.getStructuringElement(cv.MORPH\_ELLIPSE, (x-size, y-size))}

\texttt{dilated\_image = cv.dilate(image, kernel)}

\texttt{eroded\_image = cv.erode(image, kernel)}

Dilation and erosion are very similar to describe.
In both operations an image $A$ will be convolved with a kernel $B$.
The usage of both functions are removing noise, isolate individual elements, closing gaps in images.

The dilation or grow function is used to let an image grow in the directions of the kernel.
But it is also possible to set the anchor of the kernal not to the centre but to a different point.
Then it is possible to let the picture grow or shrink in a specific direction.
e.g.:

\texttt{cv.dilate(image, kernel, anchor = (1,1))}

For the erosion the same kernel can be used.
And instead of letting the image grow, with an erosion the image will shrink.
This can be used to eliminate noise or separate elements which are barely touching.

The function itself is passed two parameters and then returns a modified image.

The opencv docs contain a good explanation\\
\url{https://docs.opencv.org/3.4/db/df6/tutorial\_erosion\_dilatation.html}

\subsection{Convert Color}

\texttt{image = cv.cvtColor(image, flag)}

During the color conversion the function receive two arguments and returns the converted picture.
The first argument is the image to convert.
The second argument is the flag which conversion shall be used.
For this project only the \texttt{BGR2GRAY} and \texttt{RGB2BGR} flags are used.

\subsection{Threshold}

\texttt{threshold, image = cv.threshold(image, min, max, flag)}

Threshold is used to remove some noise and to convert the image to a binary format.
This function receive four arguments and returns two outputs.
The first output is the used threshold and the second is the thresholded picture.

The first input is the image to be thresholded, which should be already converted to grayscale.
\texttt{min} is the actual threshold which determines if a pixel is set to zero or to the \texttt{max} value.
The flags will determine which threshold algorithm will be used.
The two mainly used flags are \texttt{cv.THRESH\_OTSU} and \texttt{cv.THRESH\_BINARY\_INV}.

\texttt{cv.THRESH\_BINARY\_INV} is the simpler one of both.
After calculating the threshold for each pixel the resulting image will be inverted.
This kind of image can be used for further processing.

\texttt{cv.THRESH\_OTSU} is a more complex algorithm.
During the thresholding process the \texttt{min} value will be calculated automatically.
The \texttt{cv.THRESH\_OTSU} flag has to be set as an extra flag to the already given flag.
Now the \texttt{min} value will be substitued by the Otsu's calculated value.

\subsection{Find Contours}

\texttt{contours, hirachy = cv.findContours(image, return\_flag, approximation\_flag)}

A contour can be understood as a curve joining all pixels of the same value like color or intensity.
The function receives three arguments and returns two outputs.
For the outputs the first is a list with points for the contours.
The second one is a list with the same length as the first one with values determing the neighbours and the depth of the contour.

The fist argument is the image in with the contours will be searched.
For best computing time it is recommended to use a grayscale or binary image.
The second argument determine which kind of list of contours will be returned.
The three recommended flags are \texttt{cv.RETR\_LIST}, \texttt{cv.RETR\_TREE} and \texttt{cv.RETR\_EXTERNAL}.
For this project the \texttt{cv.RETR\_EXTERNAL} flag is the mostly used.
With this flag only the top level contours will be returned without inner contours.
The third argument determines how many points will be used for the contour.
The flag \texttt{cv.CHAIN\_APPROX\_NONE} is the commonly used to detect all points of a contour.
This makes it possible to draw a perfect mask for each found symbol.
% TODO an example would be nice

\begin{figure}[H]
    \centering
    \includegraphics[width=.8\textwidth]{line10000.png}
    \includegraphics[width=.8\textwidth]{mask10005.png}
    \includegraphics[width=.8\textwidth]{01result.png}
    \caption{Example for masking one letter}
\end{figure}

\subsection{Bounding Rectangle}

\texttt{x, y, w, h = cv.boundingRect(contour)}

For each contour this function will output the bounding rectangle.
It is possible to draw the rectangle or cut the area.
For letterdetection this is used to cut out the individual charakters after the masking process.

\subsection{arcLength and approxPolyDP}

\texttt{epsilon = value * cv.arcLength(contour, bool)}

\texttt{approximation = cv.approxPolyDP(contour, epsilon, bool)}

These functions are used to approximate a contour which isn't in a perfect shape.
For example a square which isn't detected correctly can be found with this approximation.
The \texttt{cv.arcLength()} function returns the length of a contour.
The bool values dertermine if the contour is closed or just a curve.
The \texttt{cv.approxPolyDP()} function is an implementation of the Ramer-Douglas-Peucker algorithm.
In a nutshell it will calculate a contour with lesser points than the original given contour.
For more information about this algorithm please visit \url{https://en.wikipedia.org/wiki/Ramer\_Douglas\_Peucker\_algorithm}.


\chapter{Case Study}
\label{chapter4}

\graphicspath{{Chapter4/figs/}}

This chapter focuses on discussing about a possible analysis path with MLExplore.js for one real-world dataset. In general terms, this path consist of two stages: (1) Load the dataset and perform a first overview for gaining a general understanding about this, (2) iteratively navigate the data and perform attribute selection and train multiple t-SNE and K-Means models for identifying local and global structural changes (cluster formation) in the data, and (3) explain the results in terms of the original attributes by observing their distribution among clusters or predefined classes and selecting some data instances of interest for perform neighbors analysis.

The SALURBAL dataset is introduced in \ref{section1.1}. An additional detail about this dataset is the complexity of the attributes reflecting Urban Landscape, Street Design and Transportation domains for the 1.433 Latin American sub-cities included in the study. Researchers currently have used Finite Mixture Models for the Urban Landscape and Street Design domains to determine profiles emerging from the sub-cities. The first challenge consist of determining the set of hyper-parameters that enables the identification of representative profiles based on entropy and Bayesian Information Criterion. The second challenge is about determining differences among profiles and naming them.

Figure \ref{fig:salurbal-case-study-1} shows MLExplore.js after the user loads the SALURBAL dataset and by default a t-SNE model is trained using all numerical attributes. Thanks to Navio, it is possible to evidence that many attributes are highly correlated and some others have a high missing value ratio. TRANS\_PROF is the categorical attribute automatically selected for color encoding. This attribute represents the Street Design profile previously obtained using the Finite Mixture Models. User can also use URBAN\_PROF (Urban Landscape profile) for color encoding selecting this attribute in the upper-right combobox of the Attribute Selection component.

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.9\textwidth]{salurbal-case-study-1.png}
 \caption{First iteration in MLExplore.js for the SALURBAL dataset.}
 \label{fig:salurbal-case-study-1}
\end{figure}

For both domains, just a subset of attribute are selected for training the models: Street density, Intersection density, Streets per node average, Street length average and circuity average, for Street Density, and Number of urban patches, Patch density, Area-weighted mean patch size, Effective mesh size, Area-weighted mean shape index and Area-weighted mean nearest neighbor distance, for Urban Landscape. MLExplore.js is updated for including in each case only these attributes and training again the t-SNE models with the same hyper-parameters: 20 for perplexity and 5 for learning rate. Figure \ref{fig:salurbal-case-study-2} evidences the embedding results for this interaction with the Attribute Selection component.

\begin{figure}[ht]
 \centering
 \includegraphics[width=1.0\textwidth]{salurbal-case-study-2.png}
 \caption{t-SNE for Street Design (left) and Urban Landscape (right) selected attributes.}
 \label{fig:salurbal-case-study-2}
\end{figure}

Because the visually identified clusters for both domains seems to be so granularized, dominating local data structure, perplexity t-SNE hyper-parameter can be increased to obtain a more compact group. According to Figure \ref{fig:salurbal-case-study-3}, for perplexity equal to 50, the resulting embedding is able to locate instances of the same cluster near, as the case of the red cluster in the Street Design embedding (left) and the brown cluster in the Urban Landscape embedding (right). Reasons behind the difficulty of finding an embedding that better reflects the profiles could be that Finite Mixture Models and t-SNE optimize in a different way and the same domain complexity. While Finite Mixture Models is a probabilistic model, t-SNE learns from similarity metrics such as euclidean distance. Maybe, K-Means could works better with the t-SNE for producing clusters that can be visually identified in a more clear way.

\begin{figure}[ht]
 \centering
 \includegraphics[width=1.0\textwidth]{salurbal-case-study-3.png}
 \caption{t-SNE for Street Design (left) and Urban Landscape (right) selected attributes when increasing perplexity to 50.}
 \label{fig:salurbal-case-study-3}
\end{figure}

Two new t-SNE and K-Means models for Street Design and Urban Landscape domains are trained. Figure \ref{fig:salurbal-case-study-4} shows the result for the Street Design profile where K-Means clusters are better identified in the t-SNE embedding with less cluster overlapping in comparison with profiles from the Finite Mixture Models. In Attribute Distribution component is possible to observe that the cluster orange characterizes by high values of Street density while the cluster green by high values in Intersection density and Streets per node average. Unfortunately, K-Means evidences some limitations when instances have outlier values tending to create an independent cluster for that few instances. In this case, Colon, Panama, having a very high Circuity average. Urban Landscape domain, Figure \ref{fig:salurbal-case-study-5}, have a similar problem creating two clusters with very few sub-units.

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.8\textwidth]{salurbal-case-study-4.png}
 \caption{t-SNE and K-Means for Street Design selected attributes and clustering results in the Attribute Distribution panel.}
 \label{fig:salurbal-case-study-4}
\end{figure}

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.8\textwidth]{salurbal-case-study-5.png}
 \caption{t-SNE and K-Means for Urban Landscape selected attributes and clustering results in the Attribute Distribution panel.}
 \label{fig:salurbal-case-study-5}
\end{figure}


    \filetitle{hpf}{Hodrick-Prescott filter with tunes (aka LRX filter)}{tseries/hpf}

	\paragraph{Syntax}\label{syntax}

\begin{verbatim}
[T,C,CutOff,Lambda] = hpf(X)
[T,C,CutOff,Lambda] = hpf(X,Range,...)
\end{verbatim}

\paragraph{Syntax with output arguments
swapped}\label{syntax-with-output-arguments-swapped}

\begin{verbatim}
[C,T,CutOff,Lambda] = hpf2(X)
[C,T,CutOff,Lambda] = hpf2(X,Range,...)
\end{verbatim}

\paragraph{Input arguments}\label{input-arguments}

\begin{itemize}
\item
  \texttt{X} {[} tseries {]} - Input tseries object that will be
  filtered.
\item
  \texttt{Range} {[} numeric {]} - Date Range on which the input data
  will be filtered; \texttt{Range} can be \texttt{Inf},
  \texttt{{[}startdata,Inf{]}}, or \texttt{{[}-Inf,enddate{]}}; if not
  specifired, \texttt{Inf} (i.e.~the entire available Range of the input
  series) is used.
\end{itemize}

\paragraph{Output arguments}\label{output-arguments}

\begin{itemize}
\item
  \texttt{T} {[} tseries {]} - Low-frequency (trend) component.
\item
  \texttt{C} {[} tseries {]} - High-frequency (cyclical or gap)
  component.
\item
  \texttt{CutOff} {[} numeric {]} - Cut-off periodicity; periodicities
  above the cut-off are attributed to trends, periodicities below the
  cut-off are attributed to gaps.
\item
  \texttt{Lambda} {[} numeric {]} - Smoothing parameter actually used;
  this output argument is useful when the option \texttt{'cutoff='} is
  used instead of \texttt{'lambda='}.
\end{itemize}

\paragraph{Options}\label{options}

\begin{itemize}
\item
  \texttt{'cutoff='} {[} numeric \textbar{} \emph{empty} {]} - Cut-off
  periodicity in periods (depending on the time series frequency); this
  option can be specified instead of \texttt{'lambda='}; the smoothing
  parameter will be then determined based on the cut-off periodicity.
\item
  \texttt{'cutoffYear='} {[} numeric \textbar{} \emph{empty} {]} -
  Cut-off periodicity in years; this option can be specified instead of
  \texttt{'lambda='}; the smoothing parameter will be then determined
  based on the cut-off periodicity.
\item
  \texttt{'gamma='} {[} numeric \textbar{} tseries \textbar{} \emph{1}
  {]} - Weight or weights on the deviations of the trend from
  observations; it only makes sense to use this option to make the
  signal-to-noise ratio time-varying; see the optimisation problem
  below.
\end{itemize}

\texttt{'infoSet='} {[} \texttt{1} \textbar{} \emph{\texttt{2}} {]} -
Information set assumption used in the filter: \texttt{1} runs a
one-sided filter, \texttt{2} runs a two-sided filter.

\begin{itemize}
\item
  \texttt{'lambda='} {[} numeric \textbar{} \emph{\texttt{@auto}} {]} -
  Smoothing parameter; needs to be specified for tseries objects with
  indeterminate frequency. See Description for default values.
\item
  \texttt{'level='} {[} tseries {]} - Time series with hard tunes and
  soft tunes on the level of the trend.
\item
  \texttt{'change='} {[} tseries {]} - Time series with hard tunes and
  soft tunes on the change in the trend.
\item
  \texttt{'log='} {[} \texttt{true} \textbar{} \emph{\texttt{false}} {]}
  - Logarithmise the data before filtering, de-logarithmise afterwards.
\end{itemize}

\paragraph{Description}\label{description}

\subparagraph{The underlying optimisation
problem}\label{the-underlying-optimisation-problem}

The function \texttt{hpf} solves a constrained optimisation problem
described by the following Lagrangian

\[\min_{\bar y_t, \omega_t, \sigma_t}
\underbrace{
\tsum \lambda \left( \Delta \bar y_t - \Delta \bar y_{t-1} \right)^2
+ \tsum \gamma_t \left( \bar y_t - y_t \right)^2}_\text{Plain HP with
time-varying signal-to-noise ratio} + \cdots\] \[\cdots +
\underbrace{\tsum u_t \left( \bar y_t - a_t \right)^2}_\text{Soft level tunes}
+ \underbrace{\tsum v_t \left( \Delta \bar y_t - b_t
\right)^2}_\text{Soft growth tunes} +
\underbrace{\tsum \omega_t \left( \bar y_t - c_t \right)}_\text{Hard level tunes}
+ \underbrace{\tsum \sigma_t \left( \Delta \bar y_t - d_t
\right)}_\text{Hard growth tunes},\]

where

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  $\Delta$ is the first-difference operator;
\item
  $\lambda$ is a (scalar) smoothing parameter;
\item
  $y_t$ are user-supplied observations;
\item
  $\bar y_t$ is the fitted trend;
\item
  $\gamma_t$ are user-supplied weights to modify the basic
  signal-to-noise ratio over time (the default setting is $\gamma_t=1$),
  entered in the option \texttt{'gamma='};
\item
  $a_t$ and $u_t$ are soft tunes on the level of the trend and the
  weights associated with these soft level tunes, respectively, entered
  together as complex numbers in the option \texttt{'level='};
\item
  $b_t$ and $v_t$ are soft tunes on the change in the level of the trend
  and the weights associated with these soft growth tunes, respectively,
  entered together as complex numbers in the option \texttt{'growth='};
\item
  $c_t$ are hard tunes on the level of the trend, entered as real
  numbers in the option \texttt{'level='};
\item
  $d_t$ are hard tunes on the change in the level of the trend, entered
  as real numbers in the option \texttt{'growth='};
\item
  $\omega_t$ are lagRange multipliers on the hard level tunes (note that
  these are computed as part of the optimisation problem, not entered by
  the user);
\item
  $\sigma_t$ are lagRange multipliers on the hard growth tunes (note
  that these are computed as part of the optimisation problem, not
  entered by the user).
\end{itemize}

Each of the summations in the above Lagrangian goes over those periods
in which the respective bracketed terms are defined (observations or
tunes exist). You can combine any number of any tunes in one run of
\texttt{hpf}, including out-of-sample tunes (see below).

\subparagraph{How to enter the tunes}\label{how-to-enter-the-tunes}

\begin{itemize}
\item
  The hard tunes and soft tunes on the level of the trend are entered as
  time series through the option \texttt{'level='}.
\item
  The hard tunes and soft tunes on the change in the trend are entered
  as time series through the option \texttt{'change='}.
\item
  In the tseries objects entered through \texttt{'level='} and/or
  \texttt{'change='}, you can combine any number of hard and soft tune.
  In each particular period, you can obviously specify only a hard tune
  or only a soft tune. You can think of hard tunes as a special case of
  soft tunes with infinitely large weights.
\item
  A hard tune is specified as a plain real number (i.e.~a number with a
  zero complex part).
\item
  A soft tune must be entered as a complex number whose real part
  specifies the tune itself, and the imaginary part specifies the
  \emph{inverse} of the weight, i.e. $1/v_t$ or $1/u_t$, on that tune in
  that period. Note that if the weight goes to infinity, the imaginary
  part becomes zero and the tune becomes a hard tune.
\end{itemize}

\subparagraph{Out-of-sample tunes}\label{out-of-sample-tunes}

Tunes can be imposed also at dates before the first observation of the
input series, or after the last observation. In other words, the time
series in \texttt{'level='} and/or \texttt{'growth='} can have a more
extended Range (at either side) than the filtered input series.

\subparagraph{Default smoothing
parameters}\label{default-smoothing-parameters}

If the user does not specify the smoothing parameter using the
\texttt{'lambda='} option (or reassigns the default \texttt{@auto}), a
default value is used. The default value is based on common practice and
can be calculated using the date frequency of the input time series as
$\lambda = 100 \cdot f^2$, where $f$ is the frequency (yearly=1,
half-yearly=2, quarterly=4, bi-monthly=6, monthly=12). This gives the
following default values:

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  100 for yearly time series (cut-off periodicity of 19.79 years);
\item
  400 for half-yearly time series (cut-off periodicity of 14.02 years);
\item
  1,600 for quarterly time series (cut-off periodicity of 9.92 years);
\item
  3,600 for bi-monthly time series (cut-off periodicity of 8.11 years);
\item
  14,400 for monthly time series (cut-off periodicity of 5.73 years).
\end{itemize}

Note that there is no default value for data with indeterminate or daily
frequency: for these types of time series, you must always use the
option ``lambda=''.

\paragraph{Example}\label{example}