flashflow: linkify citations

1 files changed, 26 insertions, 24 deletions

diff --git a/proposals/316-flashflow.md b/proposals/316-flashflow.md
index ed62cf7..4a1fa15 100644
--- a/proposals/316-flashflow.md
+++ b/proposals/316-flashflow.md
@@ -56,7 +56,7 @@ time while Torflow takes days/weeks to assign them their full fair share
 of bandwidth (especially for non-exits). FlashFlow is more secure than
 Torflow: FlashFlow allows a relay to inflate its measured capacity by up
 to 1.33x (configured by a parameter) while Torflow allows weight
-inflation by a factor of 89x \[0\] or even 177x \[1\].
+inflation by a factor of 89x [\[0\]](#0) or even 177x [\[1\]](#1).
 
 After an overview in section 2 of the planned deployment stages, section
 3, 4, and 5 discuss the short, medium, and long term deployment plans in
@@ -302,7 +302,7 @@ If x is very small, the relay will perform the calculation s.t. x is the
 number of cells required to produce 10 Mbit/s of measurement traffic, thus
 ensuring some minimum amount of background traffic is allowed.
 
-\[XXX teor suggests in \[4\] that the number 10 Mbit/s could be derived more
+\[XXX teor suggests in [\[4\]](#4) that the number 10 Mbit/s could be derived more
 intelligently. E.g. based on AuthDirFastGuarantee or AuthDirGuardBWGuarantee\]
 
 ## 3.2 FlashFlow Components
@@ -532,7 +532,7 @@ report more than ~33 Mbit/s, FlashFlow limits it to just ~33 Mbit/s.)
 With r=25%, FlashFlow only allows 1.33x weight inflation.
 
 Prior work shows that Torflow allows weight inflation by a factor of 89x
-\[0\] or even 177x \[1\].
+[\[0\]](#0) or even 177x [\[1\]](#1).
 
 The ratio chosen is a trade-off between impact on background traffic and
 security: r=50% allows a relay to double its weight but won't impact
@@ -578,7 +578,7 @@ supports it.
 
 New link- and relay-subprotocol versions will be used by the relay to indicate
 FF support. E.g. at the time of writing, the next relay subprotocol version is
-4 \[3\].
+4 [\[3\]](#3).
 
 We plan to host a FlashFlow deployment consisting of a FF coordinator
 and a single FF measurer on a single 1 Gbit/s machine. Data produced by
@@ -652,7 +652,7 @@ The following is quoted from Section 4.3 of the FlashFlow paper.
     ensures that old relays will continue to be measured, with new
     relays given secondary priority in the order they arrive.
 
-\[XXX Teor leaves good ideas in his tor-dev@ post \[5\],
+\[XXX Teor leaves good ideas in his tor-dev@ post [\[5\]](#5),
 including a good plain language description of what the FF paper quotes says,
 and a recommendation on which consensus to use when making a new schedule]
 
@@ -694,30 +694,32 @@ time. What specifically to do here is left for medium/long term work.
   background traffic.
 - What to do about co-located relays. Can they be detected reliably?
   Should we just add a torrc option a la MyFamily for co-located relays?
-- What is the explanation for dennis.jackson's scary graphs in this \[2\]
+- What is the explanation for dennis.jackson's scary graphs in this [\[2\]](#2)
   ticket?  Was it because of the speed test? Why? Will FlashFlow produce
   the same behavior?
 
 # Citations
 
-```text
-[0] F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating
-    in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014.
-    https://www.cryptolux.org/images/b/bc/Tor_Issues_Thesis_Thill_Fabrice.pdf
-[1] A. Johnson, R. Jansen, N. Hopper, A. Segal, and P. Syverson.
-    PeerFlow: Secure Load Balancing in Tor. Proceedings on Privacy
-    Enhancing Technologies (PoPETs), 2017(2), April 2017.
-    https://ohmygodel.com/publications/peerflow-popets2017.pdf
-[2] Mike Perry: Graph onionperf and consensus information from Rob's
-    experiments
-    https://trac.torproject.org/projects/tor/ticket/33076
-[3] tor-spec.txt Section 9.3 "Relay" Subprotocol versioning
-    https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2132
-[4] Teor's second respose to FlashFlow proposal
-    https://lists.torproject.org/pipermail/tor-dev/2020-April/014251.html
-[5] Teor's first respose to FlashFlow proposal
-    https://lists.torproject.org/pipermail/tor-dev/2020-April/014246.html
-```
+<a id="0">\[0\]</a>: F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating
+in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014.
+<https://www.cryptolux.org/images/b/bc/Tor_Issues_Thesis_Thill_Fabrice.pdf>
+
+<a id="1">\[1\]</a>: A. Johnson, R. Jansen, N. Hopper, A. Segal, and P. Syverson.
+PeerFlow: Secure Load Balancing in Tor. Proceedings on Privacy
+Enhancing Technologies (PoPETs), 2017(2), April 2017.
+<https://ohmygodel.com/publications/peerflow-popets2017.pdf>
+
+<a id="2">\[2\]</a>: Mike Perry: Graph onionperf and consensus information from Rob's
+experiments <https://trac.torproject.org/projects/tor/ticket/33076>
+
+<a id="3">\[3\]</a>: tor-spec.txt Section 9.3 "Relay" Subprotocol versioning
+<https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2132>
+
+<a id="4">\[4\]</a>: Teor's second respose to FlashFlow proposal
+<https://lists.torproject.org/pipermail/tor-dev/2020-April/014251.html>
+
+<a id="5">\[5\]</a>: Teor's first respose to FlashFlow proposal
+<https://lists.torproject.org/pipermail/tor-dev/2020-April/014246.html>
 
 # Appendix A: Save CPU at measurer by not encrypting all MEAS_ECHO cells