flashflow: replace Citations section with direct links

1 files changed, 21 insertions, 22 deletions

diff --git a/proposals/316-flashflow.md b/proposals/316-flashflow.md
index 6acdd0d..49bf17a 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\]](#0) or even 177x [\[1\]](#1).
+inflation by a factor of 89x [\[0\]] or even 177x [\[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\]](#4) that the number 10 Mbit/s could be derived more
+\[XXX teor suggests in [\[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\]](#0) or even 177x [\[1\]](#1).
+[\[0\]] or even 177x [\[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\]](#3).
+4 [\[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\]](#5),
+\[XXX Teor leaves good ideas in his tor-dev@ post [\[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,32 +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\]](#2)
+- What is the explanation for dennis.jackson's scary graphs in this [\[2\]]
   ticket?  Was it because of the speed test? Why? Will FlashFlow produce
   the same behavior?
 
-# Citations
+<!-- # Citations -->
 
-<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>
+[\[0\]]: <https://www.cryptolux.org/images/b/bc/Tor_Issues_Thesis_Thill_Fabrice.pdf>
+"F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating
+in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014."
 
-<a id="1">\[1\]</a>: A. Johnson, R. Jansen, N. Hopper, A. Segal, and P. Syverson.
+[\[1\]]: <https://ohmygodel.com/publications/peerflow-popets2017.pdf>
+"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>
+Enhancing Technologies (PoPETs), 2017(2), April 2017."
 
-<a id="2">\[2\]</a>: Mike Perry: Graph onionperf and consensus information from Rob's
-experiments <https://trac.torproject.org/projects/tor/ticket/33076>
+[\[2\]]: <https://trac.torproject.org/projects/tor/ticket/33076>
+"Mike Perry: Graph onionperf and consensus information from Rob's experiments"
 
-<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>
+[\[3\]]: <https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2132>
+"tor-spec.txt Section 9.3 \"Relay\" Subprotocol versioning"
 
-<a id="4">\[4\]</a>: Teor's second respose to FlashFlow proposal
-<https://lists.torproject.org/pipermail/tor-dev/2020-April/014251.html>
+[\[4\]]: <https://lists.torproject.org/pipermail/tor-dev/2020-April/014251.html>
+"Teor's second respose to FlashFlow proposal"
 
-<a id="5">\[5\]</a>: Teor's first respose to FlashFlow proposal
-<https://lists.torproject.org/pipermail/tor-dev/2020-April/014246.html>
+[\[5\]]: <https://lists.torproject.org/pipermail/tor-dev/2020-April/014246.html>
+"Teor's first respose to FlashFlow proposal"
 
 # Appendix A: Save CPU at measurer by not encrypting all MEAS_ECHO cells
 
@@ -834,4 +834,3 @@ results in a bucket size of approximately 125:
 Slower relays can cheat more easily but the amount of extra weight they
 can obtain is insignificant in absolute terms. Faster relays are
 essentially unable to cheat.
-