diff --git a/network-privacy-assessment/.gitignore b/network-privacy-assessment/.gitignore
new file mode 100644
index 0000000..d98ff3e
--- /dev/null
+++ b/network-privacy-assessment/.gitignore
@@ -0,0 +1,14 @@
+*.bbl
+*.bbg
+*.blg
+*.aux
+*.log
+*.out
+*.nav
+*.snm
+*.toc
+*~
+*.swp
+*.pyc
+*.pyo
+__pycache__
diff --git a/network-privacy-assessment/Makefile b/network-privacy-assessment/Makefile
new file mode 100644
index 0000000..2649a54
--- /dev/null
+++ b/network-privacy-assessment/Makefile
@@ -0,0 +1,16 @@
+LATEX = pdflatex
+BIBTEX = bibtex
+MAIN = network-privacy
+
+all: $(MAIN).pdf
+
+$(MAIN).pdf: $(MAIN).tex $(MAIN).bbl
+	while $(LATEX) $(MAIN) && grep -q "Rerun to get" $(MAIN).log ; do true; done
+
+$(MAIN).bbl: $(MAIN).bib
+	$(LATEX) $(MAIN)
+	$(BIBTEX) $(MAIN)
+
+clean:
+	rm -f *.bbl *.blg network-privacy.pdf *.aux *.log *.out
+
diff --git a/network-privacy-assessment/README.md b/network-privacy-assessment/README.md
new file mode 100644
index 0000000..330222e
--- /dev/null
+++ b/network-privacy-assessment/README.md
@@ -0,0 +1,5 @@
+# Technical Report for Zcash Threat Model and Network Privacy Assessment
+
+This is a work-in-progress project to formalize the threat model for Zcash and
+perform an assessment as to the privacy improvements that can be offered by
+different network privacy mechanisms.
diff --git a/network-privacy-assessment/network-privacy.bib b/network-privacy-assessment/network-privacy.bib
new file mode 100644
index 0000000..d1b4624
--- /dev/null
+++ b/network-privacy-assessment/network-privacy.bib
@@ -0,0 +1,169 @@
+@misc{zcash-spec,
+  author = {Daira Hopwood and Sean Bowe and Taylor Hornby and Nathan Wilcox},
+  title = {{Zcash Protocol Specification}},
+  howpublished = {\url{https://github.com/zcash/zips/blob/master/protocol/protocol.pdf}},
+  note = {
+    {last accessed 2020-05-29}
+  },
+  year = {2020}
+}
+
+@misc{light-wallet-spec,
+  author = {George Tankersley, Jack Grigg},
+  title = {{Light Client Protocol for Payment Detection}},
+  howpublished = {\url{https://github.com/gtank/zips/blob/light_payment_detection/zip-XXX-light-payment-detection.rst}},
+  note = {
+    {last accessed 2020-05-29}
+  },
+  year = {2018}
+}
+
+
+@misc{katzenpost,
+  author = {Yawning Angel and George Danezis and Claudia Diaz and Ania Piotrowska and David Stainton},
+  title = {{Katzenpost Mix Network Specification}},
+  howpublished = {\url{https://katzenpost.mixnetworks.org/docs/specs/mixnet.html}},
+  note = {
+    {last accessed 2019-12-16}
+  },
+  year = {2017}
+}
+
+@inproceedings{Dingledine2004TorTS,
+  title={{Tor: The Second-Generation Onion Router}},
+  author={Roger Dingledine and Nick Mathewson and Paul F. Syverson},
+  booktitle={USENIX Security Symposium},
+  year={2004}
+}
+
+@inproceedings{Piotrowska:2017:LAS,
+ author = {Piotrowska, Ania M. and Hayes, Jamie and Elahi, Tariq and Meiser, Sebastian and Danezis, George},
+ title = {{The Loopix Anonymity System}},
+ booktitle = {Proceedings of the 26th USENIX Conference on Security Symposium},
+ series = {SEC'17},
+ year = {2017},
+ pages = {1199--1216},
+ numpages = {18},
+ url = {http://dl.acm.org/citation.cfm?id=3241189.3241283},
+ acmid = {3241283},
+ publisher = {USENIX Association},
+}
+
+@misc{fanti2018dandelion,
+    title={Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees},
+    author={Giulia Fanti and Shaileshh Bojja Venkatakrishnan and Surya Bakshi and Bradley Denby and Shruti Bhargava and Andrew Miller and Pramod Viswanath},
+    year={2018},
+    eprint={1805.11060},
+    archivePrefix={arXiv},
+    primaryClass={cs.CR}
+}
+
+@InProceedings{anon-bitcoin,
+author="Koshy, Philip
+and Koshy, Diana
+and McDaniel, Patrick",
+editor="Christin, Nicolas
+and Safavi-Naini, Reihaneh",
+title="An Analysis of Anonymity in Bitcoin Using P2P Network Traffic",
+booktitle="Financial Cryptography and Data Security",
+year="2014",
+publisher="Springer Berlin Heidelberg",
+address="Berlin, Heidelberg",
+pages="469--485",
+isbn="978-3-662-45472-5"
+}
+
+
+@misc{dandelion,
+    title={Dandelion: Redesigning the Bitcoin Network for Anonymity},
+    author={Shaileshh Bojja Venkatakrishnan and Giulia Fanti and Pramod Viswanath},
+    year={2017},
+    eprint={1701.04439},
+    archivePrefix={arXiv},
+    primaryClass={cs.CR}
+}
+
+@article{BojjaVenkatakrishnan:2017:DRB,
+ author = {Bojja Venkatakrishnan, Shaileshh and Fanti, Giulia and Viswanath, Pramod},
+ title = {{Dandelion: Redesigning the Bitcoin Network for Anonymity}},
+ journal = {Proc. ACM Meas. Anal. Comput. Syst.},
+ issue_date = {June 2017},
+ volume = {1},
+ number = {1},
+ month = jun,
+ year = {2017},
+ issn = {2476-1249},
+ pages = {22:1--22:34},
+ articleno = {22},
+ numpages = {34},
+ url = {http://doi.acm.org/10.1145/3084459},
+ doi = {10.1145/3084459},
+ acmid = {3084459},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {bitcoin, cryptocurrencies},
+}
+
+@article{Fanti:2018:DLC,
+ author = {Fanti, Giulia and Venkatakrishnan, Shaileshh Bojja and Bakshi, Surya and Denby, Bradley and Bhargava, Shruti and Miller, Andrew and Viswanath, Pramod},
+ title = {{Dandelion++: Lightweight Cryptocurrency Networking with Formal
+   Anonymity Guarantees}},
+ journal = {Proc. ACM Meas. Anal. Comput. Syst.},
+ issue_date = {June 2018},
+ volume = {2},
+ number = {2},
+ month = jun,
+ year = {2018},
+ issn = {2476-1249},
+ pages = {29:1--29:35},
+ url = {http://doi.acm.org/10.1145/3224424},
+ doi = {10.1145/3224424},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {anonymity, cryptocurrencies, p2p networks},
+}
+
+@misc{tor-specification,
+  author = {Roger Dingledine and Nick Mathewson},
+  title = {{Tor Protocol Specification}},
+  howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt}},
+  note = {
+    {last accessed 2020-06-22}
+  },
+  year = {2020}
+}
+
+
+@article{pir,
+author = {Chor, Benny and Kushilevitz, Eyal and Goldreich, Oded and Sudan, Madhu},
+title = {Private Information Retrieval},
+year = {1998},
+issue_date = {Nov. 1998},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {45},
+number = {6},
+issn = {0004-5411},
+url = {https://doi.org/10.1145/293347.293350},
+doi = {10.1145/293347.293350},
+journal = {J. ACM},
+month = nov,
+pages = {965–981},
+numpages = {17}
+}
+
+
+@article{JAWAHERI2020101684,
+title = "Deanonymizing Tor hidden service users through Bitcoin transactions analysis",
+journal = "Computers \& Security",
+volume = "89",
+pages = "101684",
+year = "2020",
+issn = "0167-4048",
+doi = "https://doi.org/10.1016/j.cose.2019.101684",
+url = "http://www.sciencedirect.com/science/article/pii/S0167404818309908",
+author = "Husam Al Jawaheri and Mashael Al Sabah and Yazan Boshmaf and Aiman Erbad",
+keywords = "Bitcoin, Tor hidden services, Privacy, Deanonymization, Attack",
+}
+
+
diff --git a/network-privacy-assessment/network-privacy.pdf b/network-privacy-assessment/network-privacy.pdf
new file mode 100644
index 0000000..51549a7
Binary files /dev/null and b/network-privacy-assessment/network-privacy.pdf differ
diff --git a/network-privacy-assessment/network-privacy.tex b/network-privacy-assessment/network-privacy.tex
new file mode 100644
index 0000000..afad456
--- /dev/null
+++ b/network-privacy-assessment/network-privacy.tex
@@ -0,0 +1,804 @@
+\documentclass{article}
+
+\usepackage{amsthm, amsfonts, amssymb, amsmath, graphicx, cancel, framed}
+\usepackage{mathtools}
+\usepackage{multicol}
+\usepackage{multirow}
+\usepackage{amsmath}
+\usepackage{amsfonts, txfonts}
+\usepackage{ifsym}
+
+\usepackage{commath}
+\usepackage{amsthm}
+\usepackage{caption}
+\captionsetup[figure]{font=small,belowskip=-10pt}
+\captionsetup[figure]{font=small,aboveskip=3pt}
+\usepackage{wasysym}
+
+\usepackage[hyphens]{url}
+\urlstyle{same}
+\usepackage{xifthen}
+\usepackage[usenames,svgnames,table]{xcolor}
+
+\setlength{\marginparsep}{8pt}
+\setlength{\marginparwidth}{40pt}
+\setlength{\marginparpush}{5pt}
+\newcounter{mn}
+\setcounter{mn}{1}
+\newcommand{\superscript}[1]{\ensuremath{{}^{\textrm{\scriptsize #1}}}}
+\newcommand{\roughtext}[1]{\begin{color}{SkyBlue}#1\end{color}}
+\newcommand{\mntext}[1]{\colorbox{SkyBlue}{\begin{color}{black}#1\end{color}}}
+\newcommand{\mn}[2][]{{\tiny\superscript{\mntext{\arabic{mn}}}}\marginpar{\scriptsize{
+  \ifthenelse{\isempty{#1}}
+  {\mntext{\parbox{0.95\marginparwidth}{\superscript{\arabic{mn}}~\raggedright{#2}}}}
+  {\mntext{\parbox{0.95\marginparwidth}{\superscript{\arabic{mn}}#1 says:~\raggedright{#2}}}}
+}}\stepcounter{mn}}
+
+\newcommand\supth{\ensuremath{^{\textrm{\scriptsize th}}}}
+
+
+
+\title{Zcash Network Privacy Assessment}
+\author{The Zcash Foundation}
+
+\begin{document}
+
+    \maketitle
+\section{Introduction}
+
+The amount of data leaked about individuals online is ever growing; and
+financial data in particular
+provides a highly granular lens about personal daily habits.
+Zcash is a cryptocurrency that ensures strong financial
+privacy for users by leveraging zero-knowledge proofs and randomization
+techniques~\cite{zcash-spec} to
+protect against data leakage that could otherwise lead to deanonymization of a
+payer or
+recipient of Zcash. Use of zero-knowledge proofs in this manner ensures that
+the raw bytes of a Zcash \emph{shielded} transaction cannot leak identifiable
+information about the payer, payee, or amount.
+
+However, an adversary observing the Zcash network
+could perform passive or active attacks with the goal of linking
+users and their end recipients, even if that adversary cannot decrypt the Zcash
+shielded transaction directly. Consequently, ensuring additional mechanisms to
+protect against network-level adversaries seeking to deanonymize users is
+important.
+
+In this technical report, we assess the capabilities of such nework
+adversaries, and present a more formal assessment of network privacy Zcash
+users, with a focus on \textit{shielded
+transactions}. We identify what is considered sensitive information in the Zcash
+ecosystem, potential adversaries, and enumerate several attack vectors.
+We then consider several
+network privacy mechanisms and assess the extent to which these
+mechanisms improve the privacy and security of Zcash users. Finally, we
+identify near-term and long-term recommendations for improvements.
+
+\textit{Organization}.
+We begin in Section~\ref{background} by discussing background information
+useful to understanding the network privacy that Zcash ensures for users. In
+Section~\ref{observations}, we describe the difference between adversarial
+network models in blockchains as opposed to other applications such as web
+browsing or email. In
+Section~\ref{threat-model}, we introduce a basic threat model for Zcash.
+In Section~\ref{network-privacy-review} we describe the network
+privacy mechanisms that we include in our assessment, and in
+Section~\ref{network-privacy-assessment} we perform this assessment.
+In Section~\ref{future-improvements} we outline furture improvements we are
+planning to implement, and we conclude in Section~\ref{conclusion}.
+
+\section{Background} \label{background}
+
+\subsection{Zcash Shielded Transactions}
+\label{shielded}
+
+While Zcash does allow for use of unshieleded transactions, in this technical
+report we focus on assessing the network privacy for users assuming the use of shielded
+transactions. However, we will now briefly describe
+the difference between the two transaction types.
+As mentioned before, unshielded transactions are similar
+to Bitcoin transactions, and expose the pseudonyms of the payer, payee, and the
+amount paid. When this information is exposed to the network and persisted
+indefinitely to the Blockchain, it is effectively ``Twitter for your bank
+account''.
+
+Shielded transactions, on the other hand, expose what is essentially a “one
+time pad” to a network observer. Because not only the transaction information
+is encrypted, the encryption process itself is randomized such that two
+transactions that have identical payers, payees, and transaction amounts result
+in bytes that are completely indistinguishable from randomly-generated bytes.
+In other words, given only a series of shielded transactions, an adversary
+would not be able to gain enough information to distinguish any
+\emph{personally identifiable} information about the transaction plaintext.
+
+In other words, while nodes \emph{can} observe information about transactions
+such as timing or other fingerprintable network-level anomalies, we are
+concerned with the capability of an attacker to use information to tie a
+\emph{particular} transaction to \emph{both} its sender and receiver's
+real-world identities.
+
+
+\subsection{Comparison of Zcash Privacy Expectations to Bitcoin}
+
+While Zcash provides the ability to make shielded transactions to completely
+hide the information contained within a transaction, users of Zcash can also
+make non-shielded transactions. Because Zcash is a fork of Bitcoin,
+non-shielded transactions consequently have effectively the same expectation of
+privacy as plain Bitcoin transactions, which had been proven to be insecure
+against deanonymization attacks~\cite{anon-bitcoin}. In this post, we will
+focus on evaluating the setting when shielded transactions.
+
+While both Zcash and Bitcoin have future goals of
+stable Tor integration and other network-privacy mechanisms, this routing via
+an anonymity layer does not prevent attacks that examine the bytes of the
+transaction itself. So unshielded transactions in Zcash and all Bitcoin
+transactions leak information to a network observer, which can be exploited to
+perform deanonymization attacks. Further, use of network privacy tools may not
+completely mitigate deanonymization attacks against unshielded
+transactions~\cite{JAWAHERI2020101684}.
+
+\subsection{Zcash Protocol for Producing and Receiving Transactions}
+
+\textbf{Producing a Transaction (Spending Funds)}.
+A user wishing to spend
+funds can publish a new transaction to the network in several ways. The user
+could operate a \emph{full node}, meaning this node also participates in all
+network behaviour, such as gossiping transactions, responding to queries for
+the current state of the network, etc.
+
+The user can also spend funds via a \emph{light
+client} by publishing their transaction to a
+\emph{light wallet node}, which itself is a full node which additionally can handle
+light wallet functionality. Note that while publishing a transaction to a light
+wallet, the user exposes the fact that they are making a Zcash transaction (as
+the light wallet learns a particular transaction, along with the IP address of
+the user). However, the light wallet will not learn the identity of the
+receiver of the funds~\cite{light-wallet-spec}.
+
+\textbf{Receiving a Transaction (Accepting Funds)}. A user receiving a
+transaction similarly has two options for how to receive these funds, either
+via a full node or via a light wallet node.
+
+An important point to emphasize that because Zcash is a broadcast protocol (all
+full nodes sync the full state of the network), a user receiving transactions
+via a full node will not expose which transaction they are interested in
+receiving. In other words, because full nodes maintain the complete blockchain,
+they will not leak to any external party which blocks they require in order to
+process receiving of funds.
+
+Similarly, a user fetching transactions from a light wallet will also fetch all
+block headers and therefore not expose which transaction they are interested
+in. However, one slight exception exists for clients that wish
+to learn the full details of a transaction (such as the memo field). For this
+case,
+they must query the light wallet for those details separately. As such, the
+light wallet can link a recipient to a particular transaction in the case the
+user queries for extended transaction fields for a specific block~\cite{light-wallet-spec}.
+
+\section{Observations on End-to-End Network Attacks against Blockchains}
+\label{observations}
+
+We now describe several observations that we made while assessing the
+end-to-end network
+privacy of blockchains, where network state
+is published and synced to a globally consistent data store such as a blockchain. We contrast
+these observations with threats that are typical for a applications where users
+are browsing the web, exchanging email, or engaging in a messaging platform,
+for example.
+
+As stated previously, we assume the use of \emph{shielded} transactions for the
+below analysis.
+
+\textbf{Observation One: PoW Consensus adds more significantly more
+end-to-end latency than web application traffic.}
+While different cryptocurrency networks have a range of consensus mechanisms,
+in Zcash and other proof-of-work (POW) networks today, the latency
+between when a transaction is published and when that transaction is included
+into the Zcash blockchain is upwards of one minute~\cite{zcash-faq}.
+
+Hence, network privacy mechanisms that are tuned for lower-latency applications
+such as web applications will not meaningfully protect against end-to-end
+timing attacks in blockchains that use a PoW-based consensus. While such
+network privacy mechanisms may frustrate an attacker seeking to deanonymize
+only one end of the transaction (such as a mixnet preventing a node from
+identifying the source node that published the transaction), this use case in
+the setting for Zcash does not allow for end-to-end correlation.
+
+Hence, unless network privacy mechanisms that are indended to frustrate
+end-to-end timing attacks
+(such as mixnets) impose more latency than the blockchain consensus
+protocol itself, such mechanisms do not add additional
+meaningful protection against \emph{end-to-end} timing correlation attack.
+
+Such an observation extends to any network privacy mechanism that adds noise,
+such as generating dummy packets or transactions, as it is unclear how noise
+can be generated and distributed in a truly end-to-end setting.
+
+\textbf{Observation Two: Performing end-to-end correlation attacks in
+blockchains require attacking a broadcast network, not a point-to-point link.}
+In a setting such as accessing content online or sending messages or emails,
+application traffic is sent from a sender to receiver, proxied through a series
+of servers. In this setting, an adversary could perform end-to-end correlation
+attacks in a number of ways, such as observing distinguishing identifiable
+patterns as information enters and leaves the network. The latency of these
+applications is important, as faster transmission can increase the possibility for
+timing correlation attacks, but so are other factors such as the pattern of
+packets or exposed metadata.
+
+However, blockchains create a different landscape for an attacker that
+wishes to perform \emph{end-to-end} correlation attacks. Namely, blockchains require
+that transactions are \emph{first} included in the blockchain (the global state
+of the network), only \emph{after} which the receiver of the funds can learn
+about the transaction.
+
+
+\textbf{Takeaways}
+While adversaries can certainly perform \emph{end-to-end} attacks in a blockchain
+setting, the above observations indicate that doing so requires different
+adversarial models than in other application settings such as for web traffic or email
+applications. Hence, we do not consider end-to-end timing or packet correlation
+attacks when evaluating general-purpose network privacy tools such as Tor or
+general-purpose mixnets in this assessment of network privacy for Zcash in the setting where
+shielded transactions are used.
+
+
+\section{Analysis of Attack Vectors in Zcash}
+\label{threat-model}
+
+We now assess attack vectors relevant to Zcash. We define the information of
+interest to an attacker as the below tuple.
+
+\textbf{Information of interest: learning the tuple (sender network identity, transaction, receiver network identity).}
+This three-tuple of sender network identity, transaction, and receiver network
+identity allows for an adversary to link the fact that a
+specific sender of Zcash made a payment to a specific receiver, even though the
+amount of the payment is not disclosed.
+
+By ``network identity'', we mean the IP address of a sender or receiver, or other
+distinguishing information that is not included in the transaction itself. This
+differs from the ``on-chain'' identity of a sender or receiver, which Zcash
+shielded transactions hide by randomizing addresses.
+While the sender and receiver public keys (on-chain identity)
+are not exposed by the Zcash transaction itself, an adversary
+could learn their network identity by observing or participating in the
+network.
+
+\subsection{Adversarial Model}
+
+We begin with a brief review of possible adversaries, whom we will consider in
+our analysis of attack vectors.
+
+\textbf{Regular Zcash user:} Allowed to send and receive transactions and act
+outside the protocol, just as a real user.
+
+\textbf{Regular Zcash Node Operator:} Can operate one (or many) full Zcash
+nodes, and can store and forward all traffic that is sent through the node. Can
+query for network information, and store and examine all information it
+receives.
+
+\textbf{DNS seeder operators:} Operates the node that is used by new nodes when
+bootstrapping to the Zcash network, in order to learn about other nodes in the
+network to begin communicating with them directly.
+
+\textbf{Internet Service Providers (ISPs):} Can view traffic sent and received
+from either users or Zcash nodes. Can store observed traffic, forward traffic
+to other parties, and compare traffic with other traffic.
+
+\textbf{Government actors:} Can issue secret subpoenas and force ISPs and
+regular Zcash users to take actions they may not wish to take, such as turning
+over secret keys or server logs.
+
+
+\subsection{Attack Vectors Against Shielded Transaction Use}
+As described in Section~\ref{shielded} an adversary could gain more information
+about a shielded transaction by observing information exposed to the network.
+Keeping this in mind, and assuming that a transaction is shielded, we now
+review sensitive information that could be exposed and used for malicious
+purposes by a adversary.
+We divide attack vectors an adversary can employ using these information leaks
+into \emph{in scope} to our immediate network privacy assessment, and \emph{out
+of scope}.
+
+\subsubsection{In Scope}
+\label{in-scope}
+
+Note that an adversary has the ability to observe both \emph{on-chain} visible
+data as well as information or behaviour that is exposed to the network during
+the process of submitting a new transaction or receiving a transaction.
+
+\textbf{On-Path end to end correlation attacks:} This attack could occur by an
+adversary that can obtain the (sender identity, transaction, receiver identity)
+tuple discussed in Section~\ref{threat-model}. By \emph{on-path end to end
+correlation}, we include attacks performed by nodes that are directly on the
+path between a sender and receiver when publishing or receiving a transaction.
+In the current model of Zcash, such an attacks are practical
+only when the recipient uses a light wallet in such a manner that leaks the
+transaction that the sender or receiver is publishing, as further described in
+Section~\cite{light-wallet-spec}.
+
+\textbf{Block access patterns:} Even if a user accessed
+information about the Zcash blockchain using an anonymity tool such as Tor, the
+access patterns for specific blocks could leak information to network
+adversaries, such as the time of day that users requested information about
+that block, or its popularity.
+
+\textbf{Denial of Service attacks:} such attacks could be performed against
+Zcash nodes, such as DNS seeders refusing to respond to certain queries, or
+against Zcash users, such as light wallets refusing to service certain classes
+of IP addresses.
+
+
+\subsubsection{Deferred Threats for Future Improvements}
+
+\textbf{Malicious senders or receivers of Zcash:}
+Senders or receivers of Zcash can act honestly within the protocol but
+maliciously outside of the protocol (such as creating a ``honeypot'' for which
+Zcash users are tricked into sending valid transactions to). Such an attack
+would require the malicious receiver (or sender) to deanonymize the sender by
+one of the following methods:
+
+\begin{enumerate}
+  \item Gaining identifiable information from the transaction itself.
+  \item Using known network analysis methods to trace a transaction back to its
+    source.
+  \item Operating a node used as an entry point (such as a light wallet).
+\end{enumerate}
+
+While preventing malicious
+senders or receivers of Zcash from compromising the other part is certainly
+within the threat model of Zcash, we defer addressing this category of threats
+for future improvements.
+
+\textbf{Learning the tuple (sender or receiver identity, transaction):}
+Note that a network observer can also gain a subset of sender/receiver
+linkability information by
+observing just a sender \emph{or} receiver's identity linked to a specific
+transaction. Note this information is more valuable in an unshielded setting,
+as learning the unshielded transaction can give the attacker useful
+information. However, learning this information in a shielded setting simply
+gives the attacker enough information to learn that they are sending a Zcash
+transaction, but no additional information. As such, we consider this a
+deferred threat that we can consider in the future.
+
+\textbf{Partitioning attacks:} The Zcash network itself could be partitioned,
+such that some nodes think they are aware of the entire network, but only
+instead be aware of a small subset of nodes. Such attacks could be performed by
+DNS seeders (again, by lying about the state of the network), or even by
+highly-connected nodes. Such attacks are well-known in the literature and in
+practice and demonstrated to be practical for small-scale networks without a
+centralized mechanism for distribution about network state. However, we defer
+this threat for future improvements, as it requires designing a
+fully-decentralized but fully consistent network information distribution
+mechanism.
+
+\subsubsection{Out of Scope}
+\label{out-of-scope}
+
+\textbf{Unforeseen software flaws:} While our team at the Zcash Foundation
+works diligently to prevent software bugs and vulnerabilities to the best of
+our ability, we do not
+consider such flaws in scope, as such cases are unforeseen
+and we cannot rule them out completely. As such, when we become aware of
+vulnerabilities or flaws, we will fix them, but we cannot claim such
+occurrences will not occur in the future.
+
+\textbf{User behavior Outside of the Zcash protocol:} Zcash is not used in a
+vacuum; spending and receiving Zcash is linked to real-world value. As such, we
+do not consider user behavior outside of the Zcash protocol to be in scope,
+even if that behavior results in spending or receiving Zcash.
+For example, someone who goes to a website and wishes to purchase an item in
+Zcash may be unlinkable purely when observing the Zcash network, but their
+behavior when browsing the website can still be observable to a network
+attacker. In order to spend Zcash in a \emph{truly} private way, the user must
+use another privacy-preserving technology to hide their spending behavior
+outside of Zcash, such as accessing that website over Tor.
+
+\textbf{Sybil attacks:} In small decentralized networks, adversaries can
+control a larger percentage of the total network and consequently gain more
+advantage over collective network functions. However, we do not consider such
+attacks as in scope to our assessment; we assume an adversary with sufficiently
+limited resources as to require participation akin to honest users.
+
+\subsection{Attacks Less Applicable to Shielded Transactions}
+
+\textbf{Epistemic attacks:} A network observer could perform an epistemic
+attack by observing unique routing information that allows for eventual
+deanonymization of that user. Again, such attacks are possible in Zcash because
+users do not control routing information for their transaction.
+
+One example of epistemic attacks against cryptocurrency networks involve the
+probability of ``super-connected'' nodes that can link the node from which a
+transaction originated~\cite{dandelion, fanti2018dandelion}.
+
+However, in the case of a blockchain, all transactions are first synced to the
+blockchain (and become part of the global state of the network) before the
+receiver can learn the transaction. Hence, an adversary
+will not be able to learn the sender, receiver, transaction tuple simply by
+passively observing network traffic (unless the receiver is using a light
+wallet, and this query is made in the clear).
+
+\textbf{End-to-end timing fingerprinting attacks:}
+While an adversary can perform timing fingerprinting attacks on the sender of a
+transaction, the adversary still must be able to correlate this information to
+the receiver of the transaction in order to learn the full tuple of value.
+However, again, deanonymizing the receiver is possible
+\emph{only} in the light wallet setting when shielded transactions are used, as
+otherwise the receiving protocol is a full broadcast protocol.
+
+While light wallets could attempt to perform end-to-end timing attacks to link
+the sender and receiver of a transaction, we
+consider such attacks out of scope considering the latency and batching that is
+added in the time required for a transaction to be included into the
+blockchain, as further described in Section~\ref{observations}.
+
+\textbf{End-to-end behavior fingerprinting attacks:}
+Fingerprinting user behavior such as the frequency and number of transactions
+made could in theory allow for end-to-end linkability of senders and receivers
+in the setting where light wallets are used.
+For example, a malicious light wallet node could observe
+the frequency and pattern of a user’s transactions, and build a pattern to
+match against over time.
+
+However, as described in Section~\ref{observations}, it is unclear how
+end-to-end behavior correlation could occur in practice, even if an adversary has a
+complete view of the network, as all transactions must first be
+published to the blockchain before a receiver can receive the funds. At minimum, a
+transaction will have the anonymity set of the size of one block, but this
+assumes a transaction is immediately synced to the blockchain. In reality,
+ordering is not preserved for transactions included in the blockchain relative
+to when they were published to the network, due to proof of work
+requirements or variances in network topologies.
+
+
+\section{Review of Network Privacy Approaches}
+\label{network-privacy-review}
+
+Ideally, some of the attacks described in Section~\ref{attack-vectors} could be
+mitigated by using a network privacy layer. We now review three
+classes of network privacy approaches, and then in
+Section~\ref{network-privacy-assessment}, determine how these approaches
+address the existing described attacks against Zcash.
+
+For brevity, we only review
+Dandelion~\cite{Fanti:2018:DLC,BojjaVenkatakrishnan:2017:DRB},
+Tor~\cite{tor-specification}, and
+general-purpose Loopix-based mixnets~\cite{Piotrowska:2017:LAS}.
+Further, we review private information retrieval (PIR) as a method which can be
+used in conjunction with the above systems.
+
+\textbf{Dandelion.}
+Dandelion~\cite{BojjaVenkatakrishnan:2017:DRB} and
+Dandelion++~\cite{Fanti:2018:DLC} is a lightweight gossip protocol aimed at
+adding additional network privacy for
+distributed networks such as cryptocurrencies. Dandelion protects against
+\emph{passive}
+deanonymization attacks, but does not consider active or targeted attacks. Such
+passive deanonymization attacks could be conducted by a ``super node'' that has
+a high degree of connections to other nodes (and could either be a single node
+or a botnet where adversarial machines share information). As such, it is
+assumed that this adversary is honest-but-curious, following the gossip protocol
+but wishes to learn as much information about users as it can directly observe.
+However, Dandelion++ does consider a stronger adversarial model where nodes are
+allowed an arbitrarily-number of connections to other nodes (acting outside of the
+Bitcoin gossip spec which only allows 8).
+
+Both Dandelion variants follow a randomized design for how transactions are
+gossiped to the network, differing from the Bitcoin design where nodes publish
+transactions as widely as possible as quickly as possible. In the Dandelion
+design, whenever a node receives a transaction from a neighbor, it
+first flips a coin to determine if the traffic is sent to a single
+neighbor (constituting the ``stem'' phase) or to all the node's connections
+(constituting the ``fluff'' phase). Such an approach frustrates the ability for
+a super node to link a specific transaction to the node which originally
+published that transaction.
+
+
+\textbf{Tor.}
+Tor~\cite{tor-specification} is an anonymity network that today has over 2.5
+million users and a network
+size of over 6,500 nodes. Tor supports applications that require low latency,
+such as browsing the Internet anonymously or streaming videos. In order to
+support such a use case, Tor assumes that it is hard for network adversaries to
+gain an end-to-end view and provide correlation attacks, such as by injecting
+timing or dropping packets to test if the traffic it can view entering the
+network is the same as the traffic it can view leaving the network.
+
+Tor distributes its routing information (i.e, information about each relay) via
+an authenticated document called the \emph{consensus}, which is signed by a
+threshold number of trusted servers called \emph{directory authorities}. In
+doing so, Tor ensures that all clients and relays have a consistent view of the
+network. By distributing a global authenticated document to all network
+participants, Tor avoids epistemic or routing attacks unlike completely
+decentralized networks which cannot guarantee a user or relay's view of the
+network is authentic or that all users fall within a global anonymity set.
+
+
+\textbf{Loopix-based Mixnets.}
+While a range of mix network designs have been introduced in the literature, in
+this assessment we consider only those which instantiate the
+Loopix~\cite{Piotrowska:2017:LAS} design, which provides improved latency
+guarantees over prior designs. Similar to other mix network designs, Loopix
+uses dummy packets and message delays in order to protect against adversaries
+performing fingerprinting and end-to-end attacks of user traffic.
+
+While Loopix specifies how messages are routed through a network, Loopix-based
+networks still require safely distributing network information to users and
+nodes. As one example, Katzenpost~\cite{katzenpost}, a mix network which implemented
+Loopix,  used a similar model to Tor
+by leveraging trusted network authorities to sign and distribute the state of
+the network. However, alternative network distribution mechanisms can be used,
+but similarly may be subject to epistemic and path-routing attacks similar to
+other distributed networks.
+
+\textbf{Private Information Retrieval (PIR).}
+Even though the above network anonymity systems disassociate a sender or
+receiver's identity from the transaction, nodes can still observe which blocks
+are being fetched and perform fingerprinting attacks using this information.
+One mechanism that can be used in conjunction with network anonymity tools is
+private information retrieval (PIR)~\cite{pir}, which allows users to query information
+while preventing the service that hosts this information from learning the
+query.
+
+Note here we do not specify \emph{which} PIR design to use, we simply assume
+the properties of a PIR implementation, for which the content of the user's
+query is hidden from the service tasked with responding to that query.
+
+
+\section{Assessment of Network Privacy Approaches to Zcash Privacy (Assuming
+the Use of Shielded Transactions)}
+\label{network-privacy-assessment}
+
+We now review the extent to which Dandelion++, Tor, some generic PIR mechanism,
+and a \emph{general-purpose} Loopix-based mixnet
+protect against the existing network-based attacks against Zcash described in
+Section~\ref{threat-model}.
+Note again that we assume an attacker does not control either the sender or receiver
+of funds, and assume the attacker is limited in resources such that they cannot
+perform a Sybil attack.
+We summarize our results in Table~\ref{network-zcash-assessment}, but describe
+our findings here.
+
+\textbf{Assumptions.} We assume the mixnet is a separate anonymity network
+entirely, and is \emph{not} part of the cryptocurrency network
+itself (meaning that the initiator of a transaction forwards this transaction
+through the mixnet first before it is published to the cryptocurrency network).
+
+We assume that the PIR mechanism is used by the user to look up transactions in
+such a way that the node serving that transaction cannot infer the contents of
+the user's query.
+
+\begin{table}[t]
+  \caption{Effectiveness of network privacy mechanisms for Zcash
+  security and privacy, assuming the use of shielded transactions}
+  \label{network-zcash-assessment}
+
+\footnotesize
+
+  \CIRCLE=protects against; \Circle=does not protect against;
+  $\bigstar$=Not a threat in this setting;
+
+  Mixnet=General-purpose Loopix-based routing tuned for lower-latency
+  applications such as messaging or web-application traffic.
+
+  DoS=Denial of Service;
+
+  On-Path Correlation=End to end correlation attacks where one node in the path
+  is participating in the attack.
+
+  \medskip
+
+  \begin{tabular}{ p{4.5em}| c | c | c | c | c | c | c}
+    & & & & & \multicolumn{3}{c}{PIR}  \\
+    & Attack & Dandelion++ & Tor & Mixnet  & Only PIR & Tor & Mixnet \\
+ \hline
+    \multirow{2}{*}{Full Node} & DoS & \Circle & \Circle & \Circle & \Circle & \Circle & \Circle \\
+    & On-Path Correlation & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ \\
+    & Block Access Pattern & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ & $\bigstar$ \\
+
+    \hline
+
+    \multirow{2}{*}{Light Client} & DoS & \Circle & \Circle & \Circle & \Circle &  \Circle &
+    \Circle \\
+    & On-Path Correlation & \Circle & \CIRCLE & \CIRCLE & \Circle & \CIRCLE & \CIRCLE \\
+    & Block Access Pattern & $\Circle$ & $\Circle$ & $\Circle$ & $\CIRCLE$ & $\CIRCLE$ & $\CIRCLE$ \\
+
+\end{tabular}
+\end{table}
+
+\subsection{Analysis for Use of Full Nodes}
+
+\textbf{Dandelion++.}
+In the full node setting when shielded transactions are used, Dandelion++ does
+not meaningfully change privacy
+guarantees for users, as Dandelion++ provides privacy in the setting of a
+super node with knowledge of the network graph. In other words, knowledge of
+the originating node when using shielded transactions does not result in a
+meaningful information leak without additional knowledge of the receiver.
+Further, the protocol does not add any protection against denial of service
+attacks or the ability for nodes to observe block access patterns.
+
+\textbf{Tor.}
+As previously discussed, in the setting where full nodes are used, the receiver cannot be linked
+to a specific transaction, unless the receiver themselves is malicious and
+colludes with other parties.
+As such, the use of Tor does does not meaningfully change user privacy.
+
+\textbf{General-Purpose Mixnet.}
+While the use of a general-purpose mixnet raises the cost to an adversary to
+conduct fingerprinting attacks that could result in end-to-end linking of
+senders and receivers, this protection does not meaningfully increase user
+security in the full node setting.
+Most specifically, because receivers operate in a
+full-broadcast mode, end-to-end linking of senders and receivers is not
+possible when full nodes are used, unless the receiver themselves is
+compromised or malicious.
+
+\textbf{Only PIR.}
+Because the receiver in a full node setting receives all transactions, use of
+PIR does not add any additional meaningful protections when shielded
+transactions are used. This is because the receiver has the full set of
+transactions themselves and consequently will not expose a specific query to
+any external party.
+
+\textbf{Tor + PIR.}
+Because receivers of Zcash when using a full node operate in full broadcast
+receiver mode---meaning that the user
+does not leak which transaction they are interested in---use
+of PIR in this setting does not meaningfully add privacy or security
+protections.
+
+\textbf{General-Purpose Mixnet + PIR.}
+Again, because users operate with full nodes, even though the sender's identity
+is hidden and so are any timing or behavior leaks, use of mixnets with PIR does
+not add meaningful security when shielded transaction are used.
+
+\subsection{Analysis for Use of Light Wallets}
+
+\textbf{Dandelion++.}
+Similarly to the analysis for use of useful in a non-shielded context, Dandelion++ does not protect against
+end-to-end correlation attacks in the setting where light wallets are used.
+Specifically, while Dandelion++ protects against super nodes that can observe
+in-network gossip messages, Dandelion++ does not provide ``last-mile'' privacy,
+meaning that users can still be deanonymized by the light wallets they use.
+
+\textbf{Tor.}
+Tor protects against a light wallet directly distinguishing between receivers
+in a light wallet setting, as the light wallet will not be able to learn the
+network identity (IP address) of a receiver.
+
+Because Tor is a low-latency
+network, even if the receiver IP address is hidden from the light wallet, the
+light wallet or a network observer can still observe the user's timing and
+behavior when fetching transaction details. However, because a user's
+transaction is published to the Zcash network, and then published as the next
+block in the Zcash blockchain with a series of other transactions, it is
+unclear how much of an advantage an adversary has to perform end-to-end
+timing-based attacks in this setting (as further discussed in
+Section~\ref{observations}). Typically end-to-end timing attacks
+require performing packet correlation on the order of seconds, whereas the
+latency in a network like Zcash is on the order of minutes. As such, we deem
+timing-based attacks to be not applicable even when light wallets are used for
+Zcash.
+
+However, the light wallet can still observe which queries a receiver wishes to
+fetch, even if the light wallet cannot observe that receiver's network
+identity.
+Hence, we do not grant the property of protecting against
+block access patterns from receiver queries.
+
+\textbf{General-Purpose Mixnet.}
+Because blockchains require publishing transactions to a global immutable data
+store (the blockchain), the property of mixnets to inject dummy packets to help
+discourage end-to-end packet correlation in a web traffic setting is less
+relevant in a blockchain setting.
+
+Further, as described in Section~\ref{observations}, the ability of an adversary to use timing of
+transactions to infer information about the sender, receiver, and
+contents is less relevant in a blockchain setting due to the inherent latency
+incurred when publishing a transaction.
+While mixnets do hide timing information for packets by
+delaying messages sent through the mix network, in general-purpose mixnets that
+are tuned for web or
+messaging application traffic, such
+delays are on the order of seconds or even microseconds, where as we observed
+above, the Zcash network itself imposes delays on the order of minutes as
+transactions are added to the Zcash blockchain. Performing an end-to-end
+correlation attack simply by observing the endpoints (nodes servicing the
+sender or receiver of the transaction) will have difficulty performing such a
+timing correlation even in Zcash today.
+
+Similarly to the description of Tor above, a light wallet can observe which
+queries a receiver wishes to fetch, and so a malicious light wallet could use
+additional information to perform linking attacks. Hence, we do not grant the
+property of protecting against block access patterns.
+
+\textbf{Only PIR.}
+PIR in the setting of Zcash ensures that a receiver can hide which transaction
+they are interested in learning. However, a malicious on-path light wallet
+could still perform end-to-end correlation attacks by observing the sender and
+receiver's identities, as well as link the sender to a specific transaction.
+Hence, we do not grant full protection against on-path correlation attacks when
+only PIR is used. However, we do grant protection against the light wallet
+observing block access patterns due to the use of PIR.
+
+\textbf{Tor + PIR.}
+In the setting where senders and receivers use Tor along with PIR, we grant a
+full circle for protection against on-path correlation
+attacks.
+While nodes can learn that \emph{someone} is sending and receiving a
+transaction, nodes cannot learn either \emph{which} transaction, \emph{nor} who
+the sender or receiver are.
+Again, block access patterns are protected against due to the use of PIR.
+
+\textbf{General-Purpose Mixnet + PIR.}
+We grant a full circle for protection against on-path
+correlation attacks when a mixnet used in conjunction with PIR, as the use of
+PIR should only increase protection to users.
+Finally, block access patterns are protected against similarly to in the Tor +
+PIR case.
+
+\section{Future Improvements for Zcash Network Privacy}
+\label{future-improvements}
+
+\subsection{Network Privacy Improvements for Unshielded Transactions}
+
+While the end goal for Zcash is to move all users to use shielded transactions,
+the reality today is that only a very small percentage of Zcash is transacted
+using shielded transactions. In the interim to achieving the goal of
+ubiquitous shielded transactions, we can take intermediate steps to improve
+the privacy for Zcash users in the unshielded setting.
+
+With that said, incorporating a variant of the Dandelion++ gossip protocol is a
+lightweight and immediate first step to improving the privacy of unshielded
+transaction. However, we recognize that stronger protections are required in
+following steps to provide stronger security and privacy guarantees.
+
+\subsection{Network Privacy Improvements for Shielded Transactions}
+
+In looking at Table~\ref{network-zcash-assessment}, the strongest protections
+are offered by the combination of PIR along with a network anonymity tool such
+as Tor or a mixnet. Because use of an anonymity network protects against
+directly leaking the network identity of a user, and PIR protects against
+disclosing the contents of a user's query, the combination of these methods
+leaves little room for an attacker to gain advantage.
+
+While typically the
+ability for mixnets to offer protection
+against timing or behavior fingerprinting attacks is desirable,
+in the setting where shielded transactions are used along
+with PIR for receiver queries, this advantage becomes minimal as mixnets tuned
+for general application traffic (such as web traffic) will not meaningfully
+increase  end-to-end latency beyond that already induced by the blockchain
+itself.
+Again, this observation requires that the receiver can hide the contents of
+their query.
+
+As such, our immediate-term plan to proceed with Tor integration, and will
+assess PIR as a second step.
+We will continue to observe the development of production-ready mixnets as a
+possible option in the future, with an eye towards large-scale adoption in
+order to ensure sufficiently large anonymity sets for users.
+
+\section{Conclusion}
+\label{conclusion}
+
+In this technical report, we sketched out a more formalized assessment for the
+network privacy of
+users of Zcash, and identified how this threat model differs between a setting
+where users exchange shielded versus unshielded transactions. We then assessed
+the extent to which well-known network anonymity tools improve protections for
+Zcash users in the setting where \emph{shielded} transactions are used.
+Finally, we described next steps to improve user privacy in both a shielded and
+unshielded setting, starting with lightweight improvements to further
+longer-term structural changes.
+
+\section{Acknowledgements}
+
+We would like to thank Holmes Wilson from Zbay for his insightful discussion
+and feedback on this technical report.
+
+\bibliographystyle{plain}
+\bibliography{network-privacy}
+
+\end{document}