Escape brackets

5 files changed, 88 insertions, 71 deletions

diff --git a/proposals/316-flashflow.md b/proposals/316-flashflow.md
index 8258d76..44ebe5c 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\] 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
@@ -133,7 +133,7 @@ allow itself to be measured more than twice by a FlashFlow deployment in
 any time window of this length. Relays should not change this option
 unless they really know what they're doing. Changing it at the relay
 will not change how often FlashFlow will attempt to measure the relay.
-Possible values are in the range [1 hour, 1 month] inclusive. Default: 1
+Possible values are in the range \[1 hour, 1 month\] inclusive. Default: 1
 day.
 
 FFBackgroundTrafficPercent: The maximum amount of regular
@@ -142,7 +142,7 @@ percent of total traffic (measurement + non-measurement). This
 parameter is a trade off between having to limit background traffic and
 limiting how much a relay can inflate its result by handling no
 background traffic but reporting that it has done so. Possible values
-are in the range [0, 99] inclusive. Default: 25 (a maximum inflation
+are in the range \[0, 99`] inclusive. Default: 25 (a maximum inflation
 factor of 1.33).
 
 FFMaxMeasurementDuration: The maximum amount of time, in seconds, that
@@ -151,7 +151,7 @@ measurement will begin soon and the end of the measurement. If this
 amount of time passes, the relay shall close all measurement connections
 and exit its measurement mode. Note this duration includes handshake
 time, thus it necessarily is larger than the expected actual measurement
-duration. Possible values are in the range [10, 120] inclusive.
+duration. Possible values are in the range \[10, 120\] inclusive.
 Default: 45.
 
 ### 3.1.2 New Cell Types
@@ -219,7 +219,7 @@ error to the coordinator and considers the measurement a failure. It is also a
 failure if any measurer is unable to open at least half of its circuits with
 the target.
 
-The payload of MEAS_PARAMS cells [XXX more may need to be added]:
+The payload of MEAS_PARAMS cells \[XXX more may need to be added\]:
 
 ```
 - meas_duration [2 bytes] [1, 600]
@@ -231,10 +231,10 @@ meas_duration is the duration, in seconds, that the actual measurement will
 last.  num_measurers is how many link_specifier structs follow containing
 information on the measurers that the relay should expect.  Future versions of
 FlashFlow and MEAS_PARAMS will use TLS certificates instead of IP addresses.
-[XXX probably need diff layout to allow upgrade to TLS certs instead of
+\[XXX probably need diff layout to allow upgrade to TLS certs instead of
 link_specifier structs. probably using ext-type-length-value like teor
-suggests]
-[XXX want to specify number of conns to expect from each measurer here?]
+suggests\]
+\[XXX want to specify number of conns to expect from each measurer here?\]
 
 MEAS_PARAMS_OK has no payload: it's just padding bytes to make the cell
 PAYLOAD_LEN (509) bytes long.
@@ -245,7 +245,7 @@ The payload of MEAS_ECHO cells:
 - arbitrary bytes [PAYLOAD_LEN bytes]
 ```
 
-The payload of MEAS_BG cells [XXX more for extra info? like CPU usage]:
+The payload of MEAS_BG cells \[XXX more for extra info? like CPU usage\]:
 
 ```
 - second        [2 byte] [1, 600]
@@ -260,7 +260,7 @@ subsequent cell will increment it by one. sent_bg_bytes is the number of
 background traffic bytes sent in the last second (since the last MEAS_BG
 cell). recv_bg_bytes is the same but for received bytes.
 
-The payload of MEAS_ERR cells [XXX need field for more info]:
+The payload of MEAS_ERR cells \[XXX need field for more info\]:
 
 ```
 - err_code [1 byte] [0, 255]
@@ -302,8 +302,8 @@ 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
-intelligently. E.g. based on AuthDirFastGuarantee or AuthDirGuardBWGuarantee]
+\[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
 
@@ -473,11 +473,11 @@ v3bw.2020-03-01-04-00-00
 v3bw.2020-03-01-05-00-00
 ```
 
-[XXX Either FF should auto-delete old ones, logrotate config should be
+\[XXX Either FF should auto-delete old ones, logrotate config should be
 provided, a script provided, or something to help bwauths not accidentally
-fill up their disk]
+fill up their disk\]
 
-[XXX What's the approxmiate disk usage for, say, a few years of these?]
+\[XXX What's the approxmiate disk usage for, say, a few years of these?\]
 
 ### 3.2.2 FlashFlow Measurer
 
@@ -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\] 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].
+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],
+\[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]
 
@@ -665,7 +665,7 @@ time. What specifically to do here is left for medium/long term work.
 
 ## 5.3 Experiments
 
-   [XXX todo]
+\[XXX todo\]
 
 ## 5.4 Other Changes/Investigations/Ideas
 
@@ -694,12 +694,13 @@ 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\]
   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
@@ -716,6 +717,7 @@ time. What specifically to do here is left for medium/long term work.
     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
+```
 
 # Appendix A: Save CPU at measurer by not encrypting all MEAS_ECHO cells
 
@@ -745,10 +747,10 @@ measurement.
 
 Consider bucket_size is 1000. For the moment ignore cell encryption.
 
-We start at idx=0 and pick an idx in [0, 1000) to record, say 640. At
-idx=640 we record the cell. At idx=1000 we choose a new idx in [1000,
+We start at idx=0 and pick an idx in \[0, 1000) to record, say 640. At
+idx=640 we record the cell. At idx=1000 we choose a new idx in \[1000,
 2000) to record, say 1236. At idx=1236 we record the cell. At idx=2000
-we choose a new idx in [2000, 3000). Etc.
+we choose a new idx in \[2000, 3000). Etc.
 
 There's 2000+ cells in flight and the measurer has recorded two items:
 
diff --git a/proposals/323-walking-onions-full.md b/proposals/323-walking-onions-full.md
index 86d57b2..192ae48 100644
--- a/proposals/323-walking-onions-full.md
+++ b/proposals/323-walking-onions-full.md
@@ -1572,9 +1572,9 @@ even, take the lower of the two center votes (the one at position
 N/2) if `BREAK_EVEN_LOW` is true. Otherwise, take the higher of the
 two center votes (the one at position N/2 + 1).
 
-For example, the Median(…, even_low: True, type: "uint") of the votes
-["String", 2, 111, 6] is 6. The Median(…, even_low: True, type: "uint")
-of the votes ["String", 77, 9, 22, "String", 3] is 9.
+For example, the `Median(…, even_low: True, type: "uint")` of the votes
+`["String", 2, 111, 6]` is 6. The `Median(…, even_low: True, type: "uint")`
+of the votes `["String", 77, 9, 22, "String", 3]` is 9.
 
 <!-- Section 3.3.4.2 --> <a id='S3.3.4.2'></a>
 
@@ -1681,7 +1681,7 @@ elements that appears in at least `MIN_COUNT` votes.
 
 (Note that the input votes may contain duplicate elements.  These
 must be treated as if there were no duplicates: the vote
-[1, 1, 1, 1] is the same as the vote [1]. Implementations may want
+`[1, 1, 1, 1]` is the same as the vote `[1]`. Implementations may want
 to preprocess votes by discarding all but one instance of each
 member.)
 
@@ -1827,10 +1827,12 @@ computed so far), and on the entirety of the set of votes.
 > our current behavior.
 
 Parameters:
+
     `FIELDS` (one or more other locations in the vote)
     `RULE` (the rule used to combine values)
 
-Encoding
+Encoding:
+
     ; This item is "derived from" some other field.
     DerivedItemOp = {
         op: "DerivedFrom",
@@ -2646,7 +2648,7 @@ corresponding ENDIVERouterData.
 Because SNIPLocation objects are signed, they must be encoded as "canonical"
 cbor, according to section 3.9 of RFC 7049.
 
-If R[idx] is {} (the empty map) for any given idx, then no SNIP will be
+If `R[idx]` is `{}` (the empty map) for any given idx, then no SNIP will be
 generated for the SNIPRouterData at that routing index for this index group.
 
 <!-- Section 4.2 --> <a id='S4.2'></a>
@@ -2839,6 +2841,7 @@ The CREATE2, CREATED2, and EXTENDED2 cells change as follows:
 
 These extensions are defined by this proposal:
 
+```text
   [01] -- `Partial_SNIPRouterData` -- Sent from an extending relay
           to a target relay. This extension holds one or more fields
           from the SNIPRouterData that the extending relay is using,
@@ -2861,6 +2864,7 @@ These extensions are defined by this proposal:
           originator does not want a SNIP.  Otherwise, the
           originator does want a SNIP containing the router and the
           specified index.  Other values are unspecified.
+```
 
 By default, EXTENDED2 cells are sent with a SNIP iff the EXTENDED2
 cell used a `snip_index_pos` link specifier, and CREATED2 cells are
@@ -2923,14 +2927,14 @@ following main changes.
 
 So the client's message is now:
 
-   CLIENT_PK [32 bytes]
+    CLIENT_PK [32 bytes]
 
 And the relay's reply is now:
 
-   NODEID    [32 bytes]
-   KEYID     [32 bytes]
-   SERVER_PK [32 bytes]
-   AUTH      [32 bytes]
+    NODEID    [32 bytes]
+    KEYID     [32 bytes]
+    SERVER_PK [32 bytes]
+    AUTH      [32 bytes]
 
 otherwise, all fields are computed as described in tor-spec.
 
@@ -3330,10 +3334,10 @@ relay cells.)
 > that the relay might not understand.
 
 To include the SNIP, the client places it in an extension in the
-INTRODUCE cell.  The onion key can now be omitted[*], along with
+INTRODUCE cell.  The onion key can now be omitted\[\*\], along with
 the link specifiers.
 
-> [*] Technically, we use a zero-length onion key, with a new type
+> \[\*\] Technically, we use a zero-length onion key, with a new type
 > "implicit in SNIP".
 
 To know whether the service can recognize this kind of cell, the
@@ -3445,10 +3449,10 @@ between updating ENDIVEs under ideal circumstances.
 # Migrating to Walking Onions
 
 This proposal is a major change in the Tor network that will
-eventually require the participation of all relays [*], and will make
+eventually require the participation of all relays \[\*\], and will make
 clients who support it distinguishable from clients that don't.
 
-> [*] Technically, the last relay in the path doesn't need support.
+> \[\*\] Technically, the last relay in the path doesn't need support.
 
 To keep the compatibility issues under control, here is the order in which it
 should be deployed on the network.
@@ -3903,6 +3907,7 @@ guards and/or exits depending on overall balance of resources on the
 network.
 
 Formula:
+
       type: 'weighted',
       source: {
           type:'bw', require_flags: ['Valid'], 'bwfield' : ["RM", "mbw"]
@@ -3978,10 +3983,10 @@ Formula:
 ## Appendix H: Choosing good clusters of exit policies
 
 With Walking Onions, we cannot easily support all the port
-combinations [*] that we currently allow in the "policy summaries"
+combinations \[\*\] that we currently allow in the "policy summaries"
 that we support in microdescriptors.
 
-> [*] How many "short policy summaries" are there? The number would be
+> \[\*\] How many "short policy summaries" are there? The number would be
 > 2^65535, except for the fact today's Tor doesn't permit exit policies to
 > get maximally long.
 
diff --git a/proposals/325-packed-relay-cells.md b/proposals/325-packed-relay-cells.md
index 7a88840..7d0ffca 100644
--- a/proposals/325-packed-relay-cells.md
+++ b/proposals/325-packed-relay-cells.md
@@ -57,23 +57,27 @@ concatenated one after another following this format of a relay cell. The
 first command is the same header format as a normal relay cell detailed in
 section 6.1 of tor-spec.txt
 
-  Relay Command   [1 byte]
-  'Recognized'    [2 bytes]
-  StreamID        [2 bytes]
-  Digest          [4 bytes]
-  Length          [2 bytes]
-  Data            [Length bytes]
-  RELAY\_MESSAGE
-  Padding         [up to end of cell]
+```text
+Relay Command   [1 byte]
+'Recognized'    [2 bytes]
+StreamID        [2 bytes]
+Digest          [4 bytes]
+Length          [2 bytes]
+Data            [Length bytes]
+RELAY\_MESSAGE
+Padding         [up to end of cell]
+```
 
 The `RELAY_MESSAGE` can be empty as in no bytes indicating no other messages
 or set to the following:
 
-   Relay Command   [1 byte]
-   StreamID        [2 bytes]
-   Length          [2 bytes]
-   Data            [Length bytes]
-   RELAY\_MESSAGE
+```text
+Relay Command   [1 byte]
+StreamID        [2 bytes]
+Length          [2 bytes]
+Data            [Length bytes]
+RELAY\_MESSAGE
+```
 
 Note that the Recognized and Digest field are not added to a second relay
 message, they are solely used for the whole relay cell thus how we
@@ -123,10 +127,12 @@ with the default set to use a consensus parameter.
 
 The parameter is:
 
-    "relay-cell-packing"
+```text
+"relay-cell-packing"
 
-    Boolean: if 1, clients should send packed relay cells.
-    (Min: 0, Max 1, Default: 0)
+Boolean: if 1, clients should send packed relay cells.
+(Min: 0, Max 1, Default: 0)
+```
 
 To handle migration, first the parameter should be set to 0 and the
 configuration setting should be "auto".  To test the feature, individual
@@ -150,17 +156,21 @@ I propose a new relay message format, described here (with `ux`
 denoting an x-bit bitfield).  This format is 2 bytes or 4 bytes,
 depending on its first bit.
 
-    struct relay_header {
-       u1 stream_id_included; // Is the stream_id included?
-       u6 relay_command; // as before
-       u9 relay_data_len; // as before
-       u8 optional_stream_id[]; // 0 bytes or two bytes.
-    }
+```C
+struct relay_header {
+   u1 stream_id_included; // Is the stream_id included?
+   u6 relay_command; // as before
+   u9 relay_data_len; // as before
+   u8 optional_stream_id[]; // 0 bytes or two bytes.
+}
+```
 
 Alternatively, you can view the first three fields as a 16-bit
 value, computed as:
 
-    (stream_id_included<<15) | (relay_command << 9) | (relay_data_len).
+```C
+(stream_id_included<<15) | (relay_command << 9) | (relay_data_len).
+```
 
 If the `optional_stream_id` field is not present, then the default
 value for the `stream_id` is computed as follows.  We use stream_id 0
diff --git a/proposals/326-tor-relay-well-known-uri-rfc8615.md b/proposals/326-tor-relay-well-known-uri-rfc8615.md
index 075aa6d..8bc705a 100644
--- a/proposals/326-tor-relay-well-known-uri-rfc8615.md
+++ b/proposals/326-tor-relay-well-known-uri-rfc8615.md
@@ -38,7 +38,7 @@ The verification of listed Tor relay/bridge IDs only succeeds if the claim can b
 * Each line contains one relay fingerprint.
 * The file MUST NOT contain fingerprints of Tor bridges (or hashes of bridge fingerprints). For bridges see the file `hashed-bridge-rsa-fingerprint.txt`.
 * The file may contain comments (starting with #).
-* Non-comment lines must be exactly 40 characters long and consist of the following characters [a-fA-F0-9].
+* Non-comment lines must be exactly 40 characters long and consist of the following characters `[a-fA-F0-9]`.
 * Fingerprints are not case-sensitive.
 * Each fingerprint MUST appear at most once.
 * The file MUST not be larger than one MByte.
@@ -59,7 +59,7 @@ The RSA SHA1 relay fingerprint can be found in the file named "fingerprint" loca
 * This file is not relevant for bridges.
 * Each line contains one public ed25519 master key in its base64 encoded form.
 * The file may contain comments (starting with #).
-* Non-comment lines must be exactly 43 characters long and consist of the following characters [a-zA-z0-9/+].
+* Non-comment lines must be exactly 43 characters long and consist of the following characters `[a-zA-z0-9/+]`.
 * Each key MUST appear at most once.
 * The file MUST not be larger than one MByte.
 * The content MUST be a media type of "text/plain".
@@ -80,7 +80,7 @@ The base64 encoded ed25519 public master key can be found in the file named "fin
 * The file contains one or more SHA1 hashed Tor bridge SHA1 fingerprints operated by the entity in control of this website.
 * Each line contains one hashed bridge fingerprint.
 * The file may contain comments (starting with #).
-* Non-comment lines must be exactly 40 characters long and consist of the following characters [a-fA-F0-9].
+* Non-comment lines must be exactly 40 characters long and consist of the following characters `[a-fA-F0-9]`.
 * Hashed fingerprints are not case-sensitive.
 * Each hashed fingerprint MUST appear at most once.
 * The file MUST not be larger than one MByte.
diff --git a/proposals/328-relay-overload-report.md b/proposals/328-relay-overload-report.md
index 5901b93..bdb4fec 100644
--- a/proposals/328-relay-overload-report.md
+++ b/proposals/328-relay-overload-report.md
@@ -41,16 +41,16 @@ state" which can be one or many of the following load metrics:
 
    - Any OOM invocation due to memory pressure
    - Any ntor onionskins are dropped
-     [Removed in tor-0.4.6.11 and 0.4.7.5-alpha]
+     \[Removed in tor-0.4.6.11 and 0.4.7.5-alpha\]
    - A certain ratio of ntor onionskins dropped.
-     [Added in tor-0.4.6.11 and 0.4.7.5-alpha]
+     \[Added in tor-0.4.6.11 and 0.4.7.5-alpha\]
    - TCP port exhaustion
    - DNS timeout reached (X% of timeouts over Y seconds).
-     [Removed in tor-0.4.7.3-alpha]
+     \[Removed in tor-0.4.7.3-alpha\]
    - CPU utilization of Tor's mainloop CPU core above 90% for 60 sec
-     [Never implemented]
+     \[Never implemented\]
    - Control port overload (too many messages queued)
-     [Never implemented]
+     \[Never implemented\]
 
 For DNS timeouts, the X and Y are consensus parameters
 (overload_dns_timeout_scale_percent and overload_dns_timeout_period_secs)