Run mdformat on the spec files.

author: Nick Mathewson <nickm@torproject.org> 2023-10-14 14:07:40 -0400
committer: Nick Mathewson <nickm@torproject.org> 2023-10-14 14:07:40 -0400
commit: 4ba45dfd9afd08edeb46243127a480f1d23b9640 (patch)
tree: 4dcdb3b4ac378b255d8292693ef234100bf67ac5
parent: d4b9bcc71565e1c3b7b74ddfcd44730697c10c6b (diff)
download: torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.tar.gz
torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.zip
82 files changed, 673 insertions, 676 deletions
diff --git a/spec/README.md b/spec/README.md
index 63aa12f..26c4bac 100644
--- a/spec/README.md
+++ b/spec/README.md
@@ -60,12 +60,7 @@ need to have mdbook installed to do this.)
 
 > TODO: Add a note about trying not to break links.
 
-[git repository]: https://gitlab.torproject.org/tpo/core/torspec/
-[`spec` directory]: https://gitlab.torproject.org/tpo/core/torspec/-/tree/main/spec?ref_type=heads
-[`spec/tor-spec-intro.md`]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/spec/tor-spec-intro.md?ref_type=heads
-[`SUMMARY.md`]: https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/spec/SUMMARY.md?ref_type=heads
-
-----
+______________________________________________________________________
 
 ## Permalinks
 
@@ -126,3 +121,8 @@ long-term permalinks.
 <dd><a href="https://github.com/nmathewson/walking-onions-wip/tree/master/specs"><code>https://github.com/nmathewson/walking-onions-wip/tree/master/specs</code> (Walking Onions specifications (work in progress))</a></dt>
 
 </dl>
+
+[git repository]: https://gitlab.torproject.org/tpo/core/torspec/
+[`spec/tor-spec-intro.md`]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/spec/tor-spec-intro.md?ref_type=heads
+[`spec` directory]: https://gitlab.torproject.org/tpo/core/torspec/-/tree/main/spec?ref_type=heads
+[`summary.md`]: https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/spec/SUMMARY.md?ref_type=heads
diff --git a/spec/SUMMARY.md b/spec/SUMMARY.md
index 542491b..851f9a2 100644
--- a/spec/SUMMARY.md
+++ b/spec/SUMMARY.md
@@ -54,7 +54,7 @@
     - [Introduction](./srv-spec/introduction.md)
     - [Overview](./srv-spec/overview.md)
     - [Protocol](./srv-spec/protocol.md)
-    - [Specification [SPEC]](./srv-spec/specification-spec.md)
+    - [Specification \[SPEC\]](./srv-spec/specification-spec.md)
     - [Security Analysis](./srv-spec/security-analysis.md)
     - [Discussion](./srv-spec/discussion.md)
     - [Acknowledgements](./srv-spec/acknowledgements.md)
@@ -78,7 +78,7 @@
   - [Circuit Creation, Entry Guard Selection (1000 foot view)](./guard-spec/circuit-creation-entry-guard-selection-1000-foot.md)
   - [The algorithm.](./guard-spec/algorithm.md)
   - [Appendices](./guard-spec/appendices.md)
-  - [Still non-addressed issues [Section:TODO]](./guard-spec/still-non-addressed-issues-sectiontodo.md)
+  - [Still non-addressed issues \[Section:TODO\]](./guard-spec/still-non-addressed-issues-sectiontodo.md)
 - [`Tor Padding Specification`](./padding-spec-intro.md)
   - [Overview](./padding-spec/overview.md)
   - [Connection-level padding](./padding-spec/connection-level-padding.md)
@@ -96,23 +96,23 @@
 - [`Tor Rendezvous Specification - Version 3`](./rend-spec-v3-intro.md)
   - [Hidden services: overview and preliminaries.](./rend-spec-v3/hidden-services-overview-preliminaries.md)
   - [Protocol overview](./rend-spec-v3/protocol-overview.md)
-  - [Generating and publishing hidden service descriptors [HSDIR]](./rend-spec-v3/generating-publishing-hidden-service-descriptors.md)
-    - [Deriving blinded keys and subcredentials [SUBCRED]](./rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md)
-    - [Publishing shared random values [PUB-SHAREDRANDOM]](./rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md)
-    - [Hidden service descriptors: outer wrapper [DESC-OUTER]](./rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md)
-    - [Hidden service descriptors: encryption format [HS-DESC-ENC]](./rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md)
-  - [The introduction protocol [INTRO-PROTOCOL]](./rend-spec-v3/introduction-protocol-intro-protocol.md)
+  - [Generating and publishing hidden service descriptors \[HSDIR\]](./rend-spec-v3/generating-publishing-hidden-service-descriptors.md)
+    - [Deriving blinded keys and subcredentials \[SUBCRED\]](./rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md)
+    - [Publishing shared random values \[PUB-SHAREDRANDOM\]](./rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md)
+    - [Hidden service descriptors: outer wrapper \[DESC-OUTER\]](./rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md)
+    - [Hidden service descriptors: encryption format \[HS-DESC-ENC\]](./rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md)
+  - [The introduction protocol \[INTRO-PROTOCOL\]](./rend-spec-v3/introduction-protocol-intro-protocol.md)
   - [The rendezvous protocol](./rend-spec-v3/rendezvous-protocol.md)
   - [Encrypting data between client and host](./rend-spec-v3/encrypting-data-between-client-host.md)
-  - [Encoding onion addresses [ONIONADDRESS]](./rend-spec-v3/encoding-onion-addresses-onionaddress.md)
+  - [Encoding onion addresses \[ONIONADDRESS\]](./rend-spec-v3/encoding-onion-addresses-onionaddress.md)
   - [Open Questions:](./rend-spec-v3/open-questions.md)
-  - [Appendix A: Signature scheme with key blinding [KEYBLIND]](./rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md)
-  - [Appendix B: Selecting nodes [PICKNODES]](./rend-spec-v3/selecting-nodes-picknodes.md)
-  - [Appendix C: Recommendations for searching for vanity .onions [VANITY]](./rend-spec-v3/recommendations-for-searching-for-vanity-onions.md)
+  - [Appendix A: Signature scheme with key blinding \[KEYBLIND\]](./rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md)
+  - [Appendix B: Selecting nodes \[PICKNODES\]](./rend-spec-v3/selecting-nodes-picknodes.md)
+  - [Appendix C: Recommendations for searching for vanity .onions \[VANITY\]](./rend-spec-v3/recommendations-for-searching-for-vanity-onions.md)
   - [Appendix D: Numeric values reserved in this document](./rend-spec-v3/numeric-values-reserved-this-document.md)
   - [Appendix E: Reserved numbers](./rend-spec-v3/reserved-numbers.md)
-  - [Appendix F: Hidden service directory format [HIDSERVDIR-FORMAT]](./rend-spec-v3/hidden-service-directory-format-hidservdir-format.md)
-  - [Appendix G: Managing authorized client data [CLIENT-AUTH-MGMT]](./rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md)
+  - [Appendix F: Hidden service directory format \[HIDSERVDIR-FORMAT\]](./rend-spec-v3/hidden-service-directory-format-hidservdir-format.md)
+  - [Appendix G: Managing authorized client data \[CLIENT-AUTH-MGMT\]](./rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md)
   - [Appendix F: Two methods for managing revision counters.](./rend-spec-v3/two-methods-for-managing-revision-counters.md)
   - [Appendix G: Text vectors](./rend-spec-v3/text-vectors.md)
 
diff --git a/spec/address-spec.md b/spec/address-spec.md
index 0254e24..c3c779c 100644
--- a/spec/address-spec.md
+++ b/spec/address-spec.md
@@ -15,7 +15,7 @@ Table of Contents
 # Overview
 
 Most of the time, Tor treats user-specified hostnames as opaque:  When
-the user connects to <www.torproject.org>, Tor picks an exit node and uses
+the user connects to \<www.torproject.org>, Tor picks an exit node and uses
 that node to connect to "www.torproject.org".  Some hostnames, however,
 can be used to override Tor's default behavior and circuit-building
 rules.
@@ -35,7 +35,7 @@ option or the MAPADDRESS control command.
            [name-or-digest].exit
 ```
 
-Hostname is a valid hostname; [name-or-digest] is either the nickname of a
+Hostname is a valid hostname; \[name-or-digest\] is either the nickname of a
 Tor node or the hex-encoded digest of that node's public key.
 
 When Tor sees an address in this format, it uses the specified hostname as
@@ -99,7 +99,7 @@ is supported in Tor 0.2.4.10-alpha and later.
 
 # .noconnect
 
-SYNTAX:  [string].noconnect
+SYNTAX:  \[string\].noconnect
 
 When Tor sees an address in this format, it immediately closes the
 connection without attaching it to any circuit. This is useful for
diff --git a/spec/bandwidth-file-spec/header-list-format.md b/spec/bandwidth-file-spec/header-list-format.md
index 4feae69..075ddd6 100644
--- a/spec/bandwidth-file-spec/header-list-format.md
+++ b/spec/bandwidth-file-spec/header-list-format.md
@@ -23,7 +23,7 @@ It consists of:
 
 Timestamp NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 The Unix Epoch time in seconds of the most recent generator bandwidth
 result.
@@ -44,10 +44,10 @@ with version 1.0.0.
 
 "version" version_number NL
 
-[In second position, zero or one time.]
+\[In second position, zero or one time.\]
 
 The specification document format version.
-It uses semantic versioning [5].
+It uses semantic versioning \[5\].
 
 This Line was added in version 1.1.0 of this specification.
 
@@ -56,7 +56,7 @@ version_number is considered to be "1.0.0".
 
 "software" Value NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The name of the software that created the document.
 
@@ -67,7 +67,7 @@ is considered to be "torflow".
 
 "software_version" Value NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The version of the software that created the document.
 The version may be a version_number, a git commit, or some other
@@ -77,7 +77,7 @@ This Line was added in version 1.1.0 of this specification.
 
 "file_created" DateTime NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The date and time timestamp in ISO 8601 format and UTC time zone
 when the file was created.
@@ -86,7 +86,7 @@ This Line was added in version 1.1.0 of this specification.
 
 "generator_started" DateTime NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The date and time timestamp in ISO 8601 format and UTC time zone
 when the generator started.
@@ -95,7 +95,7 @@ This Line was added in version 1.1.0 of this specification.
 
 "earliest_bandwidth" DateTime NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The date and time timestamp in ISO 8601 format and UTC time zone
 when the first relay bandwidth was obtained.
@@ -104,7 +104,7 @@ This Line was added in version 1.1.0 of this specification.
 
 "latest_bandwidth" DateTime NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The date and time timestamp in ISO 8601 format and UTC time zone
 of the most recent generator bandwidth result.
@@ -118,7 +118,7 @@ This Line was added in version 1.1.0 of this specification.
 
 "number_eligible_relays" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of relays that have enough measurements to be
 included in the bandwidth file.
@@ -127,7 +127,7 @@ This Line was added in version 1.2.0 of this specification.
 
 "minimum_percent_eligible_relays" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The percentage of relays in the consensus that SHOULD be
 included in every generated bandwidth file.
@@ -148,7 +148,7 @@ This Line was added in version 1.2.0 of this specification.
 
 "number_consensus_relays" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of relays in the consensus.
 
@@ -156,7 +156,7 @@ This Line was added in version 1.2.0 of this specification.
 
 "percent_eligible_relays" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of eligible relays, as a percentage of the number
 of relays in the consensus.
@@ -204,7 +204,7 @@ This Line was added in version 1.2.0 of this specification.
 
 "recent_consensus_count" Int NL
 
-[Zero or one time.].
+\[Zero or one time.\].
 
 The number of the different consensuses seen in the last data_period
 days. (data_period is 5 by default.)
@@ -275,7 +275,7 @@ in version 1.5.0.
 
 "recent_measurement_failure_count" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the scanner attempted to measure a relay in
 the last data_period days (5 by default), but the relay has not been
@@ -285,7 +285,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "recent_measurements_excluded_error_count" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of relays that have no successful measurements in the last
 data_period days (5 by default).
@@ -296,7 +296,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "recent_measurements_excluded_near_count" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of relays that have some successful measurements in the last
 data_period days (5 by default), but all those measurements were
@@ -308,7 +308,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "recent_measurements_excluded_old_count" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of relays that have some successful measurements, but all
 those measurements are too old (more than 5 days, by default).
@@ -322,7 +322,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "recent_measurements_excluded_few_count" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of relays that don't have enough recent successful
 measurements. (Fewer than 2 measurements in the last 5 days, by
@@ -338,7 +338,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "time_to_report_half_network" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The time in seconds that it would take to report measurements about the
 half of the network, given the number of eligible relays and the time
@@ -350,7 +350,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "tor_version" version_number NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The Tor version of the Tor process controlled by the generator.
 
@@ -358,7 +358,7 @@ This Line was added in version 1.4.0 of this specification.
 
 "mu" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The network stream bandwidth average calculated as explained in B4.2.
 
@@ -366,7 +366,7 @@ This Line was added in version 1.7.0 of this specification.
 
 "muf" Int NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The network stream bandwidth average filtered calculated as explained in
 B4.2.
@@ -375,7 +375,7 @@ This Line was added in version 1.7.0 of this specification.
 
 KeyValue NL
 
-[Zero or more times.]
+\[Zero or more times.\]
 
 There MUST NOT be multiple KeyValue header Lines with the same key.
 If there are, the parser SHOULD choose an arbitrary Line.
@@ -399,7 +399,7 @@ If there are, the parser MAY ignore conflicting keywords.
 
 Terminator NL
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The Header List section ends with a Terminator.
 
diff --git a/spec/bandwidth-file-spec/implementation-details.md b/spec/bandwidth-file-spec/implementation-details.md
index 5491d57..90f84fa 100644
--- a/spec/bandwidth-file-spec/implementation-details.md
+++ b/spec/bandwidth-file-spec/implementation-details.md
@@ -39,7 +39,7 @@ As above.
 
 "nick" nickname
 
-[Exactly once.]
+\[Exactly once.\]
 
 The relay nickname.
 
@@ -47,7 +47,7 @@ Torflow also has a "nick" KeyValue.
 
 "rtt" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The Round Trip Time in milliseconds to obtain 1 byte of data.
 
@@ -56,7 +56,7 @@ It became optional in version 1.3.0 or 1.4.0 of this specification.
 
 "time" DateTime
 
-[Exactly once.]
+\[Exactly once.\]
 
 The date and time timestamp in ISO 8601 format and UTC time zone
 when the last bandwidth was obtained.
@@ -66,7 +66,7 @@ The Torflow equivalent is "measured_at".
 
 "success" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the bandwidth measurements for this relay were
 successful.
@@ -75,7 +75,7 @@ This KeyValue was added in version 1.1.0 of this specification.
 
 "error_circ" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the bandwidth measurements for this relay
 failed because of circuit failures.
@@ -85,7 +85,7 @@ The Torflow equivalent is "circ_fail".
 
 "error_stream" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the bandwidth measurements for this relay
 failed because of stream failures.
@@ -94,7 +94,7 @@ This KeyValue was added in version 1.1.0 of this specification.
 
 "error_destination" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the bandwidth measurements for this relay
 failed because the destination Web server was not available.
@@ -103,7 +103,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "error_second_relay" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the bandwidth measurements for this relay
 failed because sbws could not find a second relay for the test circuit.
@@ -112,7 +112,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "error_misc" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times that the bandwidth measurements for this relay
 failed because of other reasons.
@@ -121,7 +121,7 @@ This KeyValue was added in version 1.1.0 of this specification.
 
 "bw_mean" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The measured bandwidth mean for this relay in bytes per second.
 
@@ -129,7 +129,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "bw_median" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The measured bandwidth median for this relay in bytes per second.
 
@@ -137,7 +137,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "desc_bw_avg" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The descriptor average bandwidth for this relay in bytes per second.
 
@@ -145,7 +145,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "desc_bw_obs_last" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The last descriptor observed bandwidth for this relay in bytes per
 second.
@@ -154,7 +154,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "desc_bw_obs_mean" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The descriptor observed bandwidth mean for this relay in bytes per
 second.
@@ -163,7 +163,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "desc_bw_bur" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The descriptor burst bandwidth for this relay in bytes per
 second.
@@ -172,7 +172,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "consensus_bandwidth" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The consensus bandwidth for this relay in bytes per second.
 
@@ -180,7 +180,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "consensus_bandwidth_is_unmeasured" Bool
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 If the consensus bandwidth for this relay was not obtained from
 three or more bandwidth authorities, this KeyValue is True or
@@ -190,7 +190,7 @@ This KeyValue was added in version 1.2.0 of this specification.
 
 "relay_in_recent_consensus_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times this relay was found in a consensus in the
 last data_period days. (Unless otherwise stated, data_period is
@@ -200,7 +200,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_priority_list_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times this relay has been prioritized to be measured
 in the last data_period days.
@@ -209,7 +209,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_measurement_attempt_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times this relay was tried to be measured in the
 last data_period days.
@@ -218,7 +218,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_measurement_failure_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times this relay was tried to be measured in the
 last data_period days, but it was not possible to obtain a
@@ -228,7 +228,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_measurements_excluded_error_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of recent relay measurement attempts that failed.
 Measurements are recent if they are in the last data_period days
@@ -240,7 +240,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_measurements_excluded_near_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 When all of a relay's recent successful measurements were performed in
 a period of time that was too short (by default 1 day), the relay is
@@ -253,7 +253,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_measurements_excluded_old_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of successful measurements for this relay that are too old
 (more than data_period days, 5 by default).
@@ -267,7 +267,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "relay_recent_measurements_excluded_few_count" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of successful measurements for this relay that were ignored
 because the relay did not have enough successful measurements (fewer
@@ -283,7 +283,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "under_min_report" bool
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 If the value is 1, there are not enough eligible relays in the
 bandwidth file, and Tor bandwidth authorities MAY NOT vote on this
@@ -305,7 +305,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "unmeasured" bool
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 If the value is 1, this relay was not successfully measured and
 Tor bandwidth authorities MAY NOT vote on this relay.
@@ -325,7 +325,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "vote" bool
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 If the value is 0, Tor directory authorities SHOULD ignore the relay's
 entry in the bandwidth file. They SHOULD vote for the relay the same
@@ -347,7 +347,7 @@ This KeyValue was added in version 1.4.0 of this specification.
 
 "xoff_recv" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times this relay received `XOFF_RECV` stream events while
 being measured in the last data_period days.
@@ -356,7 +356,7 @@ This KeyValue was added in version 1.6.0 of this specification.
 
 "xoff_sent" Int
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The number of times this relay received `XOFF_SENT` stream events while
 being measured in the last data_period days.
@@ -365,7 +365,7 @@ This KeyValue was added in version 1.6.0 of this specification.
 
 "r_strm" Float
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The stream ratio of this relay calculated as explained in B4.3.
 
@@ -373,7 +373,7 @@ This KeyValue was added in version 1.7.0 of this specification.
 
 "r_strm_filt" Float
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The filtered stream ratio of this relay calculated as explained in B4.3.
 
@@ -383,7 +383,7 @@ This KeyValue was added in version 1.7.0 of this specification.
 
 #### Torflow
 
-Torflow RelayLines include node_id and bw, and other KeyValue pairs [2].
+Torflow RelayLines include node_id and bw, and other KeyValue pairs \[2\].
 
 References:
 
diff --git a/spec/bandwidth-file-spec/relay-line-format.md b/spec/bandwidth-file-spec/relay-line-format.md
index 13a9ffd..ec47146 100644
--- a/spec/bandwidth-file-spec/relay-line-format.md
+++ b/spec/bandwidth-file-spec/relay-line-format.md
@@ -20,7 +20,7 @@ Each RelayLine includes the following KeyValue pairs:
 
 "node_id" hexdigest
 
-[Exactly once.]
+\[Exactly once.\]
 
 The fingerprint for the relay's RSA identity key.
 
@@ -39,7 +39,7 @@ least one of them.
 
 "master_key_ed25519" MasterKey
 
-[Zero or one time.]
+\[Zero or one time.\]
 
 The relays's master Ed25519 key, base64 encoded,
 without trailing "="s, to avoid ambiguity with KeyValue "="
@@ -51,7 +51,7 @@ This KeyValue was added in version 1.1.0 of this specification.
 
 "bw" Bandwidth
 
-[Exactly once.]
+\[Exactly once.\]
 
 The bandwidth of this relay in kilobytes per second.
 
@@ -107,7 +107,7 @@ measured bandwidth.
 
 KeyValue
 
-[Zero or more times.]
+\[Zero or more times.\]
 
 Future format versions may include additional KeyValue pairs on a
 RelayLine.
diff --git a/spec/bandwidth-file-spec/sample-data.md b/spec/bandwidth-file-spec/sample-data.md
index f9b05de..45bb43f 100644
--- a/spec/bandwidth-file-spec/sample-data.md
+++ b/spec/bandwidth-file-spec/sample-data.md
@@ -39,7 +39,7 @@ bw=189 error_circ=0 error_misc=0 error_stream=0 master_key_ed25519=a6a+dZadrQBtf
 
 ## Generated by sbws version 1.0.3
 
-```text
+````text
 1523911758
 version=1.2.0
 latest_bandwidth=2018-04-16T20:49:18
@@ -78,7 +78,7 @@ percent_eligible_relays=46
 software=sbws
 software_version=1.0.3
 =====
-```
+````
 
 <a id="bandwidth-file-spec.txt-A.4"></a>
 
diff --git a/spec/bandwidth-file-spec/scaling-bandwidths.md b/spec/bandwidth-file-spec/scaling-bandwidths.md
index 32fcb83..8d8906e 100644
--- a/spec/bandwidth-file-spec/scaling-bandwidths.md
+++ b/spec/bandwidth-file-spec/scaling-bandwidths.md
@@ -127,6 +127,6 @@ r_strm_i = bw_i / bw_avg_strm
       bw_new_i = r_i * bw_obs_i
 ```
 
-<<In this way, the resulting network status consensus bandwidth
+\<\<In this way, the resulting network status consensus bandwidth
 values are effectively re-weighted proportional to how much faster
 the node was as compared to the rest of the network.>>
diff --git a/spec/bandwidth-file-spec/scope-preliminaries.md b/spec/bandwidth-file-spec/scope-preliminaries.md
index 267d2cb..dd17d56 100644
--- a/spec/bandwidth-file-spec/scope-preliminaries.md
+++ b/spec/bandwidth-file-spec/scope-preliminaries.md
@@ -11,7 +11,7 @@ which we call version 1.0.0. It also specifies new format versions
 
 Since Tor version 0.2.4.12-alpha, the directory authorities use
 the Bandwidth File file called "V3BandwidthsFile" generated by
-Torflow [1]. The details of this format are described in Torflow's
+Torflow \[1\]. The details of this format are described in Torflow's
 README.spec.txt. We also summarise the format in this specification.
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
@@ -36,7 +36,7 @@ Iain Learmonth (irl)
 
 ## Outline
 
-The Tor directory protocol (dir-spec.txt [3]) sections 3.4.1
+The Tor directory protocol (dir-spec.txt \[3\]) sections 3.4.1
 and 3.4.2, use the term bandwidth measurements, to refer to what
 here is called Bandwidth File.
 
diff --git a/spec/bridgedb-spec.md b/spec/bridgedb-spec.md
index 2080e5d..8bce610 100644
--- a/spec/bridgedb-spec.md
+++ b/spec/bridgedb-spec.md
@@ -434,7 +434,7 @@ loading new bridges and assigning them to distributors.
 
 For every running bridge there is a line with the following format:
 
-fingerprint SP distributor (SP key "=" value)* NL
+fingerprint SP distributor (SP key "=" value)\* NL
 
 The distributor is one out of "email", "https", or "unallocated".
 
diff --git a/spec/cert-spec.md b/spec/cert-spec.md
index 79ee9b0..0b98f75 100644
--- a/spec/cert-spec.md
+++ b/spec/cert-spec.md
@@ -74,10 +74,10 @@ numbers.  So we'll choose a compact representation.
          SIGNATURE       [64 Bytes]
 ```
 
-The "VERSION" field holds the value [01].  The "CERT_TYPE" field
+The "VERSION" field holds the value \[01\].  The "CERT_TYPE" field
 holds a value depending on the type of certificate. (See appendix
 A.1.) The CERTIFIED_KEY field is an Ed25519 public key if
-CERT_KEY_TYPE is [01], or a digest of some other key type
+CERT_KEY_TYPE is \[01\], or a digest of some other key type
 depending on the value of CERT_KEY_TYPE.  (See appendix A.4.)
 The EXPIRATION_DATE is a date, given in HOURS since the epoch,
 after which this certificate isn't valid. (A four-byte field here
@@ -117,7 +117,7 @@ sizeof(ed25519_cert) - 64 bytes).
 
 <a id="cert-spec.txt-2.2.1"></a>
 
-### Signed-with-ed25519-key extension [type 04]
+### Signed-with-ed25519-key extension \[type 04\]
 
 In several places, it's desirable to bundle the key signing a
 certificate along with the certificate.  We do so with this
@@ -136,7 +136,7 @@ sign the certificate.
 
 ## RSA->Ed25519 cross-certificate
 
-Certificate type [07] (Cross-certification of Ed25519 identity
+Certificate type \[07\] (Cross-certification of Ed25519 identity
 with RSA key) contains the following data:
 
 ```text
@@ -206,7 +206,7 @@ certificate type enumeration of in our Ed25519 certificates.
 
 ## List of extension types
 
-[04] - signed-with-ed25519-key (section 2.2.1)
+\[04\] - signed-with-ed25519-key (section 2.2.1)
 
 <a id="cert-spec.txt-A.3"></a>
 
diff --git a/spec/control-spec/commands.md b/spec/control-spec/commands.md
index f59a548..d087473 100644
--- a/spec/control-spec/commands.md
+++ b/spec/control-spec/commands.md
@@ -52,7 +52,7 @@ its default value (if any), and then assign the String provided.
 Typically the String is left empty, to simply set an option back to
 its default. The syntax is:
 
-"RESETCONF" 1*(SP keyword ["=" String]) CRLF
+"RESETCONF" 1\*(SP keyword \["=" String\]) CRLF
 
 Otherwise it behaves like SETCONF above.
 
@@ -63,7 +63,7 @@ Otherwise it behaves like SETCONF above.
 Request the value of zero or more configuration variable(s).
 The syntax is:
 
-"GETCONF" *(SP keyword) CRLF
+"GETCONF" \*(SP keyword) CRLF
 
 If all of the listed keywords exist in the Tor configuration, Tor replies
 with a series of reply lines of the form:
@@ -101,9 +101,9 @@ HiddenServiceVersion, and HiddenserviceAuthorizeClient option settings.
 Request the server to inform the client about interesting events.  The
 syntax is:
 
-"SETEVENTS" [SP "EXTENDED"] *(SP EventCode) CRLF
+"SETEVENTS" \[SP "EXTENDED"\] \*(SP EventCode) CRLF
 
-EventCode = 1*(ALPHA / "_")  (see section 4.1.x for event types)
+EventCode = 1\*(ALPHA / "\_")  (see section 4.1.x for event types)
 
 Any events _not_ listed in the SETEVENTS line are turned off; thus, sending
 SETEVENTS with an empty body turns off all event reporting.
@@ -127,7 +127,7 @@ Each event is described in more detail in Section 4.1.
 
 Sent from the client to the server.  The syntax is:
 
-"AUTHENTICATE" [ SP 1*HEXDIG / QuotedString ] CRLF
+"AUTHENTICATE" \[ SP 1\*HEXDIG / QuotedString \] CRLF
 
 This command is used to authenticate to the server. The provided string is
 one of the following:
@@ -174,7 +174,7 @@ connection after an authentication failure.)
 
 Sent from the client to the server.  The syntax is:
 
-"SAVECONF" [SP "FORCE"] CRLF
+"SAVECONF" \[SP "FORCE"\] CRLF
 
 Instructs the server to write out its config options into its torrc. Server
 returns "250 OK" if successful, or "551 Unable to write configuration
@@ -252,7 +252,7 @@ signal that have them.
 
 Sent from the client to the server.  The syntax is:
 
-"MAPADDRESS" 1*(Address "=" Address SP) CRLF
+"MAPADDRESS" 1\*(Address "=" Address SP) CRLF
 
 The first address in each pair is an "original" address; the second is a
 "replacement" address.  The client sends this message to the server in
@@ -339,7 +339,7 @@ Example:
 
 Sent from the client to the server.  The syntax is as for GETCONF:
 
-"GETINFO" 1*(SP keyword) CRLF
+"GETINFO" 1\*(SP keyword) CRLF
 
 Unlike GETCONF, this message is used for data that are not stored in the Tor
 configuration file, and that may be longer than a single line.  On success,
@@ -1034,7 +1034,7 @@ historical interest.
 
 Sent from the client to the server.  The syntax is:
 
-"ATTACHSTREAM" SP StreamID SP CircuitID [SP "HOP=" HopNum] CRLF
+"ATTACHSTREAM" SP StreamID SP CircuitID \[SP "HOP=" HopNum\] CRLF
 
 This message informs the server that the specified stream should be
 associated with the specified circuit.  Each stream may be associated with
@@ -1061,8 +1061,8 @@ that turns out to be a problem.}
 
 {Implementation note: By default, Tor automatically attaches streams to
 circuits itself, unless the configuration variable
-"__LeaveStreamsUnattached" is set to "1".  Attempting to attach streams
-via TC when "__LeaveStreamsUnattached" is false may cause a race between
+"\_\_LeaveStreamsUnattached" is set to "1".  Attempting to attach streams
+via TC when "\_\_LeaveStreamsUnattached" is false may cause a race between
 Tor and the controller, as both attempt to attach streams to circuits.}
 
 {Implementation note: You can try to attachstream to a stream that
@@ -1105,7 +1105,7 @@ is added, Tor replies with "250 OK".
 
 Sent from the client to the server. The syntax is:
 
-"REDIRECTSTREAM" SP StreamID SP Address [SP Port] CRLF
+"REDIRECTSTREAM" SP StreamID SP Address \[SP Port\] CRLF
 
 Tells the server to change the exit address on the specified stream.  If
 Port is specified, changes the destination port as well.  No remapping
@@ -1123,7 +1123,7 @@ Tor replies with "250 OK" on success.
 
 Sent from the client to the server.  The syntax is:
 
-"CLOSESTREAM" SP StreamID SP Reason *(SP Flag) CRLF
+"CLOSESTREAM" SP StreamID SP Reason \*(SP Flag) CRLF
 
 Tells the server to close the specified stream.  The reason should be one
 of the Tor RELAY_END reasons given in tor-spec.txt, as a decimal.  Flags is
@@ -1227,7 +1227,7 @@ request (or reverse lookup if "mode=reverse" is specified).  Note that the
 request is done in the background: to see the answers, your controller will
 need to listen for ADDRMAP events; see 4.1.7 below.
 
-[Added in Tor 0.2.0.3-alpha]
+\[Added in Tor 0.2.0.3-alpha\]
 
 <a id="control-spec.txt-3.21"></a>
 
@@ -1235,11 +1235,11 @@ need to listen for ADDRMAP events; see 4.1.7 below.
 
 The syntax is:
 
-"PROTOCOLINFO" *(SP PIVERSION) CRLF
+"PROTOCOLINFO" \*(SP PIVERSION) CRLF
 
 The server reply format is:
 
-"250-PROTOCOLINFO" SP PIVERSION CRLF *InfoLine "250 OK" CRLF
+"250-PROTOCOLINFO" SP PIVERSION CRLF \*InfoLine "250 OK" CRLF
 
 InfoLine = AuthLine / VersionLine / OtherLine
 
@@ -1301,10 +1301,10 @@ a future version of Tor.
 
 The VERSION line contains the Tor version.
 
-[Unlike other commands besides AUTHENTICATE, PROTOCOLINFO may be used (but
-only once!) before AUTHENTICATE.]
+\[Unlike other commands besides AUTHENTICATE, PROTOCOLINFO may be used (but
+only once!) before AUTHENTICATE.\]
 
-[PROTOCOLINFO was not supported before Tor 0.2.0.5-alpha.]
+\[PROTOCOLINFO was not supported before Tor 0.2.0.5-alpha.\]
 
 <a id="control-spec.txt-3.22"></a>
 
@@ -1318,7 +1318,7 @@ This command allows a controller to upload the text of a config file
 to Tor over the control port.  This config file is then loaded as if
 it had been read from disk.
 
-[LOADCONF was added in Tor 0.2.1.1-alpha.]
+\[LOADCONF was added in Tor 0.2.1.1-alpha.\]
 
 <a id="control-spec.txt-3.23"></a>
 
@@ -1340,7 +1340,7 @@ want to ensure a clean shutdown--and you should!--then send "SIGNAL
 SHUTDOWN" and wait for the Tor process to close.)
 
 This command is intended to be used with the
-__OwningControllerProcess configuration option.  A controller that
+\_\_OwningControllerProcess configuration option.  A controller that
 starts a Tor process which the user cannot easily control or stop
 should 'own' that Tor process:
 
@@ -1422,10 +1422,10 @@ will accept is:
                 CookieString | ClientNonce | ServerNonce)
 ```
 
-[Unlike other commands besides AUTHENTICATE, AUTHCHALLENGE may be
-used (but only once!) before AUTHENTICATE.]
+\[Unlike other commands besides AUTHENTICATE, AUTHCHALLENGE may be
+used (but only once!) before AUTHENTICATE.\]
 
-[AUTHCHALLENGE was added in Tor 0.2.3.13-alpha.]
+\[AUTHCHALLENGE was added in Tor 0.2.3.13-alpha.\]
 
 <a id="control-spec.txt-3.25"></a>
 
@@ -1440,7 +1440,7 @@ lightly; it can increase vulnerability to tracking attacks over time.
 
 Tor replies with "250 OK" on success.
 
-[DROPGUARDS was added in Tor 0.2.5.2-alpha.]
+\[DROPGUARDS was added in Tor 0.2.5.2-alpha.\]
 
 <a id="control-spec.txt-3.26"></a>
 
@@ -1496,8 +1496,8 @@ Examples are:
      S: 250 OK
 ```
 
-[HSFETCH was added in Tor 0.2.7.1-alpha]
-[HS v3 support added 0.4.1.1-alpha]
+\[HSFETCH was added in Tor 0.2.7.1-alpha\]
+\[HS v3 support added 0.4.1.1-alpha\]
 
 <a id="control-spec.txt-3.27"></a>
 
@@ -1620,14 +1620,14 @@ RSAPrivateKey, with all newlines removed. For a "ED25519-V3" key is
 the Base64 encoding of the concatenation of the 32-byte ed25519 secret
 scalar in little-endian and the 32-byte ed25519 PRF secret.)
 
-[Note: The ED25519-V3 format is not the same as, e.g., SUPERCOP
+\[Note: The ED25519-V3 format is not the same as, e.g., SUPERCOP
 ed25519/ref, which stores the concatenation of the 32-byte ed25519
 hash seed concatenated with the 32-byte public key, and which derives
 the secret scalar and PRF secret by expanding the hash seed with
 SHA-512.  Our key blinding scheme is incompatible with storing
 private keys as seeds, so we store the secret scalar alongside the
 PRF secret, and just pay the cost of recomputing the public key when
-importing an ED25519-V3 key.]
+importing an ED25519-V3 key.\]
 
 Examples:
 
@@ -1675,12 +1675,12 @@ Examples:
      S: 250 OK
 ```
 
-[ADD_ONION was added in Tor 0.2.7.1-alpha.]
-[MaxStreams and MaxStreamsCloseCircuit were added in Tor 0.2.7.2-alpha]
-[ClientAuth was added in Tor 0.2.9.1-alpha. It is v2 only.]
-[NonAnonymous was added in Tor 0.2.9.3-alpha.]
-[HS v3 support added 0.3.3.1-alpha]
-[ClientV3Auth support added 0.4.6.1-alpha]
+\[ADD_ONION was added in Tor 0.2.7.1-alpha.\]
+\[MaxStreams and MaxStreamsCloseCircuit were added in Tor 0.2.7.2-alpha\]
+\[ClientAuth was added in Tor 0.2.9.1-alpha. It is v2 only.\]
+\[NonAnonymous was added in Tor 0.2.9.3-alpha.\]
+\[HS v3 support added 0.3.3.1-alpha\]
+\[ClientV3Auth support added 0.4.6.1-alpha\]
 
 <a id="control-spec.txt-3.28"></a>
 
@@ -1711,8 +1711,8 @@ removed via "DEL_ONION".
 Tor replies with "250 OK" on success, or a 512 if there are an invalid
 number of arguments, or a 552 if it doesn't recognize the ServiceID.
 
-[DEL_ONION was added in Tor 0.2.7.1-alpha.]
-[HS v3 support added 0.3.3.1-alpha]
+\[DEL_ONION was added in Tor 0.2.7.1-alpha.\]
+\[HS v3 support added 0.3.3.1-alpha\]
 
 <a id="control-spec.txt-3.29"></a>
 
@@ -1836,7 +1836,7 @@ On success "250 OK" is returned. Otherwise, the following error codes exist:
 
 The syntax is:
 
-"ONION_CLIENT_AUTH_VIEW" [SP HSAddress] CRLF
+"ONION_CLIENT_AUTH_VIEW" \[SP HSAddress\] CRLF
 
 Tells the connected Tor to list all the stored client-side v3 client auth
 credentials for "HSAddress". If no "HSAddress" is provided, list all the
@@ -1869,7 +1869,7 @@ On success "250 OK" is returned. Otherwise, the following error codes exist:
 
 512 - Syntax error in "HSAddress".
 
-[ONION_CLIENT_AUTH_VIEW was added in Tor 0.4.3.1-alpha]
+\[ONION_CLIENT_AUTH_VIEW was added in Tor 0.4.3.1-alpha\]
 
 <a id="control-spec.txt-3.33"></a>
 
@@ -1890,7 +1890,7 @@ does nothing.
 The controller can call TAKEOWNERSHIP again to re-establish
 ownership.
 
-[DROPOWNERSHIP was added in Tor 0.4.0.0-alpha]
+\[DROPOWNERSHIP was added in Tor 0.4.0.0-alpha\]
 
 <a id="control-spec.txt-3.34"></a>
 
@@ -1907,4 +1907,4 @@ lightly; it can increase vulnerability to tracking attacks over time.
 Tor replies with "250 OK" on success. Tor also emits the BUILDTIMEOUT_SET
 RESET event right after this "250 OK".
 
-[DROPTIMEOUTS was added in Tor 0.4.5.0-alpha.]
+\[DROPTIMEOUTS was added in Tor 0.4.5.0-alpha.\]
diff --git a/spec/control-spec/implementation-notes.md b/spec/control-spec/implementation-notes.md
index e69f755..37ce9d6 100644
--- a/spec/control-spec/implementation-notes.md
+++ b/spec/control-spec/implementation-notes.md
@@ -16,7 +16,7 @@ to another file specified in the 'CookieAuthFile' option).  To
 authenticate, the controller must demonstrate that it can read the
 contents of the cookie file:
 
-* Current versions of Tor support cookie authentication
+- Current versions of Tor support cookie authentication
 
 ```text
     using the "COOKIE" authentication method: the controller sends the
@@ -101,7 +101,7 @@ Generally, these options make Tor unusable by disabling a portion of Tor's
 normal operations.  Unless a controller provides replacement functionality
 to fill this gap, Tor will not correctly handle user requests.
 
-__AllDirActionsPrivate
+\_\_AllDirActionsPrivate
 
 ```text
     If true, Tor will try to launch all directory operations through
@@ -214,8 +214,8 @@ fails.
 Bootstrap phases can be viewed as belonging to one of three stages:
 
 1. Initial connection to a Tor relay or bridge
-2. Obtaining directory information
-3. Building an application circuit
+1. Obtaining directory information
+1. Building an application circuit
 
 Tor doesn't specifically enter Stage 1; that is a side effect of
 other actions that Tor is taking. Tor could be making a connection
@@ -240,7 +240,7 @@ of Tor building circuits for some purpose or other. In a typical
 client, Tor builds predicted circuits to provide lower latency for
 application connection requests. In Stage 3, Tor might make new
 connections to relays or bridges that it did not connect to in Stage
-1.
+1\.
 
 <a id="control-spec.txt-5.5.2"></a>
 
@@ -540,7 +540,7 @@ as indicated above. When bootstrap completes, Tor will be ready to handle
 an application requesting an internal circuit to hidden services at
 ".onion" addresses.
 
-If a future consensus contains Exits, exit circuits may become available.]
+If a future consensus contains Exits, exit circuits may become available.\]
 
 Phase 0:
 tag=starting summary="Starting"
@@ -649,7 +649,7 @@ indicate partial steps.
 ```
 
 Phase 80:
-tag=conn_or summary="Connecting to the Tor network[ internally]"
+tag=conn_or summary="Connecting to the Tor network\[ internally\]"
 
 Once we have a valid consensus and enough relay descriptors, we choose
 entry guard(s) and start trying to build some circuits. This step
@@ -685,7 +685,7 @@ handshake with a Tor relay.
 ```
 
 Phase 90:
-tag=circuit_create summary="Establishing a[n internal] Tor circuit"
+tag=circuit_create summary="Establishing a\[n internal\] Tor circuit"
 
 Once we've finished our TLS handshake with the first hop of a circuit,
 we will set about trying to make some 3-hop circuits in case we need them
@@ -718,4 +718,4 @@ as indicated above. At this stage, Tor will be ready to handle an
 application requesting an internal circuit to hidden services at ".onion"
 addresses.
 
-If a future consensus contains Exits, exit circuits may become available.]
+If a future consensus contains Exits, exit circuits may become available.\]
diff --git a/spec/control-spec/message-format.md b/spec/control-spec/message-format.md
index 2e3115b..5a1a6ad 100644
--- a/spec/control-spec/message-format.md
+++ b/spec/control-spec/message-format.md
@@ -13,7 +13,7 @@ We use the following nonterminals from RFC 2822: atom, qcontent
 
 We define the following general-use nonterminals:
 
-QuotedString = DQUOTE *qcontent DQUOTE
+QuotedString = DQUOTE \*qcontent DQUOTE
 
 There are explicitly no limits on line length.  All 8-bit characters
 are permitted unless explicitly disallowed.  In QuotedStrings,
@@ -28,13 +28,13 @@ Controllers SHOULD always send CRLF.
 
 ### Notes on an escaping bug
 
-CString = DQUOTE *qcontent DQUOTE
+CString = DQUOTE \*qcontent DQUOTE
 
 Note that although these nonterminals have the same grammar, they
 are interpreted differently.  In a QuotedString, a backslash
 followed by any character represents that character.  But
-in a CString, the escapes "\n", "\t", "\r", and the octal escapes
-"\0" ... "\377" represent newline, tab, carriage return, and the
+in a CString, the escapes "\\n", "\\t", "\\r", and the octal escapes
+"\\0" ... "\\377" represent newline, tab, carriage return, and the
 256 possible octet values respectively.
 
 The use of CString in this document reflects a bug in Tor;
@@ -101,11 +101,11 @@ Tor to the controller are guaranteed to share the same status
 code. Specific replies are mentioned below in section 3, and
 described more fully in section 4.
 
-[Compatibility note:  versions of Tor before 0.2.0.3-alpha sometimes
-generate AsyncReplies of the form "*(MidReplyLine / DataReplyLine)".
+\[Compatibility note:  versions of Tor before 0.2.0.3-alpha sometimes
+generate AsyncReplies of the form "\*(MidReplyLine / DataReplyLine)".
 This is incorrect, but controllers that need to work with these
 versions of Tor should be prepared to get multi-line AsyncReplies with
-the final line (usually "650 OK") omitted.]
+the final line (usually "650 OK") omitted.\]
 
 <a id="control-spec.txt-2.4"></a>
 
@@ -132,13 +132,13 @@ CRLF = CR LF
 ; The tokens that implement the above follow:
 
 ServerSpec = LongName / Nickname
-LongName   = Fingerprint [ "~" Nickname ]
+LongName   = Fingerprint \[ "~" Nickname \]
 
 ; For tors older than 0.3.1.3-alpha, LongName may have included an equal
 ; sign ("=") in lieu of a tilde ("~").  The presence of an equal sign
 ; denoted that the OR possessed the "Named" flag:
 
-LongName   = Fingerprint [ ( "=" / "~" ) Nickname ]
+LongName   = Fingerprint \[ ( "=" / "~" ) Nickname \]
 
 Fingerprint = "$" 40*HEXDIG
 NicknameChar = "a"-"z" / "A"-"Z" / "0" - "9"
@@ -167,7 +167,7 @@ Address = ip4-address / ip6-address / hostname   (XXXX Define these)
 CmdData = *DataLine "." CRLF
 DataLine = CRLF / "." 1*LineItem CRLF / NonDotItem *LineItem CRLF
 LineItem = NonCR / 1*CR NonCRLF
-NonDotItem = NonDotCR / 1*CR NonCRLF
+NonDotItem = NonDotCR / 1\*CR NonCRLF
 
 ; ISOTime, ISOTime2, and ISOTime2Frac are time formats as specified in
 ; ISO8601.
@@ -178,8 +178,8 @@ IsoDatePart = 4*DIGIT "-" 2*DIGIT "-" 2*DIGIT
 IsoTimePart = 2*DIGIT ":" 2*DIGIT ":" 2*DIGIT
 ISOTime  = IsoDatePart " " IsoTimePart
 ISOTime2 = IsoDatePart "T" IsoTimePart
-ISOTime2Frac = IsoTime2 [ "." 1*DIGIT ]
+ISOTime2Frac = IsoTime2 \[ "." 1\*DIGIT \]
 
 ; Numbers
 LeadingDigit = "1" - "9"
-UInt = LeadingDigit *Digit
+UInt = LeadingDigit \*Digit
diff --git a/spec/control-spec/protocol-outline.md b/spec/control-spec/protocol-outline.md
index feeef1b..0329b1d 100644
--- a/spec/control-spec/protocol-outline.md
+++ b/spec/control-spec/protocol-outline.md
@@ -33,7 +33,7 @@ where servers speaking a future version of this protocol may insert
 new data, and note that clients should/must "tolerate" unexpected
 elements in these places.  There are two ways that we do this:
 
-* Adding a new field to a message:
+- Adding a new field to a message:
 
 ```text
     For example, we might say "This message has three space-separated
diff --git a/spec/control-spec/replies.md b/spec/control-spec/replies.md
index c55635c..c7b1ab7 100644
--- a/spec/control-spec/replies.md
+++ b/spec/control-spec/replies.md
@@ -121,11 +121,11 @@ Tor 0.2.2.x and later), then each event line as specified below may be
 followed by additional arguments and additional lines.  Additional
 lines will be of the form:
 
-"650" ("-"/" ") KEYWORD ["=" ARGUMENTS] CRLF
+"650" ("-"/" ") KEYWORD \["=" ARGUMENTS\] CRLF
 
 Additional arguments will be of the form
 
-SP KEYWORD ["=" ( QuotedString / * NonSpDquote ) ]
+SP KEYWORD \["=" ( QuotedString / * NonSpDquote ) \]
 
 Clients MUST tolerate events with arguments and keywords they do not
 recognize, and SHOULD process those events as if any unrecognized
@@ -542,9 +542,9 @@ The syntax is:
      Num = 1*DIGIT
 ```
 
-BytesRead and BytesWritten are the totals. [In a future Tor version,
+BytesRead and BytesWritten are the totals. \[In a future Tor version,
 we may also include a breakdown of the connection types that used
-bandwidth this second (not implemented yet).]
+bandwidth this second (not implemented yet).\]
 
 <a id="control-spec.txt-4.1.5"></a>
 
@@ -615,7 +615,7 @@ Syntax:
 
 Error and UTCExpiry are only provided if extended events are enabled.
 The values for Error are mostly useless.  Future values will be
-chosen to match 1*(ALNUM / "_"); the "Unable to launch resolve request"
+chosen to match 1\*(ALNUM / "\_"); the "Unable to launch resolve request"
 value is a bug in Tor before 0.2.4.7-alpha.
 
 Expiry is expressed as the local time (rather than UTC).  This is a bug,
@@ -632,7 +632,7 @@ the address was resolved.
 
 ### Descriptors uploaded to us in our role as authoritative dirserver
 
-[NOTE: This feature was removed in Tor 0.3.2.1-alpha.]
+\[NOTE: This feature was removed in Tor 0.3.2.1-alpha.\]
 
 Tor generates this event when it's a directory authority, and
 somebody has just uploaded a server descriptor.
@@ -662,7 +662,7 @@ Syntax:
 
 "650" SP "DESCCHANGED" CRLF
 
-[First added in 0.1.2.2-alpha.]
+\[First added in 0.1.2.2-alpha.\]
 
 <a id="control-spec.txt-4.1.10"></a>
 
@@ -1151,7 +1151,7 @@ The Status values are:
 
 Syntax:
 
-"650" "+" "NS" CRLF 1*NetworkStatus "." CRLF "650" SP "OK" CRLF
+"650" "+" "NS" CRLF 1\*NetworkStatus "." CRLF "650" SP "OK" CRLF
 
 The event is used whenever our local view of a relay status changes.
 This happens when we get a new v3 consensus (in which case the entries
@@ -1159,7 +1159,7 @@ we see are a duplicate of what we see in the NEWCONSENSUS event,
 below), but it also happens when we decide to mark a relay as up or
 down in our local status, for example based on connection attempts.
 
-[First added in 0.1.2.3-alpha]
+\[First added in 0.1.2.3-alpha\]
 
 <a id="control-spec.txt-4.1.13"></a>
 
@@ -1243,7 +1243,7 @@ every relay in the consensus. NEWCONSENSUS is a separate event from the
 NS event, because the list here represents every usable relay: so any
 relay *not* mentioned in this list is implicitly no longer recommended.
 
-[First added in 0.2.1.13-alpha]
+\[First added in 0.2.1.13-alpha\]
 
 <a id="control-spec.txt-4.1.16"></a>
 
@@ -1285,7 +1285,7 @@ of build times Tor stores (NCIRCUITS_TO_OBSERVE).
 The Timeout itself is provided in milliseconds. Internally, Tor rounds
 this value to the nearest second before using it.
 
-[First added in 0.2.2.7-alpha]
+\[First added in 0.2.2.7-alpha\]
 
 <a id="control-spec.txt-4.1.17"></a>
 
@@ -1309,7 +1309,7 @@ semantics of the signals here.
 Note that the HALT (SIGTERM) and SHUTDOWN (SIGINT) signals do not currently
 generate any event.
 
-[First added in 0.2.3.1-alpha]
+\[First added in 0.2.3.1-alpha\]
 
 <a id="control-spec.txt-4.1.18"></a>
 
@@ -1317,7 +1317,7 @@ generate any event.
 
 The syntax is:
 
-StartReplyLine *(MidReplyLine) EndReplyLine
+StartReplyLine \*(MidReplyLine) EndReplyLine
 
 ```text
      StartReplyLine = "650-CONF_CHANGED" CRLF
@@ -1356,7 +1356,7 @@ purpose.
 
 Other fields are as specified in section 4.1.1 above.
 
-[First added in 0.2.3.11-alpha]
+\[First added in 0.2.3.11-alpha\]
 
 <a id="control-spec.txt-4.1.20"></a>
 
@@ -1407,7 +1407,7 @@ These events are generated about once per second per connection; no
 events are generated for connections that have not read or written.
 These events are only generated if TestingTorNetwork is set.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
 <a id="control-spec.txt-4.1.22"></a>
 
@@ -1477,12 +1477,12 @@ These events are generated about once per second per circuit; no events
 are generated for circuits that had no attached stream writing or
 reading.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
-[DELIVERED_READ, OVERHEAD_READ, DELIVERED_WRITTEN, and OVERHEAD_WRITTEN
-were added in Tor 0.3.4.0-alpha]
+\[DELIVERED_READ, OVERHEAD_READ, DELIVERED_WRITTEN, and OVERHEAD_WRITTEN
+were added in Tor 0.3.4.0-alpha\]
 
-[SS, CWND, RTT, and MIN_RTT were added in Tor 0.4.7.5-alpha]
+\[SS, CWND, RTT, and MIN_RTT were added in Tor 0.4.7.5-alpha\]
 
 <a id="control-spec.txt-4.1.23"></a>
 
@@ -1554,7 +1554,7 @@ These events are generated about once per second per circuit; no
 events are generated for circuits that have not added or processed any
 cell.  These events are only generated if TestingTorNetwork is set.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
 <a id="control-spec.txt-4.1.24"></a>
 
@@ -1603,7 +1603,7 @@ at LastRefill in order not to report empty times more than once.
 
 These events are only generated if TestingTorNetwork is set.
 
-[First added in 0.2.5.2-alpha]
+\[First added in 0.2.5.2-alpha\]
 
 <a id="control-spec.txt-4.1.25"></a>
 
@@ -1714,8 +1714,8 @@ takes to fetch something over the Tor network. This can be between a
 couple of seconds up to 60 seconds (not a hard limit). But, in any cases,
 this event will reply either the descriptor's content or an empty one.
 
-[HS_DESC_CONTENT was added in Tor 0.2.7.1-alpha]
-[HS v3 support added 0.3.3.1-alpha]
+\[HS_DESC_CONTENT was added in Tor 0.2.7.1-alpha\]
+\[HS v3 support added 0.3.3.1-alpha\]
 
 <a id="control-spec.txt-4.1.27"></a>
 
diff --git a/spec/dir-list-spec.md b/spec/dir-list-spec.md
index 0dbb750..a3e6aae 100644
--- a/spec/dir-list-spec.md
+++ b/spec/dir-list-spec.md
@@ -223,9 +223,9 @@ C-style comments.
 
 ### List Header Format
 
-"/*" SP+ "type=" Keyword SP+ "*/" SP* NL
+"/*" SP+ "type=" Keyword SP+ "*/" SP\* NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 ```text
        The type of directory entries in the list. Parsers SHOULD exit with
@@ -321,7 +321,7 @@ The list generation section MUST NOT be a valid directory entry.
 
 The list generation summary MUST end with a section separator:
 
-separator SP* NL
+separator SP\* NL
 
 There MUST NOT be any section separators in the list generation
 section, other than the terminating section separator.
@@ -569,7 +569,7 @@ URL: https:onionoo.torproject.orgdetails?fields=fingerprint%2Cnickname%2Ccontact
 Onionoo Source: uptime Date: 2017-05-16 07:00:00 Version: 4.0
 URL: https:onionoo.torproject.orguptime?first_seen_days=30-&flag=V2Dir&type=relay&last_seen_days=-0
 */
-/* ===== */
+/* ===== \*/
 
 <a id="dir-list-spec.txt-A.1.3"></a>
 
@@ -581,7 +581,7 @@ URL: https:onionoo.torproject.orguptime?first_seen_days=30-&flag=V2Dir&type=rela
 /* ===== */
 ,
 "5.9.110.236:9030 orport=9001 id=0756B7CD4DFC8182BE23143FAC0642F515182CEB"
-" ipv6=[2a01:4f8:162:51e2::2]:9001"
+" ipv6=\[2a01:4f8:162:51e2::2\]:9001"
 /* nickname= */
 /* extrainfo=0 */
 /* =====*/
diff --git a/spec/dir-spec/assigning-flags-vote.md b/spec/dir-spec/assigning-flags-vote.md
index 84d024b..7b7a59e 100644
--- a/spec/dir-spec/assigning-flags-vote.md
+++ b/spec/dir-spec/assigning-flags-vote.md
@@ -63,12 +63,12 @@ through 0.1.1.16-rc are stupid this way.)
 
 To calculate weighted MTBF, compute the weighted mean of the lengths
 of all intervals when the router was observed to be up, weighting
-intervals by $\alpha^n$, where $n$ is the amount of time that has
-passed since the interval ended, and $\alpha$ is chosen so that
+intervals by $\\alpha^n$, where $n$ is the amount of time that has
+passed since the interval ended, and $\\alpha$ is chosen so that
 measurements over approximately one month old no longer influence the
 weighted MTBF much.
 
-[XXXX what happens when we have less than 4 days of MTBF info.]
+\[XXXX what happens when we have less than 4 days of MTBF info.\]
 
 "Exit" -- A router is called an 'Exit' iff it allows exits to at
 least one /8 address space on each of ports 80 and 443. (Up until
diff --git a/spec/dir-spec/client-operation.md b/spec/dir-spec/client-operation.md
index 3f19a61..42a5906 100644
--- a/spec/dir-spec/client-operation.md
+++ b/spec/dir-spec/client-operation.md
@@ -55,7 +55,7 @@ as indicated above. When bootstrap completes, Tor will be ready to handle
 an application requesting an internal circuit to hidden services at
 ".onion" addresses.
 
-If a future consensus contains Exits, exit circuits may become available.]
+If a future consensus contains Exits, exit circuits may become available.\]
 
 (Note: clients can and should pick caches based on the network-status
 information they have: once they have first fetched network-status info
@@ -95,7 +95,7 @@ most recent consensus it has if that consensus is "reasonably live". A
 Clients try to have the best descriptor for each router.  A descriptor is
 "best" if:
 
-* It is listed in the consensus network-status document.
+- It is listed in the consensus network-status document.
 
 Periodically (currently every 10 seconds) clients check whether there are
 any "downloadable" descriptors.  A descriptor is downloadable if:
@@ -182,7 +182,7 @@ We follow the same splitting and back-off rules as in section 5.2.
 
 ## Using directory information
 
-[XXX This subsection really belongs in path-spec.txt, not here. -KL]
+\[XXX This subsection really belongs in path-spec.txt, not here. -KL\]
 
 Everyone besides directory authorities uses the approaches in this section
 to decide which relays to use and what their keys are likely to be.
@@ -194,7 +194,7 @@ above.)
 ### Choosing routers for circuits
 
 Circuits SHOULD NOT be built until the client has enough directory
-information: a live consensus network status [XXXX fallback?]  and
+information: a live consensus network status \[XXXX fallback?\]  and
 descriptors for at least 1/4 of the relays believed to be running.
 
 A relay is "listed" if it is included by the consensus network-status
diff --git a/spec/dir-spec/computing-microdescriptors.md b/spec/dir-spec/computing-microdescriptors.md
index 1b88e42..5270ffa 100644
--- a/spec/dir-spec/computing-microdescriptors.md
+++ b/spec/dir-spec/computing-microdescriptors.md
@@ -26,8 +26,8 @@ same microdescriptor.
 
 "onion-key" NL a public key in PEM format
 
-[Exactly once, at start]
-[No extra arguments]
+\[Exactly once, at start\]
+\[No extra arguments\]
 
 The "onion-key" element as specified in section 2.1.1.
 
@@ -37,18 +37,18 @@ earlier, the trailing = sign must be present.
 
 "ntor-onion-key" SP base-64-encoded-key NL
 
-[Exactly once]
+\[Exactly once\]
 
 The "ntor-onion-key" element as specified in section 2.1.1.
 
 (Only included when generating microdescriptors for
 consensus-method 16 or later.)
 
-[Before Tor 0.4.5.1-alpha, this field was optional.]
+\[Before Tor 0.4.5.1-alpha, this field was optional.\]
 
 "a" SP address ":" port NL
 
-[Any number]
+\[Any number\]
 
 Additional advertised addresses for the OR.
 
@@ -64,7 +64,7 @@ consensus-methods 14 to 27.)
 
 "family" names NL
 
-[At most once]
+\[At most once\]
 
 The "family" element as specified in section 2.1.1.
 
@@ -98,20 +98,20 @@ this is what makes the algorithm forward-compatible.)
 
 "p" SP ("accept" / "reject") SP PortList NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The exit-policy summary as specified in sections 3.4.1 and 3.8.2.
 
-[With microdescriptors, clients don't learn exact exit policies:
+\[With microdescriptors, clients don't learn exact exit policies:
 clients can only guess whether a relay accepts their request, try the
 BEGIN request, and might get end-reason-exit-policy if they guessed
-wrong, in which case they'll have to try elsewhere.]
+wrong, in which case they'll have to try elsewhere.\]
 
-[In consensus methods before 5, this line was omitted.]
+\[In consensus methods before 5, this line was omitted.\]
 
 "p6" SP ("accept" / "reject") SP PortList NL
 
-[At most once]
+\[At most once\]
 
 The IPv6 exit policy summary as specified in sections 3.4.1 and
 3.8.2. A missing "p6" line is equivalent to "p6 reject 1-65535".
@@ -121,7 +121,7 @@ consensus-method 15 or later.)
 
 "id" SP "rsa1024" SP base64-encoded-identity-digest NL
 
-[At most once]
+\[At most once\]
 
 The node identity digest (as described in tor-spec.txt), base64
 encoded, without trailing =s.  This line is included to prevent
@@ -135,7 +135,7 @@ consensus-method 18 or later.)
 
 "id" SP "ed25519" SP base64-encoded-ed25519-identity NL
 
-[At most once]
+\[At most once\]
 
 The node's master Ed25519 identity key, base64 encoded,
 without trailing =s.
@@ -149,18 +149,18 @@ consensus-method 21 or later.)
 
 "id" SP keytype ... NL
 
-[At most once per distinct keytype.]
+\[At most once per distinct keytype.\]
 
 Implementations MUST ignore "id" lines with unrecognized
 key-types in place of "rsa1024" or "ed25519"
 
 "pr" SP Entries NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The "proto" element as specified in section 2.1.1.
 
-[Before Tor 0.4.5.1-alpha, this field was optional.]
+\[Before Tor 0.4.5.1-alpha, this field was optional.\]
 
 (Note that with microdescriptors, clients do not learn the RSA identity of
 their routers: they only learn a hash of the RSA identity key.  This is
diff --git a/spec/dir-spec/converting-curve25519-public-key-to-ed25519-public.md b/spec/dir-spec/converting-curve25519-public-key-to-ed25519-public.md
index a676228..57f9d1d 100644
--- a/spec/dir-spec/converting-curve25519-public-key-to-ed25519-public.md
+++ b/spec/dir-spec/converting-curve25519-public-key-to-ed25519-public.md
@@ -45,8 +45,8 @@ To get the sign, the easiest way is to take the corresponding
 private key, feed it to the ed25519 public key generation
 algorithm, and see what the sign is.
 
-[Recomputing the sign bit from the private key every time sounds
-rather strange and inefficient to me… —isis]
+\[Recomputing the sign bit from the private key every time sounds
+rather strange and inefficient to me… —isis\]
 
 Note that in addition to its coordinates, an expanded Ed25519 private key
 also has a 32-byte random value, "prefix", used to compute internal `r`
@@ -55,7 +55,7 @@ derived deterministically from the curve25519 key.  The Tor
 implementation derives it as `SHA512(private_key | STR)[0..32]`, where
 STR is the nul-terminated string:
 
-"Derive high part of ed25519 key from curve25519 key\0"
+"Derive high part of ed25519 key from curve25519 key\\0"
 
 On the client side, where there is no access to the curve25519 private
 keys, one may use the curve25519 public key's Montgomery u-coordinate to
diff --git a/spec/dir-spec/creating-key-certificates.md b/spec/dir-spec/creating-key-certificates.md
index 56b715b..ebe3e2f 100644
--- a/spec/dir-spec/creating-key-certificates.md
+++ b/spec/dir-spec/creating-key-certificates.md
@@ -6,7 +6,7 @@ Key certificates consist of the following items:
 
 "dir-key-certificate-version" version NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 Determines the version of the key certificate.  MUST be "3" for
 the protocol described in this document.  Implementations MUST
@@ -28,8 +28,8 @@ identity key.
 
 "dir-identity-key" NL a public key in PEM format
 
-[Exactly once.]
-[No extra arguments]
+\[Exactly once.\]
+\[No extra arguments\]
 
 The long-term authority identity key for this authority.  This key
 SHOULD be at least 2048 bits long; it MUST NOT be shorter than
@@ -37,7 +37,7 @@ SHOULD be at least 2048 bits long; it MUST NOT be shorter than
 
 "dir-key-published" YYYY-MM-DD HH:MM:SS NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The time (in UTC) when this document and corresponding key were
 last generated.
@@ -47,7 +47,7 @@ too far in the future, though they MAY tolerate some clock skew.
 
 "dir-key-expires" YYYY-MM-DD HH:MM:SS NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 A time (in UTC) after which this key is no longer valid.
 
@@ -56,16 +56,16 @@ MAY tolerate some clock skew.
 
 "dir-signing-key" NL a key in PEM format
 
-[Exactly once.]
-[No extra arguments]
+\[Exactly once.\]
+\[No extra arguments\]
 
 The directory server's public signing key.  This key MUST be at
 least 1024 bits, and MAY be longer.
 
 "dir-key-crosscert" NL CrossSignature NL
 
-[Exactly once.]
-[No extra arguments]
+\[Exactly once.\]
+\[No extra arguments\]
 
 CrossSignature is a signature, made using the certificate's signing
 key, of the digest of the PKCS1-padded hash of the certificate's
@@ -79,8 +79,8 @@ of the hash of the identity key using the signing key.
 
 "dir-key-certification" NL Signature NL
 
-[At end, exactly once.]
-[No extra arguments]
+\[At end, exactly once.\]
+\[No extra arguments\]
 
 A document signature as documented in section 1.3, using the
 initial item "dir-key-certificate-version" and the final item
diff --git a/spec/dir-spec/directory-cache-operation.md b/spec/dir-spec/directory-cache-operation.md
index 8b3bfce..9807857 100644
--- a/spec/dir-spec/directory-cache-operation.md
+++ b/spec/dir-spec/directory-cache-operation.md
@@ -57,7 +57,7 @@ caches SHOULD try to hold those which clients are likely to download the
 most.  (Currently, this is judged based on the interval for which each
 descriptor seemed newest.)
 
-[XXXX define recent]
+\[XXXX define recent\]
 
 <a id="dir-spec.txt-4.3"></a>
 
diff --git a/spec/dir-spec/extra-info-document-format.md b/spec/dir-spec/extra-info-document-format.md
index 1c7dffe..24d6a03 100644
--- a/spec/dir-spec/extra-info-document-format.md
+++ b/spec/dir-spec/extra-info-document-format.md
@@ -98,7 +98,7 @@ the old ones, the new keywords have been introduced.
 YYYY-MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).
 
-A "bridge-stats-end" line, as well as any other "bridge-*" line,
+A "bridge-stats-end" line, as well as any other "bridge-\*" line,
 is only added when the relay has been running as a bridge for at
 least 24 hours.
 
@@ -152,7 +152,7 @@ If no clients have connected to the bridge yet, we only write
 YYYY-MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).
 
-A "dirreq-stats-end" line, as well as any other "dirreq-*" line,
+A "dirreq-stats-end" line, as well as any other "dirreq-\*" line,
 is only added when the relay has opened its Dir port and after 24
 hours of measuring directory requests.
 
@@ -287,7 +287,7 @@ recent intervals, ordered from oldest to newest.
 YYYY-MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).
 
-An "entry-stats-end" line, as well as any other "entry-*"
+An "entry-stats-end" line, as well as any other "entry-\*"
 line, is first added after the relay has been running for at least
 24 hours.
 
@@ -309,7 +309,7 @@ nearest multiple of 8.
 YYYY-MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).
 
-A "cell-stats-end" line, as well as any other "cell-*" line,
+A "cell-stats-end" line, as well as any other "cell-\*" line,
 is first added after the relay has been running for at least 24
 hours.
 
@@ -393,7 +393,7 @@ bi-directionally. See "conn-bi-direct" for more details.
 YYYY-MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).
 
-An "exit-stats-end" line, as well as any other "exit-*" line, is
+An "exit-stats-end" line, as well as any other "exit-\*" line, is
 first added after the relay has been running for at least 24 hours
 and only if the relay permits exiting (where exiting to a single
 port and IP address is sufficient).
@@ -431,7 +431,7 @@ streams under port "other".
 YYYY-MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).
 
-A "hidserv-stats-end" line, as well as any other "hidserv-*" line,
+A "hidserv-stats-end" line, as well as any other "hidserv-\*" line,
 is first added after the relay has been running for at least 24
 hours.
 
diff --git a/spec/dir-spec/general-use-http-urls.md b/spec/dir-spec/general-use-http-urls.md
index 4d11372..98ea7a5 100644
--- a/spec/dir-spec/general-use-http-urls.md
+++ b/spec/dir-spec/general-use-http-urls.md
@@ -61,7 +61,7 @@ key fingerprint is `<S>` should be available at:
 
 `http://<hostname>/tor/keys/fp-sk/<F1>-<S1>+<F2>-<S2>.z`  )
 
-[The above fp-sk format was not supported before Tor 0.2.1.9-alpha.]
+\[The above fp-sk format was not supported before Tor 0.2.1.9-alpha.\]
 
 The most recent descriptor for a server whose identity key has a
 fingerprint of `<F>` should be available at:
diff --git a/spec/dir-spec/nonterminals-server-descriptors.md b/spec/dir-spec/nonterminals-server-descriptors.md
index 62298cb..4991e9e 100644
--- a/spec/dir-spec/nonterminals-server-descriptors.md
+++ b/spec/dir-spec/nonterminals-server-descriptors.md
@@ -11,7 +11,7 @@
 ```
 
 exitpattern ::= addrspec ":" portspec
-portspec ::= "*" | port | port "-" port
+portspec ::= "\*" | port | port "-" port
 port ::= an integer between 1 and 65535, inclusive.
 
 ```text
@@ -20,7 +20,7 @@ port ::= an integer between 1 and 65535, inclusive.
        Connections to port 0 are never permitted.]
 ```
 
-addrspec ::= "*" | ip4spec | ip6spec
+addrspec ::= "\*" | ip4spec | ip6spec
 ipv4spec ::= ip4 | ip4 "/" num_ip4_bits | ip4 "/" ip4mask
 ip4 ::= an IPv4 address in dotted-quad format
 ip4mask ::= an IPv4 mask in dotted-quad format
diff --git a/spec/dir-spec/outline.md b/spec/dir-spec/outline.md
index faa848a..e183e33 100644
--- a/spec/dir-spec/outline.md
+++ b/spec/dir-spec/outline.md
@@ -70,7 +70,7 @@ The highest level object is a Document, which consists of one or more
 Items.  Every Item begins with a KeywordLine, followed by zero or more
 Objects. A KeywordLine begins with a Keyword, optionally followed by
 whitespace and more non-newline characters, and ends with a newline.  A
-Keyword is a sequence of one or more characters in the set [A-Za-z0-9-],
+Keyword is a sequence of one or more characters in the set \[A-Za-z0-9-\],
 but may not start with -.
 An Object is a block of encoded data in pseudo-Privacy-Enhanced-Mail (PEM)
 style format: that is, lines of encoded data MAY be wrapped by inserting
diff --git a/spec/dir-spec/server-descriptor-format.md b/spec/dir-spec/server-descriptor-format.md
index 97b7d09..49820fc 100644
--- a/spec/dir-spec/server-descriptor-format.md
+++ b/spec/dir-spec/server-descriptor-format.md
@@ -16,7 +16,7 @@ such blank lines.
 
 "router" nickname address ORPort SOCKSPort DirPort NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 Indicates the beginning of a server descriptor.  "nickname" must be a
 valid router nickname as specified in section 2.1.3.  "address" must
@@ -36,33 +36,33 @@ authorities MAY reject any descriptor with both DirPort and ORPort of
            "-----END ED25519 CERT-----" NL
 ```
 
-[Exactly once, in second position in document.]
-[No extra arguments]
+\[Exactly once, in second position in document.\]
+\[No extra arguments\]
 
 The certificate is a base64-encoded Ed25519 certificate (see
 cert-spec.txt) with terminating =s removed.  When this element
 is present, it MUST appear as the first or second element in
 the router descriptor.
 
-The certificate has CERT_TYPE of [04].  It must include a
+The certificate has CERT_TYPE of \[04\].  It must include a
 signed-with-ed25519-key extension (see cert-spec.txt,
 section 2.2.1), so that we can extract the master identity key.
 
-[Before Tor 0.4.5.1-alpha, this field was optional.]
+\[Before Tor 0.4.5.1-alpha, this field was optional.\]
 
 "master-key-ed25519" SP MasterKey NL
 
-[Exactly once]
+\[Exactly once\]
 
 Contains the base-64 encoded ed25519 master key as a single
 argument.  If it is present, it MUST match the identity key
 in the identity-ed25519 entry.
 
-[Before Tor 0.4.5.1-alpha, this field was optional.]
+\[Before Tor 0.4.5.1-alpha, this field was optional.\]
 
 "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL
 
-[Exactly once]
+\[Exactly once\]
 
 Estimated bandwidth for this router, in bytes per second.  The
 "average" bandwidth is the volume per second that the OR is willing to
@@ -78,7 +78,7 @@ day. These versions are no longer supported or recommended.
 
 "platform" string NL
 
-[At most once]
+\[At most once\]
 
 A human-readable string describing the system on which this OR is
 running.  This MAY include the operating system, and SHOULD include
@@ -86,14 +86,14 @@ the name and version of the software implementing the Tor protocol.
 
 "published" YYYY-MM-DD HH:MM:SS NL
 
-[Exactly once]
+\[Exactly once\]
 
 The time, in UTC, when this descriptor (and its corresponding
 extra-info document if any) was generated.
 
 "fingerprint" fingerprint NL
 
-[At most once]
+\[At most once\]
 
 A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded in
 hex, with a single space after every 4 characters) for this router's
@@ -125,8 +125,8 @@ descriptor was published, and shouldn't be used to build circuits.
     "onion-key" NL a public key in PEM format
 ```
 
-[Exactly once]
-[No extra arguments]
+\[Exactly once\]
+\[No extra arguments\]
 
 This key is used to encrypt CREATE cells for this OR.  The key MUST be
 accepted for at least 1 week after any new key is published in a
@@ -138,8 +138,8 @@ KEY-----" and "-----END RSA PUBLIC KEY-----".
 
 "onion-key-crosscert" NL a RSA signature in PEM format.
 
-[Exactly once]
-[No extra arguments]
+\[Exactly once\]
+\[No extra arguments\]
 
 This element contains an RSA signature, generated using the
 onion-key, of the following:
@@ -162,12 +162,12 @@ This signature proves that the party creating the descriptor
 had control over the secret key corresponding to the
 onion-key.
 
-[Before Tor 0.4.5.1-alpha, this field was optional whenever
-identity-ed25519 was absent.]
+\[Before Tor 0.4.5.1-alpha, this field was optional whenever
+identity-ed25519 was absent.\]
 
 "ntor-onion-key" base-64-encoded-key
 
-[Exactly once]
+\[Exactly once\]
 
 A curve25519 public key used for the ntor circuit extended
 handshake.  It's the standard encoding of the OR's curve25519
@@ -176,7 +176,7 @@ omitted from the base64 encoding.  The key MUST be accepted
 for at least 1 week after any new key is published in a
 subsequent descriptor.
 
-[Before Tor 0.4.5.1-alpha, this field was optional.]
+\[Before Tor 0.4.5.1-alpha, this field was optional.\]
 
 ```text
     "ntor-onion-key-crosscert" SP Bit NL
@@ -184,12 +184,12 @@ subsequent descriptor.
            "-----END ED25519 CERT-----" NL
 ```
 
-[Exactly once]
-[No extra arguments]
+\[Exactly once\]
+\[No extra arguments\]
 
 A signature created with the ntor-onion-key, using the
 certificate format documented in cert-spec.txt, with type
-[0a].  The signed key here is the master identity key.
+\[0a\].  The signed key here is the master identity key.
 
 Bit must be "0" or "1".  It indicates the sign of the ed25519
 public key corresponding to the ntor onion key.  If Bit is "0",
@@ -204,13 +204,13 @@ This signature proves that the party creating the descriptor
 had control over the secret key corresponding to the
 ntor-onion-key.
 
-[Before Tor 0.4.5.1-alpha, this field was optional whenever
-identity-ed25519 was absent.]
+\[Before Tor 0.4.5.1-alpha, this field was optional whenever
+identity-ed25519 was absent.\]
 
 "signing-key" NL a public key in PEM format
 
-[Exactly once]
-[No extra arguments]
+\[Exactly once\]
+\[No extra arguments\]
 
 The OR's long-term RSA identity key.  It MUST be 1024 bits.
 
@@ -219,7 +219,7 @@ The encoding is as for "onion-key" above.
 "accept" exitpattern NL
 "reject" exitpattern NL
 
-[Any number]
+\[Any number\]
 
 These lines describe an "exit policy": the rules that an OR follows
 when deciding whether to allow a new stream to a given address.  The
@@ -230,7 +230,7 @@ be accept *:* or reject *:*.
 
 "ipv6-policy" SP ("accept" / "reject") SP PortList NL
 
-[At most once.]
+\[At most once.\]
 
 An exit-policy summary as specified in sections 3.4.1 and 3.8.2,
 summarizing
@@ -240,7 +240,7 @@ the router's rules for connecting to IPv6 addresses. A missing
 
 "overload-general" SP version SP YYYY-MM-DD HH:MM:SS NL
 
-[At most once.]
+\[At most once.\]
 
 Indicates that a relay has reached an "overloaded state" which can be
 one or many of the following load metrics:
@@ -286,13 +286,13 @@ The signature is encoded in Base64, with terminating =s removed.
 The signing key in the identity-ed25519 certificate MUST
 be the one used to sign the document.
 
-[Before Tor 0.4.5.1-alpha, this field was optional whenever
-identity-ed25519 was absent.]
+\[Before Tor 0.4.5.1-alpha, this field was optional whenever
+identity-ed25519 was absent.\]
 
 "router-signature" NL Signature NL
 
-[At end, exactly once]
-[No extra arguments]
+\[At end, exactly once\]
+\[No extra arguments\]
 
 The "SIGNATURE" object contains a signature of the PKCS1-padded
 hash of the entire server descriptor, taken from the beginning of the
@@ -302,14 +302,14 @@ with the router's identity key.
 
 "contact" info NL
 
-[At most once]
+\[At most once\]
 
 Describes a way to contact the relay's administrator, preferably
 including an email address and a PGP key fingerprint.
 
 "bridge-distribution-request" SP Method NL
 
-[At most once, bridges only.]
+\[At most once, bridges only.\]
 
 The "Method" describes how a Bridge address is distributed by
 BridgeDB. Recognized methods are: "none", "any", "https", "email",
@@ -338,12 +338,12 @@ BridgeDB SHOULD treat unrecognized Method values as if they were
 
 (Default: "any")
 
-[This line was introduced in 0.3.2.3-alpha, with a minimal backport
-to 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, and later.]
+\[This line was introduced in 0.3.2.3-alpha, with a minimal backport
+to 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, and later.\]
 
 "family" names NL
 
-[At most once]
+\[At most once\]
 
 'Names' is a space-separated list of relay nicknames or
 hexdigests. If two ORs list one another in their "family" entries,
@@ -366,7 +366,7 @@ appeared in extra-info descriptors since 0.2.0.x.)
 
 "eventdns" bool NL
 
-[At most once]
+\[At most once\]
 
 Declare whether this version of Tor is using the newer enhanced
 dns logic.  Versions of Tor with this field set to false SHOULD NOT
@@ -379,17 +379,17 @@ be used for reverse hostname lookups.
    "caches-extra-info" NL
 ```
 
-[At most once.]
-[No extra arguments]
+\[At most once.\]
+\[No extra arguments\]
 
 Present only if this router is a directory cache that provides
 extra-info documents.
 
-[Versions before 0.2.0.1-alpha don't recognize this]
+\[Versions before 0.2.0.1-alpha don't recognize this\]
 
-"extra-info-digest" SP sha1-digest [SP sha256-digest] NL
+"extra-info-digest" SP sha1-digest \[SP sha256-digest\] NL
 
-[At most once]
+\[At most once\]
 
 "sha1-digest" is a hex-encoded SHA1 digest (using upper-case characters)
 of the router's extra-info document, as signed in the router's
@@ -405,12 +405,12 @@ to roll out an incremental fix for, not a design choice. Future digest
 algorithms specified should not include the signature in the data used
 to compute the digest.
 
-[Versions before 0.2.7.2-alpha did not include a SHA256 digest.]
-[Versions before 0.2.0.1-alpha don't recognize this field at all.]
+\[Versions before 0.2.7.2-alpha did not include a SHA256 digest.\]
+\[Versions before 0.2.0.1-alpha don't recognize this field at all.\]
 
 "hidden-service-dir" NL
 
-[At most once.]
+\[At most once.\]
 
 Present only if this router stores and serves hidden service
 descriptors. This router supports the descriptor versions declared
@@ -431,8 +431,8 @@ parse this line.
 
 "allow-single-hop-exits" NL
 
-[At most once.]
-[No extra arguments]
+\[At most once.\]
+\[No extra arguments\]
 
 Present only if the router allows single-hop circuits to make exit
 connections.  Most Tor relays do not support this: this is
@@ -441,7 +441,7 @@ access and such. This is obsolete in tor version >= 0.3.1.0-alpha.
 
 "or-address" SP ADDRESS ":" PORT NL
 
-[Any number]
+\[Any number\]
 
 ADDRESS = IP6ADDR | IP4ADDR
 IPV6ADDR = an ipv6 address, surrounded by square brackets.
@@ -465,8 +465,8 @@ Tor 0.2.3.x only the first address/port pair is advertised and used.
 
 "tunnelled-dir-server" NL
 
-[At most once.]
-[No extra arguments]
+\[At most once.\]
+\[No extra arguments\]
 
 ```text
        Present if the router accepts "tunneled" directory requests using a
@@ -505,4 +505,4 @@ larger than 63.
 
 This field was first added in Tor 0.2.9.x.
 
-[Before Tor 0.4.5.1-alpha, this field was optional.]
+\[Before Tor 0.4.5.1-alpha, this field was optional.\]
diff --git a/spec/dir-spec/serving-bandwidth-list-files.md b/spec/dir-spec/serving-bandwidth-list-files.md
index 2dd5ff4..6b0296b 100644
--- a/spec/dir-spec/serving-bandwidth-list-files.md
+++ b/spec/dir-spec/serving-bandwidth-list-files.md
@@ -43,8 +43,8 @@ they are not currently trying to download.
 Authorities identify them by hash in vote (if publication date is more
 recent than the descriptor we currently have).
 
-[XXXX need a way to fetch descriptors ahead of the vote?  v2 status docs can
-do that for now.]
+\[XXXX need a way to fetch descriptors ahead of the vote?  v2 status docs can
+do that for now.\]
 
 If so, the directory authority launches requests to the authorities for these
 descriptors, such that each authority is only asked for descriptors listed
@@ -455,7 +455,7 @@ Port lists are sorted in ascending order.
 The maximum allowed length of a policy summary (including the "accept "
 or "reject ") is 1000 characters.  If a summary exceeds that length we
 use an accept-style summary and list as much of the port list as is
-possible within these 1000 bytes.  [XXXX be more specific.]
+possible within these 1000 bytes.  \[XXXX be more specific.\]
 
 <a id="dir-spec.txt-3.8.3"></a>
 
@@ -526,7 +526,7 @@ Wed == 1/3.
 Let R denote the more scarce class (Rare) between Guard vs Exit.
 Let S denote the less scarce class.
 
-Subcase a: R+D < S
+Subcase a: R+D \< S
 
 In this subcase, we simply devote all of D bandwidth to the
 scarce class.
@@ -544,15 +544,15 @@ scarce class.
     Subcase b: R+D >= S
 ```
 
-In this case, if M <= T/3, we have enough bandwidth to try to achieve
+In this case, if M \<= T/3, we have enough bandwidth to try to achieve
 a balancing condition.
 
 Add constraints Wgg = weight_scale, Wmd == Wgd to maximize bandwidth in
 the guard position while still allowing exits to be used as middle nodes:
 
-Wee = (weight_scale*(E - G + M))/E
-Wed = (weight_scale*(D - 2*E + 4*G - 2*M))/(3*D)
-Wme = (weight_scale*(G-M))/E
+Wee = (weight_scale\*(E - G + M))/E
+Wed = (weight_scale\*(D - 2*E + 4*G - 2*M))/(3*D)
+Wme = (weight_scale\*(G-M))/E
 Wmg = 0
 Wgg = weight_scale
 Wmd = (weight_scale - Wed)/2
@@ -680,7 +680,7 @@ All consensus flavors have in common that their first line is
 "network-status-version" where version is 3 or higher, and the flavor
 is a string consisting of alphanumeric characters and dashes:
 
-"network-status-version" SP version [SP flavor] NL
+"network-status-version" SP version \[SP flavor\] NL
 
 <a id="dir-spec.txt-3.9.1"></a>
 
@@ -709,7 +709,7 @@ the exceptions as follows:
 
 "network-status-version" SP version SP "microdesc" NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 The flavor name of a microdescriptor consensus is "microdesc".
 
@@ -736,7 +736,7 @@ later.)
 
 "p" ... NL
 
-[At most once]
+\[At most once\]
 
 Not currently generated.
 
@@ -745,7 +745,7 @@ therefore omitted in the microdescriptor consensus.
 
 "m" SP digest NL
 
-[Exactly once.*]
+\[Exactly once.\*\]
 
 "digest" is the base64 of the SHA256 hash of the router's
 microdescriptor with trailing =s omitted.  For a given router
@@ -758,8 +758,8 @@ consensus should contain whichever microdescriptor digest is
 most common.  If there is no winner, we break ties in the favor
 of the lexically earliest.
 
-[*Before consensus method 13, this field was sometimes erroneously
-omitted.]
+\[\*Before consensus method 13, this field was sometimes erroneously
+omitted.\]
 
 Additionally, a microdescriptor consensus SHOULD use the sha256 digest
 algorithm for its signatures.
@@ -774,7 +774,7 @@ request to the URL:
 
 `http://<hostname>/tor/post/consensus-signature`
 
-[XXX Note why we support push-and-then-pull.]
+\[XXX Note why we support push-and-then-pull.\]
 
 All of the detached signatures it knows for consensus status should be
 available at:
@@ -790,7 +790,7 @@ follows:
 
 "consensus-digest" SP Digest NL
 
-[At start, at most once.]
+\[At start, at most once.\]
 
 The digest of the consensus being signed.
 
@@ -798,11 +798,11 @@ The digest of the consensus being signed.
 "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL
 "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL
 
-[As in the consensus]
+\[As in the consensus\]
 
 "additional-digest" SP flavor SP algname SP digest NL
 
-[Any number.]
+\[Any number.\]
 
 For each supported consensus flavor, every directory authority
 adds one or more "additional-digest" lines.  "flavor" is the name
@@ -834,13 +834,13 @@ the OAEP+-padded SHA256 digest of the item to be signed.  When
 checking signatures, the signature MUST be treated as valid if the
 signature material begins with SHA256(document), so that other
 data can get added later.
-[To be honest, I didn't fully understand the previous paragraph
-and only copied it from the proposals.  Review carefully. -KL]
+\[To be honest, I didn't fully understand the previous paragraph
+and only copied it from the proposals.  Review carefully. -KL\]
 
 "directory-signature"
 
-[As in the consensus; the signature object is the same as in the
-consensus document.]
+\[As in the consensus; the signature object is the same as in the
+consensus document.\]
 
 <a id="dir-spec.txt-3.11"></a>
 
diff --git a/spec/dir-spec/vote-consensus-status-document-formats.md b/spec/dir-spec/vote-consensus-status-document-formats.md
index 379cd8f..6fe5637 100644
--- a/spec/dir-spec/vote-consensus-status-document-formats.md
+++ b/spec/dir-spec/vote-consensus-status-document-formats.md
@@ -23,21 +23,21 @@ order given here:
 
 "network-status-version" SP version NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 A document format version.  For this specification, the version is
 "3".
 
 "vote-status" SP type NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The status MUST be "vote" or "consensus", depending on the type of
 the document.
 
 "consensus-methods" SP IntegerList NL
 
-[At most once for votes; does not occur in consensuses.]
+\[At most once for votes; does not occur in consensuses.\]
 
 A space-separated list of supported methods for generating
 consensuses from votes.  See section 3.8.1 for details.  Absence of
@@ -45,8 +45,8 @@ the line means that only method "1" is supported.
 
 "consensus-method" SP Integer NL
 
-[At most once for consensuses; does not occur in votes.]
-[No extra arguments]
+\[At most once for consensuses; does not occur in votes.\]
+\[No extra arguments\]
 
 See section 3.8.1 for details.
 
@@ -55,13 +55,13 @@ later.)
 
 "published" SP YYYY-MM-DD SP HH:MM:SS NL
 
-[Exactly once for votes; does not occur in consensuses.]
+\[Exactly once for votes; does not occur in consensuses.\]
 
 The publication time for this status document (if a vote).
 
 "valid-after" SP YYYY-MM-DD SP HH:MM:SS NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The start of the Interval for this vote.  Before this time, the
 consensus document produced from this vote is not officially in
@@ -75,7 +75,7 @@ See section 1.4 for voting timeline information.
 
 "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The time at which the next consensus should be produced; before this
 time, there is no point in downloading another consensus, since there
@@ -83,7 +83,7 @@ won't be a new one.  See section 1.4 for voting timeline information.
 
 "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 The end of the Interval for this vote.  After this time, all
 clients should try to find a more recent consensus. See section 1.4
@@ -95,7 +95,7 @@ downloaded.
 
 "voting-delay" SP VoteSeconds SP DistSeconds NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 VoteSeconds is the number of seconds that we will allow to collect
 votes from all authorities; DistSeconds is the number of seconds
@@ -104,7 +104,7 @@ section 1.4 for voting timeline information.
 
 "client-versions" SP VersionList NL
 
-[At most once.]
+\[At most once.\]
 
 A comma-separated list of recommended Tor versions for client
 usage, in ascending order. The versions are given as defined by
@@ -113,7 +113,7 @@ versions.
 
 "server-versions" SP VersionList NL
 
-[At most once.]
+\[At most once.\]
 
 A comma-separated list of recommended Tor versions for relay
 usage, in ascending order. The versions are given as defined by
@@ -122,7 +122,7 @@ versions.
 
 "package" SP PackageName SP Version SP URL SP DIGESTS NL
 
-[Any number of times.]
+\[Any number of times.\]
 
 For this element:
 
@@ -150,7 +150,7 @@ did not include this; method 34 removed it.
 
 "known-flags" SP FlagList NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 A space-separated list of all of the flags that this document
 might contain.  A flag is "known" either because the authority
@@ -160,7 +160,7 @@ opinion to have been formed about their status.
 
 "flag-thresholds" SP Thresholds NL
 
-[At most once for votes; does not occur in consensuses.]
+\[At most once for votes; does not occur in consensuses.\]
 
 ```text
          A space-separated list of the internal performance thresholds
@@ -209,7 +209,7 @@ opinion to have been formed about their status.
 "required-client-protocols" SP Entries NL
 "required-relay-protocols" SP Entries NL
 
-[At most once for each.]
+\[At most once for each.\]
 
 The "proto" element as specified in section 2.1.1.
 
@@ -225,9 +225,9 @@ the Tor code.
 The tor-spec.txt section 9 details how a relay and a client should
 behave when they encounter these lines in the consensus.
 
-"params" SP [Parameters] NL
+"params" SP \[Parameters\] NL
 
-[At most once]
+\[At most once\]
 
 Parameter ::= Keyword '=' Int32
 Int32 ::= A decimal integer between -2147483648 and 2147483647.
@@ -244,7 +244,7 @@ See param-spec.txt for a list of parameters and their meanings.
 
 "shared-rand-previous-value" SP NumReveals SP Value NL
 
-[At most once]
+\[At most once\]
 
 NumReveals ::= An integer greater or equal to 0.
 Value ::= Base64-encoded-data
@@ -254,8 +254,8 @@ shared randomness protocol run. For example, if this document was
 created on the 5th of November, this field carries the shared random
 value generated during the protocol run of the 3rd of November.
 
-See section [SRCALC] of srv-spec.txt for instructions on how to compute
-this value, and see section [CONS] for why we include old shared random
+See section \[SRCALC\] of srv-spec.txt for instructions on how to compute
+this value, and see section \[CONS\] for why we include old shared random
 values in votes and consensus.
 
 Value is the actual shared random value encoded in base64.  It will
@@ -264,7 +264,7 @@ to generate this SRV.
 
 "shared-rand-current-value" SP NumReveals SP Value NL
 
-[At most once]
+\[At most once\]
 
 NumReveals ::= An integer greater or equal to 0.
 Value ::= Base64-encoded-data
@@ -274,7 +274,7 @@ randomness protocol run. For example, if this document was created on
 the 5th of November, this field carries the shared random value
 generated during the protocol run of the 4th of November
 
-See section [SRCALC] of srv-spec.txt for instructions on how to compute
+See section \[SRCALC\] of srv-spec.txt for instructions on how to compute
 this value given the active commits.
 
 Value is the actual shared random value encoded in base64.  It will
@@ -283,7 +283,7 @@ generate this SRV.
 
 "bandwidth-file-headers" SP KeyValues NL
 
-[At most once for votes; does not occur in consensuses.]
+\[At most once for votes; does not occur in consensuses.\]
 
 KeyValues ::= "" | KeyValue | KeyValues SP KeyValue
 KeyValue ::= Keyword '=' Value
@@ -301,9 +301,9 @@ fails, this line SHOULD appear in its vote, but without any headers.
 
 First-appeared: Tor 0.3.5.1-alpha.
 
-"bandwidth-file-digest" 1*(SP algorithm "=" digest) NL
+"bandwidth-file-digest" 1\*(SP algorithm "=" digest) NL
 
-[At most once for votes; does not occur in consensuses.]
+\[At most once for votes; does not occur in consensuses.\]
 
 A digest of the bandwidth file used to generate this vote.
 "algorithm" is the name of the hash algorithm producing "digest",
@@ -340,7 +340,7 @@ connections.
 
 "contact" SP string NL
 
-[Exactly once]
+\[Exactly once\]
 
 An arbitrary string describing how to contact the directory
 server's administrator.  Administrators should include at least an
@@ -348,7 +348,7 @@ email address and a PGP fingerprint.
 
 "legacy-dir-key" SP FINGERPRINT NL
 
-[At most once]
+\[At most once\]
 
 Lists a fingerprint for an obsolete _identity_ key still used
 by this authority to keep older clients working.  This option
@@ -360,24 +360,24 @@ Debian OpenSSL RNG bug of May 2008.)
 
 "shared-rand-participate" NL
 
-[At most once]
+\[At most once\]
 
 Denotes that the directory authority supports and can participate in the
 shared random protocol.
 
-"shared-rand-commit" SP Version SP AlgName SP Identity SP Commit [SP Reveal] NL
+"shared-rand-commit" SP Version SP AlgName SP Identity SP Commit \[SP Reveal\] NL
 
-[Any number of times]
+\[Any number of times\]
 
 Version ::= An integer greater or equal to 0.
-AlgName ::= 1*(ALPHA / DIGIT / "_" / "-")
-Identity ::= 40* HEXDIG
+AlgName ::= 1\*(ALPHA / DIGIT / "\_" / "-")
+Identity ::= 40\* HEXDIG
 Commit ::= Base64-encoded-data
 Reveal ::= Base64-encoded-data
 
 Denotes a directory authority commit for the shared randomness
 protocol, containing the commitment value and potentially also the
-reveal value. See sections [COMMITREVEAL] and [VALIDATEVALUES] of
+reveal value. See sections \[COMMITREVEAL\] and \[VALIDATEVALUES\] of
 srv-spec.txt on how to generate and validate these values.
 
 Version is the current shared randomness protocol version. AlgName is
@@ -391,13 +391,13 @@ receiver MUST only consider the first commit listed.
 
 "shared-rand-previous-value" SP NumReveals SP Value NL
 
-[At most once]
+\[At most once\]
 
 See shared-rand-previous-value description above.
 
 "shared-rand-current-value" SP NumReveals SP Value NL
 
-[At most once]
+\[At most once\]
 
 See shared-rand-current-value description above.
 
@@ -461,7 +461,7 @@ in non-vote documents.
 
 "a" SP address ":" port NL
 
-[Any number]
+\[Any number\]
 
 The first advertised IPv6 address for the OR, if it is reachable.
 
@@ -477,7 +477,7 @@ consensus-method 14 or later.)
 
 "s" SP Flags NL
 
-[Exactly once.]
+\[Exactly once.\]
 
 A series of space-separated status flags, in lexical order (as ASCII
 byte strings).  Currently documented flags are:
@@ -535,7 +535,7 @@ long.
 
 "pr" SP Entries NL
 
-[At most once.]
+\[At most once.\]
 
 The "proto" family element as specified in section 2.1.1.
 
@@ -546,9 +546,9 @@ in section D. They are included in the consensus using the same rules
 as currently used for "v" lines, if a sufficiently late consensus
 method is in use.
 
-"w" SP "Bandwidth=" INT [SP "Measured=" INT] [SP "Unmeasured=1"] NL
+"w" SP "Bandwidth=" INT \[SP "Measured=" INT\] \[SP "Unmeasured=1"\] NL
 
-[At most once.]
+\[At most once.\]
 
 An estimate of the bandwidth of this relay, in an arbitrary
 unit (currently kilobytes per second).  Used to weight router
@@ -572,7 +572,7 @@ Clients MUST ignore keywords they do not recognize.
 
 "p" SP ("accept" / "reject") SP PortList NL
 
-[At most once.]
+\[At most once.\]
 
 PortList = PortOrRange
 PortList = PortList "," PortOrRange
@@ -582,9 +582,9 @@ A list of those ports that this router supports (if 'accept')
 or does not support (if 'reject') for exit to "most
 addresses".
 
-"m" SP methods 1*(SP algorithm "=" digest) NL
+"m" SP methods 1\*(SP algorithm "=" digest) NL
 
-[Any number, only in votes.]
+\[Any number, only in votes.\]
 
 Microdescriptor hashes for all consensus methods that an authority
 supports and that use the same microdescriptor format.  "methods"
@@ -606,7 +606,7 @@ the router's microdescriptor with trailing =s omitted.
 ```
 
 KeyValue ::= Keyword '=' Number
-Number ::= [0-9]+("."[0-9]+)?
+Number ::= \[0-9\]+("."\[0-9\]+)?
 KeyValues ::= KeyValue | KeyValues SP KeyValue
 
 Line containing various statistics that an authority has computed for
@@ -625,7 +625,7 @@ The footer section is delineated in all votes and consensuses supporting
 consensus method 9 and above with the following:
 
 "directory-footer" NL
-[No extra arguments]
+\[No extra arguments\]
 
 It contains two subsections, a bandwidths-weights line and a
 directory-signature. (Prior to consensus method 9, footers only contained
@@ -635,7 +635,7 @@ bandwidth-weights.)
 The bandwidths-weights line appears At Most Once for a consensus. It does
 not appear in votes.
 
-"bandwidth-weights" [SP Weights] NL
+"bandwidth-weights" \[SP Weights\] NL
 
 Weight ::= Keyword '=' Int32
 Int32 ::= A decimal integer between -2147483648 and 2147483647.
diff --git a/spec/dos-spec.md b/spec/dos-spec.md
index d3cba22..d0b8e89 100644
--- a/spec/dos-spec.md
+++ b/spec/dos-spec.md
@@ -41,13 +41,13 @@ or derived from a fraction of the total amount of system RAM.
 As of Tor 0.4.7.x, the MaxMemInQueues mechanism tracks the following
 kinds of allocation:
 
-* Cells queued on circuits.
-* Per-connection read or write buffers.
-* On-the-fly compression or decompression state.
-* Half-open stream records.
-* Cached onion service descriptors (hsdir only).
-* Cached DNS resolves (relay only).
-* GEOIP-based usage activity statistics.
+- Cells queued on circuits.
+- Per-connection read or write buffers.
+- On-the-fly compression or decompression state.
+- Half-open stream records.
+- Cached onion service descriptors (hsdir only).
+- Cached DNS resolves (relay only).
+- GEOIP-based usage activity statistics.
 
 Note that directory caches aren't counted, since those are stored on
 disk and accessed via mmap.
diff --git a/spec/ext-orport-spec.md b/spec/ext-orport-spec.md
index 75e2ec2..9d84f92 100644
--- a/spec/ext-orport-spec.md
+++ b/spec/ext-orport-spec.md
@@ -55,7 +55,7 @@ connects to an Extended ORPort, the server sends:
 The client reads the list of supported authentication schemes,
 chooses one, and sends it back:
 
-AuthType                                    [1 octet]
+AuthType                                    \[1 octet\]
 
 Where,
 
@@ -117,11 +117,11 @@ authentication protocol.
 
 A client that performs the SAFE_COOKIE handshake begins by sending:
 
-ClientNonce                                 [32 octets]
+ClientNonce                                 \[32 octets\]
 
 Where,
 
-+ ClientNonce is 32 octets of random data.
+- ClientNonce is 32 octets of random data.
 
 Then, the server replies with:
 
@@ -144,7 +144,7 @@ terminate the connection.
 
 Otherwise the client replies with:
 
-ClientHash                                  [32 octets]
+ClientHash                                  \[32 octets\]
 
 ```text
   Where,
@@ -158,7 +158,7 @@ validates it against the ClientHash provided by the client.
 
 Finally, the server replies with:
 
-Status                                      [1 octet]
+Status                                      \[1 octet\]
 
 ```text
   Where,
diff --git a/spec/gettor-spec.md b/spec/gettor-spec.md
index 6895a1f..9a5caea 100644
--- a/spec/gettor-spec.md
+++ b/spec/gettor-spec.md
@@ -53,7 +53,7 @@ per transport basis.
 
 ## Reference implementation
 
-We have implemented[0] a compliant GetTor that supports SMTP as a transport.
+We have implemented\[0\] a compliant GetTor that supports SMTP as a transport.
 
 <a id="gettor-spec.txt-3"></a>
 
@@ -86,7 +86,7 @@ without any long term storage excepting a cache of files that it will send to
 any user who requests it.
 
 GetTor may optionally collect anonymized usage statistics to better understand
-how GetTor[1] is in use. This must not include any personally identifying
+how GetTor\[1\] is in use. This must not include any personally identifying
 information about any of the requester beyond language selection.
 
 <a id="gettor-spec.txt-4"></a>
@@ -103,5 +103,5 @@ useful system as is XMPP/Jabber with the newest OTR file sharing transport.
 It is suggested that any compliant GetTor instance should be written in a so
 called "safe" language such as Python.
 
-[0] <https://gitweb.torproject.org/gettor.git>
-[1] <https://metrics.torproject.org/packages.html>
+\[0\] <https://gitweb.torproject.org/gettor.git>
+\[1\] <https://metrics.torproject.org/packages.html>
diff --git a/spec/glossary.md b/spec/glossary.md
index 8ea5363..8f62ff7 100644
--- a/spec/glossary.md
+++ b/spec/glossary.md
@@ -57,7 +57,7 @@ DirPort - Directory Port
 
 ## Relays, aka OR (onion router)
 
-[Style guide: prefer the term "Relay"]
+\[Style guide: prefer the term "Relay"\]
 
 <a id="glossary.txt-2.1.1"></a>
 
@@ -93,7 +93,7 @@ rendezvous point.
 
 ## Client, aka OP (onion proxy)
 
-[Style: the "OP" and "onion proxy" terms are deprecated.]
+\[Style: the "OP" and "onion proxy" terms are deprecated.\]
 
 <a id="glossary.txt-2.3"></a>
 
diff --git a/spec/guard-spec/algorithm.md b/spec/guard-spec/algorithm.md
index 5e30782..b18803b 100644
--- a/spec/guard-spec/algorithm.md
+++ b/spec/guard-spec/algorithm.md
@@ -4,7 +4,7 @@
 
 <a id="guard-spec.txt-4.0"></a>
 
-## The guards listed in the current consensus. [Section:GUARDS]
+## The guards listed in the current consensus. \[Section:GUARDS\]
 
 By {set:GUARDS} we mean the set of all guards in the current
 consensus that are usable for all circuits and directory
@@ -17,7 +17,7 @@ from any guard, so that all guards are usable for all circuits.
 
 <a id="guard-spec.txt-4.1"></a>
 
-## The Sampled Guard Set. [Section:SAMPLED]
+## The Sampled Guard Set. \[Section:SAMPLED\]
 
 We maintain a set, {set:SAMPLED_GUARDS}, that persists across
 invocations of Tor. It is a subset of the nodes ordered by a sample idx that
@@ -130,7 +130,7 @@ adversary node.
 
 <a id="guard-spec.txt-4.2"></a>
 
-## The Usable Sample [Section:FILTERED]
+## The Usable Sample \[Section:FILTERED\]
 
 We maintain another set, {set:FILTERED_GUARDS}, that does not
 persist. It is derived from:
@@ -185,9 +185,9 @@ filtering restrictions that we had in the past.
 
 <a id="guard-spec.txt-4.3"></a>
 
-## The confirmed-guard list. [Section:CONFIRMED]
+## The confirmed-guard list. \[Section:CONFIRMED\]
 
-[formerly USED_GUARDS]
+\[formerly USED_GUARDS\]
 
 We maintain a persistent ordered list, {list:CONFIRMED_GUARDS}.
 It contains guards that we have used before, in our preference
@@ -247,7 +247,7 @@ traffic.
 
 <a id="guard-spec.txt-4.4"></a>
 
-## The Primary guards [Section:PRIMARY]
+## The Primary guards \[Section:PRIMARY\]
 
 We keep a run-time non-persistent ordered list of
 {list:PRIMARY_GUARDS}.  It is a subset of {FILTERED_GUARDS}.  It
@@ -280,7 +280,7 @@ usable after all.
 
 <a id="guard-spec.txt-4.5"></a>
 
-## Retrying guards. [Section:RETRYING]
+## Retrying guards. \[Section:RETRYING\]
 
 (We run this process as frequently as needed. It can be done once
 a second, or just-in-time.)
@@ -303,7 +303,7 @@ now from the fact that it was unreachable a few minutes ago.
 
 <a id="guard-spec.txt-4.6"></a>
 
-## Selecting guards for circuits. [Section:SELECTING]
+## Selecting guards for circuits. \[Section:SELECTING\]
 
 Every origin circuit is now in one of these states:
 
@@ -385,7 +385,7 @@ In some cases (for example, when we need a certain directory feature,
 or when we need to avoid using a certain exit as a guard), we need to
 restrict the guards that we use for a single circuit. When this happens, we
 remember the restrictions that applied when choosing the guard for
-that circuit, since we will need them later (see [UPDATE_WAITING].).
+that circuit, since we will need them later (see \[UPDATE_WAITING\].).
 
 **Rationale**
 
@@ -406,11 +406,11 @@ circuit through each, to give it a chance to succeed or fail.  If
 ever such a circuit succeeds, we don't use it until we're pretty
 sure that it's the best guard we're getting. (see below).
 
-[XXX timeout.]
+\[XXX timeout.\]
 
 <a id="guard-spec.txt-4.7"></a>
 
-## When a circuit fails. [Section:ON_FAIL]
+## When a circuit fails. \[Section:ON_FAIL\]
 
 When a circuit fails in a way that makes us conclude that a guard
 is not reachable, we take the following steps:
@@ -427,17 +427,17 @@ is not reachable, we take the following steps:
         below.)
 ```
 
-[Note: the existing Tor logic will cause us to create more
+\[Note: the existing Tor logic will cause us to create more
 circuits in response to some of these steps; and also see
-[ON_CONSENSUS].]
+\[ON_CONSENSUS\].\]
 
 **Rationale**
 
-See [SELECTING] above for rationale.
+See \[SELECTING\] above for rationale.
 
 <a id="guard-spec.txt-4.8"></a>
 
-## When a circuit succeeds [Section:ON_SUCCESS]
+## When a circuit succeeds \[Section:ON_SUCCESS\]
 
 When a circuit succeeds in a way that makes us conclude that a
 guard _was_ reachable, we take these steps:
@@ -466,17 +466,17 @@ guard _was_ reachable, we take these steps:
              [UPDATE_WAITING] below)
 ```
 
-[Note: the existing Tor logic will cause us to create more
+\[Note: the existing Tor logic will cause us to create more
 circuits in response to some of these steps; and see
-[ON_CONSENSUS].]
+\[ON_CONSENSUS\].\]
 
 **Rationale**
 
-See [SELECTING] above for rationale.
+See \[SELECTING\] above for rationale.
 
 <a id="guard-spec.txt-4.9"></a>
 
-## Updating the list of waiting circuits [Section:UPDATE_WAITING]
+## Updating the list of waiting circuits \[Section:UPDATE_WAITING\]
 
 We run this procedure whenever it's possible that a
 `<waiting_for_better_guard>` circuit might be ready to be called
@@ -516,9 +516,9 @@ them after all if the `<complete>` circuit goes down before
 
 <a id="guard-spec.txt-4.9.1"></a>
 
-### Without a list of waiting circuits [Section:NO_CIRCLIST]
+### Without a list of waiting circuits \[Section:NO_CIRCLIST\]
 
-As an alternative to the section [SECTION:UPDATE_WAITING] above,
+As an alternative to the section \[SECTION:UPDATE_WAITING\] above,
 this section presents a new way to maintain guard status
 independently of tracking individual circuit status.  This
 formulation gives a result equivalent or similar to the approach
@@ -540,7 +540,7 @@ these rules:
 
 1. Primary guards are always usable.
 
-2. Non-primary guards are usable _for a given circuit_ if every
+1. Non-primary guards are usable _for a given circuit_ if every
    guard earlier in the preference list is either unsuitable for
    that circuit (e.g. because of family restrictions), or marked as
    Unreachable, or has been pending for at least
@@ -553,20 +553,20 @@ these rules:
    Non-primary guards are unusable if they have not become
    usable after `{NONPRIMARY_GUARD_IDLE_TIMEOUT}` seconds.
 
-3. If a circuit's guard is not usable or unusable immediately, the
+1. If a circuit's guard is not usable or unusable immediately, the
    circuit is not discarded; instead, it is kept (but not used) until the
    guard becomes usable or unusable.
 
 <a id="guard-spec.txt-4.10"></a>
 
-## Whenever we get a new consensus. [Section:ON_CONSENSUS]
+## Whenever we get a new consensus. \[Section:ON_CONSENSUS\]
 
 We update {GUARDS}.
 
 For every guard in {SAMPLED_GUARDS}, we update {IS_LISTED} and
 {FIRST_UNLISTED_AT}.
 
-[**] We remove entries from {SAMPLED_GUARDS} if appropriate,
+\[\*\*\] We remove entries from {SAMPLED_GUARDS} if appropriate,
 according to the sampled-guards expiration rules.  If they were
 in {CONFIRMED_GUARDS}, we also remove them from
 {CONFIRMED_GUARDS}.
@@ -576,7 +576,7 @@ it, including {USABLE_FILTERED_GUARDS}, and {PRIMARY_GUARDS}.
 
 (Whenever one of the configuration options that affects the
 filter is updated, we repeat the process above, starting at the
-[**] line.)
+\[\*\*\] line.)
 
 ```text
 4.11. Deciding whether to generate a new circuit.
diff --git a/spec/guard-spec/appendices.md b/spec/guard-spec/appendices.md
index 612ff4c..34368ad 100644
--- a/spec/guard-spec/appendices.md
+++ b/spec/guard-spec/appendices.md
@@ -11,7 +11,7 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548.
 
 <a id="guard-spec.txt-A.1"></a>
 
-## Parameters with suggested values. [Section:PARAM_VALS]
+## Parameters with suggested values. \[Section:PARAM_VALS\]
 
 (All suggested values chosen arbitrarily)
 
@@ -80,7 +80,7 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548.
 
 <a id="guard-spec.txt-A.2"></a>
 
-## Random values [Section:RANDOM]
+## Random values \[Section:RANDOM\]
 
 Frequently, we want to randomize the expiration time of something
 so that it's not easy for an observer to match it to its start
@@ -92,7 +92,7 @@ the past, chosen uniformly at random.
 
 <a id="guard-spec.txt-A.3"></a>
 
-## Why not a sliding scale of primaryness? [Section:CVP]
+## Why not a sliding scale of primaryness? \[Section:CVP\]
 
 At one meeting, I floated the idea of having "primaryness" be a
 continuous variable rather than a boolean.
@@ -102,7 +102,7 @@ how it might work.
 
 To begin with: being "primary" gives it a few different traits:
 
-1) We retry primary guards more frequently. [Section:RETRYING]
+1. We retry primary guards more frequently. \[Section:RETRYING\]
 
 ```text
       2) We don't even _try_ building circuits through
diff --git a/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md b/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md
index bbebb04..b31609f 100644
--- a/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md
+++ b/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md
@@ -6,7 +6,7 @@ A circuit in Tor is a path through the network connecting a client to
 its destination. At a high-level, a three-hop exit circuit will look
 like this:
 
-Client <-> Entry Guard <-> Middle Node <-> Exit Node <-> Destination
+Client \<-> Entry Guard \<-> Middle Node \<-> Exit Node \<-> Destination
 
 Entry guards are the only nodes which a client will connect to
 directly. Exit relays are the nodes by which traffic exits the
diff --git a/spec/guard-spec/still-non-addressed-issues-sectiontodo.md b/spec/guard-spec/still-non-addressed-issues-sectiontodo.md
index 89e60ba..38b0be4 100644
--- a/spec/guard-spec/still-non-addressed-issues-sectiontodo.md
+++ b/spec/guard-spec/still-non-addressed-issues-sectiontodo.md
@@ -1,6 +1,6 @@
 <a id="guard-spec.txt-TODO"></a>
 
-# Still non-addressed issues [Section:TODO]
+# Still non-addressed issues \[Section:TODO\]
 
 Simulate to answer:  Will this work in a dystopic world?
 
diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md
index 575f248..a220507 100644
--- a/spec/padding-spec/circuit-level-padding.md
+++ b/spec/padding-spec/circuit-level-padding.md
@@ -3,13 +3,13 @@
 # Circuit-level padding
 
 The circuit padding system in Tor is an extension of the WTF-PAD
-event-driven state machine design[15]. At a high level, this design places
+event-driven state machine design\[15\]. At a high level, this design places
 one or more padding state machines at the client, and one or more padding
 state machines at a relay, on each circuit.
 
 State transition and histogram generation has been generalized to be fully
 programmable, and probability distribution support was added to support more
-compact representations like APE[16]. Additionally, packet count limits,
+compact representations like APE\[16\]. Additionally, packet count limits,
 rate limiting, and circuit application conditions have been added.
 
 At present, Tor uses this system to deploy two pairs of circuit padding
@@ -19,7 +19,7 @@ onion service circuits, up to the first 10 cells.
 This specification covers only the resulting behavior of these padding
 machines, and thus does not cover the state machine implementation details or
 operation. For full details on using the circuit padding system to develop
-future padding defenses, see the research developer documentation[17].
+future padding defenses, see the research developer documentation\[17\].
 
 <a id="padding-spec.txt-3.1"></a>
 
@@ -133,16 +133,16 @@ Note that inter-arrival timing is not obfuscated by this defense.
 
 Most general Tor circuits used to surf the web or download directory
 information start with the following 6-cell relay cell sequence (cells
-surrounded in [brackets] are outgoing, the others are incoming):
+surrounded in \[brackets\] are outgoing, the others are incoming):
 
-[EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED
+\[EXTEND2\] -> EXTENDED2 -> \[EXTEND2\] -> EXTENDED2 -> \[BEGIN\] -> CONNECTED
 
 When this is done, the client has established a 3-hop circuit and also opened
 a stream to the other end. Usually after this comes a series of DATA cell that
 either fetches pages, establishes an SSL connection or fetches directory
 information:
 
-[DATA] -> [DATA] -> DATA -> DATA...(inbound cells continue)
+\[DATA\] -> \[DATA\] -> DATA -> DATA...(inbound cells continue)
 
 The above stream of 10 relay cells defines the grand majority of general
 circuits that come out of Tor browser during our testing, and it's what we use
@@ -165,7 +165,7 @@ machine terminates at the second hop and does not get forwarded to the actual
 introduction point.
 
 From Section 3.3.1 above, most general circuits have the following initial
-relay cell sequence (outgoing cells marked in [brackets]):
+relay cell sequence (outgoing cells marked in \[brackets\]):
 
 ```text
   [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED
@@ -181,12 +181,12 @@ This means that up to the sixth cell (first line of each sequence above),
 both general and intro circuits have identical cell sequences. After that
 we want to mimic the second line sequence of
 
--> [DATA] -> [DATA] -> DATA -> DATA...(inbound data cells continue)
+-> \[DATA\] -> \[DATA\] -> DATA -> DATA...(inbound data cells continue)
 
 We achieve this by starting padding INTRODUCE1 has been sent. With padding
 negotiation cells, in the common case of the second line looks like:
 
--> [INTRO1] -> [PADDING_NEGOTIATE] -> PADDING_NEGOTIATED -> INTRO_ACK
+-> \[INTRO1\] -> \[PADDING_NEGOTIATE\] -> PADDING_NEGOTIATED -> INTRO_ACK
 
 Then, the middle node will send between INTRO_MACHINE_MINIMUM_PADDING (7) and
 INTRO_MACHINE_MAXIMUM_PADDING (10) cells, to match the "...(inbound data cells
@@ -218,7 +218,7 @@ circuits which usually look like this:
 This means that up to the sixth cell (the first line), both general and
 rend circuits have identical cell sequences.
 
-After that we want to mimic a [DATA] -> [DATA] -> DATA -> DATA sequence.
+After that we want to mimic a \[DATA\] -> \[DATA\] -> DATA -> DATA sequence.
 
 With padding negotiation right after the REND_ESTABLISHED, the sequence
 becomes:
@@ -243,7 +243,7 @@ will look alike.
 ### Circuit setup machine overhead
 
 For the intro circuit case, we see that the origin-side machine just sends a
-single [PADDING_NEGOTIATE] cell, whereas the origin-side machine sends a
+single \[PADDING_NEGOTIATE\] cell, whereas the origin-side machine sends a
 PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the
 average overhead of this machine is 11 padding cells per introduction circuit.
 
diff --git a/spec/padding-spec/connection-level-padding.md b/spec/padding-spec/connection-level-padding.md
index b0450d7..5c01f38 100644
--- a/spec/padding-spec/connection-level-padding.md
+++ b/spec/padding-spec/connection-level-padding.md
@@ -13,7 +13,7 @@ Such metadata retention is implemented by Internet routers in the form of
 Netflow, jFlow, Netstream, or IPFIX records.  These records are emitted by
 gateway routers in a raw form and then exported (often over plaintext) to a
 "collector" that either records them verbatim, or reduces their granularity
-further[1].
+further\[1\].
 
 Netflow records and the associated data collection and retention tools are
 very configurable, and have many modes of operation, especially when
@@ -147,7 +147,7 @@ bidirectional padding packet rate is now a third random variable:
 Z = min(Y,Y).
 
 The distribution of Z is slightly bell-shaped, but mostly flat around the
-mean. It also turns out that Exp[Z] ~= Exp[X]. Here's a table of average
+mean. It also turns out that Exp\[Z\] ~= Exp\[X\]. Here's a table of average
 values for each random variable:
 
 ```text
@@ -178,7 +178,7 @@ in each direction (309KB total).
 
 With 2.5M completely idle clients connected simultaneously, 52 bytes per
 second amounts to 130MB/second in each direction network-wide, which is
-roughly the current amount of Tor directory traffic[11]. Of course, our
+roughly the current amount of Tor directory traffic\[11\]. Of course, our
 2.5M daily users will neither be connected simultaneously, nor entirely
 idle, so we expect the actual overhead to be much lower than this.
 
@@ -192,7 +192,7 @@ clients to relays. This cell is used to instruct relays to cease sending
 padding.
 
 If the client has opted to use reduced padding, it continues to send
-padding cells sampled from the range [9000,14000] milliseconds (subject to
+padding cells sampled from the range \[9000,14000\] milliseconds (subject to
 consensus parameter alteration as per Section 2.6), still using the
 Y=max(X,X) distribution. Since the padding is now unidirectional, the
 expected frequency of padding cells is now governed by the Y distribution
diff --git a/spec/param-spec.md b/spec/param-spec.md
index 0d465e1..bd18c0c 100644
--- a/spec/param-spec.md
+++ b/spec/param-spec.md
@@ -6,17 +6,17 @@ line of a directory consensus.
 Table of Contents
 
 1. Network protocol parameters
-2. Performance-tuning parameters
-3. Voting-related parameters
-4. Circuit-build-timeout parameters
-5. Directory-related parameters
-6. Pathbias parameters
-7. Relay behavior
-8. V3 onion service parameters
-9. Denial-of-service parameters
-10. Padding-related parameters
-11. Guard-related parameters
-X. Obsolete parameters
+1. Performance-tuning parameters
+1. Voting-related parameters
+1. Circuit-build-timeout parameters
+1. Directory-related parameters
+1. Pathbias parameters
+1. Relay behavior
+1. V3 onion service parameters
+1. Denial-of-service parameters
+1. Padding-related parameters
+1. Guard-related parameters
+   X. Obsolete parameters
 
 <a id="param-spec.txt-1"></a>
 
@@ -295,7 +295,7 @@ allowed to open.  This concept comes from proposal #155.
 Min: 0. Max: 128. Default: 2.
 
 "hsdir_interval" -- The length of a time period, _in minutes_. See
-rend-spec-v3.txt section [TIME-PERIODS].
+rend-spec-v3.txt section \[TIME-PERIODS\].
 Min: 30. Max: 14400. Default: 1440.
 
 "hsdir_n_replicas" -- Number of HS descriptor replicas.
diff --git a/spec/path-spec/attaching-streams-to-circuits.md b/spec/path-spec/attaching-streams-to-circuits.md
index e03414e..585885b 100644
--- a/spec/path-spec/attaching-streams-to-circuits.md
+++ b/spec/path-spec/attaching-streams-to-circuits.md
@@ -6,7 +6,7 @@ When a circuit that might support a request is built, Tor tries to attach
 the request's stream to the circuit and sends a BEGIN, BEGIN_DIR,
 or RESOLVE relay
 cell as appropriate.  If the request completes unsuccessfully, Tor
-considers the reason given in the CLOSE relay cell. [XXX yes, and?]
+considers the reason given in the CLOSE relay cell. \[XXX yes, and?\]
 
 After a request has remained unattached for SocksTimeout (2 minutes
 by default), Tor abandons the attempt and signals an error to the
@@ -14,6 +14,6 @@ client as appropriate (e.g., by closing the SOCKS connection).
 
 XXX Timeouts and when Tor auto-retries.
 
-* What stream-end-reasons are appropriate for retrying.
+- What stream-end-reasons are appropriate for retrying.
 
 If no reply to BEGIN/RESOLVE, then the stream will timeout and fail.
diff --git a/spec/path-spec/general-operation.md b/spec/path-spec/general-operation.md
index e1632af..7127fee 100644
--- a/spec/path-spec/general-operation.md
+++ b/spec/path-spec/general-operation.md
@@ -23,7 +23,7 @@ as indicated above. When bootstrap completes, Tor will be ready to handle
 an application requesting an internal circuit to hidden services at
 ".onion" addresses.
 
-If a future consensus contains Exits, exit circuits may become available.]
+If a future consensus contains Exits, exit circuits may become available.\]
 
 When a client application creates a new stream (by opening a SOCKS
 connection or launching a resolve request), we attach it to an appropriate
diff --git a/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md b/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md
index 06f6914..939f3a2 100644
--- a/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md
+++ b/spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md
@@ -77,7 +77,7 @@ To avoid ln(1.0+epsilon) precision issues, use log laws to rewrite the
 estimator for 'alpha' as the sum of logs followed by subtraction, rather
 than multiplication and division:
 
-alpha = n/(Sum_n{ln(MAX(Xm, x_i))} - n*ln(Xm))
+alpha = n/(Sum_n{ln(MAX(Xm, x_i))} - n\*ln(Xm))
 
 In this, n is the total number of build times that have completed, x_i is
 the ith recorded build time, and Xm is the modes of x_i as above.
@@ -133,9 +133,9 @@ other lengths, the client multiples the timeout_ms and close_ms values
 by a scaling factor determined by the number of communication hops
 needed to build their circuits:
 
-timeout_ms[hops=n] = timeout_ms * Actions(N) / Actions(3)
+timeout_ms\[hops=n\] = timeout_ms * Actions(N) / Actions(3)
 
-close_ms[hops=n] = close_ms * Actions(N) / Actions(3)
+close_ms\[hops=n\] = close_ms * Actions(N) / Actions(3)
 
 where Actions(N) = N * (N + 1) / 2.
 
diff --git a/spec/path-spec/old-notes.md b/spec/path-spec/old-notes.md
index 34734fb..ce3ec44 100644
--- a/spec/path-spec/old-notes.md
+++ b/spec/path-spec/old-notes.md
@@ -26,15 +26,15 @@ How to deal with network down.
     circuit and beginning to use it immediately?)
 ```
 
-[Do we actually do any of the above?  If so, let's spec it.  If not, let's
-remove it. -NM]
+\[Do we actually do any of the above?  If so, let's spec it.  If not, let's
+remove it. -NM\]
 
 <a id="path-spec.txt-X.2"></a>
 
 ## A thing we could do to deal with reachability
 
 And as a bonus, it leads to an answer to Nick's attack ("If I pick
-my helper nodes all on 18.0.0.0:*, then I move, you'll know where I
+my helper nodes all on 18.0.0.0:\*, then I move, you'll know where I
 bootstrapped") -- the answer is to pick your original three helper nodes
 without regard for reachability. Then the above algorithm will add some
 more that are reachable for you, and if you move somewhere, it's more
@@ -59,5 +59,5 @@ our location (IP? subnet?) changes, we have two bad options.  We could
       nasty, since it would force us to record where we've been.
 ```
 
-[Do we do any of this now? If not, this should move into 099-misc or
-098-todo. -NM]
+\[Do we do any of this now? If not, this should move into 099-misc or
+098-todo. -NM\]
diff --git a/spec/pt-spec/architecture-overview.md b/spec/pt-spec/architecture-overview.md
index 64a3eca..ef4a6a4 100644
--- a/spec/pt-spec/architecture-overview.md
+++ b/spec/pt-spec/architecture-overview.md
@@ -15,7 +15,7 @@
 ```
 
 On the client's host, the PT Client software exposes a SOCKS proxy
-[RFC1928] to the client application, and obfuscates or otherwise
+\[RFC1928\] to the client application, and obfuscates or otherwise
 transforms traffic before forwarding it to the server's host.
 
 On the server's host, the PT Server software exposes a reverse proxy
@@ -24,7 +24,7 @@ obfuscation/transformation applied to traffic, before forwarding it
 to the actual server software.  An optional lightweight protocol
 exists to facilitate communicating connection meta-data that would
 otherwise be lost such as the source IP address and port
-[EXTORPORT].
+\[EXTORPORT\].
 
 All PT instances are configured by the respective parent process via
 a set of standardized environment variables (3.2) that are set at
diff --git a/spec/pt-spec/introduction.md b/spec/pt-spec/introduction.md
index 6db3ea5..796468e 100644
--- a/spec/pt-spec/introduction.md
+++ b/spec/pt-spec/introduction.md
@@ -24,4 +24,4 @@ Transports.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
-[RFC2119].
+\[RFC2119\].
diff --git a/spec/pt-spec/pluggable-transport-configuration-environment.md b/spec/pt-spec/pluggable-transport-configuration-environment.md
index 19bd351..79e9f67 100644
--- a/spec/pt-spec/pluggable-transport-configuration-environment.md
+++ b/spec/pt-spec/pluggable-transport-configuration-environment.md
@@ -6,7 +6,7 @@ All Pluggable Transport proxy instances are configured by their
 parent process at launch time via a set of well defined
 environment variables.
 
-The "TOR_PT_" prefix is used for namespacing reasons and does not
+The "TOR_PT\_" prefix is used for namespacing reasons and does not
 indicate any relations to Tor, except for the origins of this
 specification.
 
@@ -92,13 +92,13 @@ use.
 If this value is unset or empty, the PT proxy MUST use the default source
 address for outgoing connections.
 
-This setting MUST be ignored for connections to the loopback address ([::1]).
+This setting MUST be ignored for connections to the loopback address (\[::1\]).
 
 IPv6 addresses MUST always be wrapped in square brackets.
 
 Example::
 
-TOR_PT_OUTBOUND_BIND_ADDRESS_V6=[2001:db8::4]
+TOR_PT_OUTBOUND_BIND_ADDRESS_V6=\[2001:db8::4\]
 
 <a id="pt-spec.txt-3.2.2"></a>
 
@@ -124,7 +124,7 @@ TOR_PT_CLIENT_TRANSPORTS=obfs2,obfs3,obfs4
 "TOR_PT_PROXY"
 
 Specifies an upstream proxy that the PT MUST use when making
-outgoing network connections.  It is a URI [RFC3986] of the
+outgoing network connections.  It is a URI \[RFC3986\] of the
 format:
 
 `<proxy_type>://[<user_name>[:<password>][@]<ip>:<port>`.
@@ -230,7 +230,7 @@ TOR_PT_ORPORT=127.0.0.1:9001
 "TOR_PT_EXTENDED_SERVER_PORT"
 
 Specifies the destination that the PT reverse proxy should
-forward traffic to, via the Extended ORPort protocol [EXTORPORT]
+forward traffic to, via the Extended ORPort protocol \[EXTORPORT\]
 as an `<address>:<port>`.
 
 The Extended ORPort protocol allows the PT reverse proxy to
diff --git a/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md b/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md
index 2a1cb72..201fc92 100644
--- a/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md
+++ b/spec/rend-spec-v3/deriving-blinded-keys-subcredentials-subcred.md
@@ -1,13 +1,13 @@
 <a id="rend-spec-v3.txt-2.1"></a>
 
-## Deriving blinded keys and subcredentials [SUBCRED]
+## Deriving blinded keys and subcredentials \[SUBCRED\]
 
-In each time period (see [TIME-PERIODS] for a definition of time
+In each time period (see \[TIME-PERIODS\] for a definition of time
 periods), a hidden service host uses a different blinded private key
 to sign its directory information, and clients use a different
 blinded public key as the index for fetching that information.
 
-For a candidate for a key derivation method, see Appendix [KEYBLIND].
+For a candidate for a key derivation method, see Appendix \[KEYBLIND\].
 
 Additionally, clients and hosts derive a subcredential for each
 period. Knowledge of the subcredential is needed to decrypt hidden
@@ -58,7 +58,7 @@ Which Tor servers hosts a hidden service depends on:
 
 <a id="rend-spec-v3.txt-2.2.1"></a>
 
-### Dividing time into periods [TIME-PERIODS]
+### Dividing time into periods \[TIME-PERIODS\]
 
 To prevent a single set of hidden service directory from becoming a
 target by adversaries looking to permanently censor a hidden service,
@@ -79,7 +79,7 @@ dividing by the time period (effectively making "our" epoch start at Jan
 
 Example: If the current time is 2016-04-13 11:15:01 UTC, making the seconds
 since the epoch 1460546101, and the number of minutes since the epoch
-24342435.  We then subtract the "rotation time offset" of 12*60 minutes from
+24342435\.  We then subtract the "rotation time offset" of 12\*60 minutes from
 the minutes since the epoch, to get 24341715. If the current time period
 length is 1440 minutes, by doing the division we see that we are currently
 in time period number 16903.
@@ -90,17 +90,17 @@ after the epoch, at 2016-04-12 12:00 UTC, and ended at 16904*1440*60 +
 
 <a id="rend-spec-v3.txt-2.2.2"></a>
 
-### When to publish a hidden service descriptor [WHEN-HSDESC]
+### When to publish a hidden service descriptor \[WHEN-HSDESC\]
 
 Hidden services periodically publish their descriptor to the responsible
 HSDirs. The set of responsible HSDirs is determined as specified in
-[WHERE-HSDESC].
+\[WHERE-HSDESC\].
 
 Specifically, every time a hidden service publishes its descriptor, it also
 sets up a timer for a random time between 60 minutes and 120 minutes in the
 future. When the timer triggers, the hidden service needs to publish its
 descriptor again to the responsible HSDirs for that time period.
-[TODO: Control republish period using a consensus parameter?]
+\[TODO: Control republish period using a consensus parameter?\]
 
 <a id="rend-spec-v3.txt-2.2.2.1"></a>
 
@@ -118,14 +118,14 @@ Hence, services maintain two active descriptors at every point. Clients on
 the other hand, don't have a notion of overlapping descriptors, and instead
 always download the descriptor for the current time period and shared random
 value. It's the job of the service to ensure that descriptors will be
-available for all clients. See section [FETCHUPLOADDESC] for how this is
+available for all clients. See section \[FETCHUPLOADDESC\] for how this is
 achieved.
 
-[TODO: What to do when we run multiple hidden services in a single host?]
+\[TODO: What to do when we run multiple hidden services in a single host?\]
 
 <a id="rend-spec-v3.txt-2.2.3"></a>
 
-### Where to publish a hidden service descriptor [WHERE-HSDESC]
+### Where to publish a hidden service descriptor \[WHERE-HSDESC\]
 
 This section specifies how the HSDir hash ring is formed at any given
 time. Whenever a time value is needed (e.g. to get the current time period
@@ -155,10 +155,10 @@ derived, the uploading or downloading party calculates:
                                      INT_8(period_num) )
 ```
 
-where blinded_public_key is specified in section [KEYBLIND], period_length
+where blinded_public_key is specified in section \[KEYBLIND\], period_length
 is the length of the time period in minutes, and period_num is calculated
 using the current consensus "valid-after" as specified in section
-[TIME-PERIODS].
+\[TIME-PERIODS\].
 
 Then, for each node listed in the current consensus with the HSDir flag,
 we compute a directory index for that node as:
@@ -171,7 +171,7 @@ we compute a directory index for that node as:
 ```
 
 where shared_random_value is the shared value generated by the authorities
-in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity
+in section \[PUB-SHAREDRANDOM\], and node_identity is the ed25519 identity
 key of the node.
 
 Finally, for replicanum in 1...hsdir_n_replicas, the hidden service
@@ -190,7 +190,7 @@ choosing the spread for a replica.
 
 <a id="rend-spec-v3.txt-2.2.4"></a>
 
-### Using time periods and SRVs to fetch/upload HS descriptors [FETCHUPLOADDESC]
+### Using time periods and SRVs to fetch/upload HS descriptors \[FETCHUPLOADDESC\]
 
 Hidden services and clients need to make correct use of time periods (TP)
 and shared random values (SRVs) to successfully fetch and upload
@@ -202,7 +202,7 @@ of clients and services due to system clock. Whenever time-based decisions
 are taken in this section, assume that they are consensus times and not
 system times.
 
-As [PUB-SHAREDRANDOM] specifies, consensuses contain two shared random
+As \[PUB-SHAREDRANDOM\] specifies, consensuses contain two shared random
 values (the current one and the previous one). Hidden services and clients
 are asked to match these shared random values with descriptor time periods
 and use the right SRV when fetching/uploading descriptors. This section
@@ -228,7 +228,7 @@ Let's start with an illustration of the system:
 
 <a id="rend-spec-v3.txt-2.2.4.1"></a>
 
-#### Client behavior for fetching descriptors [CLIENTFETCH]
+#### Client behavior for fetching descriptors \[CLIENTFETCH\]
 
 And here is how clients use TPs and SRVs to fetch descriptors:
 
@@ -258,7 +258,7 @@ after SRV#2, it will still use TP#1 and SRV#1.
 
 <a id="rend-spec-v3.txt-2.2.4.2"></a>
 
-#### Service behavior for uploading descriptors [SERVICEUPLOAD]
+#### Service behavior for uploading descriptors \[SERVICEUPLOAD\]
 
 As discussed above, services maintain two active descriptors at any time. We
 call these the "first" and "second" service descriptors. Services rotate
@@ -272,7 +272,7 @@ values based on their position in the graph above. Here is the logic:
 
 <a id="rend-spec-v3.txt-2.2.4.2.1"></a>
 
-##### First descriptor upload logic [FIRSTDESCUPLOAD]
+##### First descriptor upload logic \[FIRSTDESCUPLOAD\]
 
 Here is the service logic for uploading its first descriptor:
 
@@ -308,7 +308,7 @@ first descriptor using TP#1 and SRV#1.
 
 <a id="rend-spec-v3.txt-2.2.4.2.2"></a>
 
-##### Second descriptor upload logic [SECONDDESCUPLOAD]
+##### Second descriptor upload logic \[SECONDDESCUPLOAD\]
 
 Here is the service logic for uploading its second descriptor:
 
@@ -342,7 +342,7 @@ second descriptor using TP#2 and SRV#2.
 
 <a id="rend-spec-v3.txt-2.2.4.3"></a>
 
-#### Directory behavior for handling descriptor uploads [DIRUPLOAD]
+#### Directory behavior for handling descriptor uploads \[DIRUPLOAD\]
 
 Upon receiving a hidden service descriptor publish request, directories MUST
 check the following:
@@ -368,12 +368,12 @@ necessary client credentials (for decrypting the second layer).
 
 <a id="rend-spec-v3.txt-2.2.5"></a>
 
-### Expiring hidden service descriptors [EXPIRE-DESC]
+### Expiring hidden service descriptors \[EXPIRE-DESC\]
 
 Hidden services set their descriptor's "descriptor-lifetime" field to 180
 minutes (3 hours). Hidden services ensure that their descriptor will remain
 valid in the HSDir caches, by republishing their descriptors periodically as
-specified in [WHEN-HSDESC].
+specified in \[WHEN-HSDESC\].
 
 Hidden services MUST also keep their introduction circuits alive for as long
 as descriptors including those intro points are valid (even if that's after
@@ -415,4 +415,4 @@ The right way for clients to detect such fraudulent addresses (which should
 only occur malevolently and never naturally) is to extract the ed25519
 public key from the onion address and multiply it by the ed25519 group order
 and ensure that the result is the ed25519 identity element. For more
-details, please see [TORSION-REFS].
+details, please see \[TORSION-REFS\].
diff --git a/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md b/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md
index 7919b73..14b3c44 100644
--- a/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md
+++ b/spec/rend-spec-v3/encoding-onion-addresses-onionaddress.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-6"></a>
 
-# Encoding onion addresses [ONIONADDRESS]
+# Encoding onion addresses \[ONIONADDRESS\]
 
 The onion address of a hidden service includes its identity public key, a
 version field and a basic checksum. All this information is then base32
@@ -24,4 +24,4 @@ encoded as shown below:
 ```
 
 For more information about this encoding, please see our discussion thread
-at [ONIONADDRESS-REFS].
+at \[ONIONADDRESS-REFS\].
diff --git a/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md b/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md
index a540bec..8b1d75a 100644
--- a/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md
+++ b/spec/rend-spec-v3/generating-publishing-hidden-service-descriptors.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2"></a>
 
-# Generating and publishing hidden service descriptors [HSDIR]
+# Generating and publishing hidden service descriptors \[HSDIR\]
 
 Hidden service descriptors follow the same metaformat as other Tor
 directory objects. They are published anonymously to Tor servers with the
diff --git a/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md b/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md
index 719d4fa..834aceb 100644
--- a/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md
+++ b/spec/rend-spec-v3/hidden-service-descriptors-encryption-format-hs-desc-enc.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.5"></a>
 
-## Hidden service descriptors: encryption format [HS-DESC-ENC]
+## Hidden service descriptors: encryption format \[HS-DESC-ENC\]
 
 Hidden service descriptors are protected by two layers of encryption.
 Clients need to decrypt both layers to connect to the hidden service.
@@ -12,7 +12,7 @@ and protects against entities that do not possess valid client credentials.
 
 <a id="rend-spec-v3.txt-2.5.1"></a>
 
-### First layer of encryption [HS-DESC-FIRST-LAYER]
+### First layer of encryption \[HS-DESC-FIRST-LAYER\]
 
 The first layer of HS descriptor encryption is designed to protect
 descriptor confidentiality against entities who don't know the public
@@ -23,7 +23,7 @@ identity key of the hidden service.
 #### First layer encryption logic
 
 The encryption keys and format for the first layer of encryption are
-generated as specified in [HS-DESC-ENCRYPTION-KEYS] with customization
+generated as specified in \[HS-DESC-ENCRYPTION-KEYS\] with customization
 parameters:
 
 ```text
@@ -31,8 +31,8 @@ parameters:
      STRING_CONSTANT = "hsdir-superencrypted-data"
 ```
 
-The encryption scheme in [HS-DESC-ENCRYPTION-KEYS] uses the service
-credential which is derived from the public identity key (see [SUBCRED]) to
+The encryption scheme in \[HS-DESC-ENCRYPTION-KEYS\] uses the service
+credential which is derived from the public identity key (see \[SUBCRED\]) to
 ensure that only entities who know the public identity key can decrypt the
 first descriptor layer.
 
@@ -64,7 +64,7 @@ Here are all the supported fields:
 
 "desc-auth-type" SP type NL
 
-[Exactly once]
+\[Exactly once\]
 
 ```text
       This field contains the type of authorization used to protect the
@@ -138,7 +138,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.1.3"></a>
 
-#### Client behavior [FIRST-LAYER-CLIENT-BEHAVIOR]
+#### Client behavior \[FIRST-LAYER-CLIENT-BEHAVIOR\]
 
 ```text
     The goal of clients at this stage is to decrypt the "encrypted" field as
@@ -183,7 +183,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.2"></a>
 
-### Second layer of encryption [HS-DESC-SECOND-LAYER]
+### Second layer of encryption \[HS-DESC-SECOND-LAYER\]
 
 The second layer of descriptor encryption is designed to protect descriptor
 confidentiality against unauthorized clients. If client authorization is
@@ -199,7 +199,7 @@ does not offer any additional security, but is still used.
 #### Second layer encryption keys
 
 The encryption keys and format for the second layer of encryption are
-generated as specified in [HS-DESC-ENCRYPTION-KEYS] with customization
+generated as specified in \[HS-DESC-ENCRYPTION-KEYS\] with customization
 parameters as follows:
 
 ```text
@@ -220,7 +220,7 @@ list of intro points etc. The plaintext has the following format:
 
 "create2-formats" SP formats NL
 
-[Exactly once]
+\[Exactly once\]
 
 ```text
       A space-separated list of integers denoting CREATE2 cell HTYPEs
@@ -387,7 +387,7 @@ Other encryption and authentication key formats are allowed; clients
 should ignore ones they do not recognize.
 
 Clients who manage to extract the introduction points of the hidden service
-can proceed with the introduction protocol as specified in [INTRO-PROTOCOL].
+can proceed with the introduction protocol as specified in \[INTRO-PROTOCOL\].
 
 Compatibility note: At least some versions of OnionBalance do not include
 a final newline when generating this inner plaintext section; other
@@ -396,7 +396,7 @@ newline.
 
 <a id="rend-spec-v3.txt-2.5.3"></a>
 
-### Deriving hidden service descriptor encryption keys [HS-DESC-ENCRYPTION-KEYS]
+### Deriving hidden service descriptor encryption keys \[HS-DESC-ENCRYPTION-KEYS\]
 
 In this section we present the generic encryption format for hidden service
 descriptors. We use the same encryption format in both encryption layers,
@@ -439,7 +439,7 @@ Here is the key generation logic:
 
 <a id="rend-spec-v3.txt-2.5.4"></a>
 
-### Number of introduction points [NUM_INTRO_POINT]
+### Number of introduction points \[NUM_INTRO_POINT\]
 
 This section defines how many introduction points an hidden service
 descriptor can have at minimum, by default and the maximum:
diff --git a/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md b/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md
index f981e11..5f4b5de 100644
--- a/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md
+++ b/spec/rend-spec-v3/hidden-service-descriptors-outer-wrapper-desc-outer.md
@@ -1,13 +1,13 @@
 <a id="rend-spec-v3.txt-2.4"></a>
 
-## Hidden service descriptors: outer wrapper [DESC-OUTER]
+## Hidden service descriptors: outer wrapper \[DESC-OUTER\]
 
 The format for a hidden service descriptor is as follows, using the
 meta-format from dir-spec.txt.
 
 "hs-descriptor" SP version-number NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 ```text
        The version-number is a 32 bit unsigned integer indicating the version
diff --git a/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md b/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md
index 9f6cfc6..f5c06f4 100644
--- a/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md
+++ b/spec/rend-spec-v3/hidden-service-directory-format-hidservdir-format.md
@@ -1,17 +1,17 @@
 <a id="rend-spec-v3.txt-F"></a>
 
-# Appendix F: Hidden service directory format [HIDSERVDIR-FORMAT]
+# Appendix F: Hidden service directory format \[HIDSERVDIR-FORMAT\]
 
 This appendix section specifies the contents of the HiddenServiceDir directory:
 
-- "hostname"                                       [FILE]
+- "hostname"                                       \[FILE\]
 
 This file contains the onion address of the onion service.
 
-- "private_key_ed25519"                            [FILE]
+- "private_key_ed25519"                            \[FILE\]
 
 This file contains the private master ed25519 key of the onion service.
-[TODO: Offline keys]
+\[TODO: Offline keys\]
 
 ```text
   - "./authorized_clients/"                  [DIRECTORY]
@@ -25,6 +25,6 @@ file for each authorized client. Each such file contains the public key of
 the respective client. The files are transmitted to the service operator by
 the client.
 
-See section [CLIENT-AUTH-MGMT] for more details and the format of the client file.
+See section \[CLIENT-AUTH-MGMT\] for more details and the format of the client file.
 
 (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)
diff --git a/spec/rend-spec-v3/hidden-services-overview-preliminaries.md b/spec/rend-spec-v3/hidden-services-overview-preliminaries.md
index 382c732..cf16ff4 100644
--- a/spec/rend-spec-v3/hidden-services-overview-preliminaries.md
+++ b/spec/rend-spec-v3/hidden-services-overview-preliminaries.md
@@ -70,8 +70,8 @@ We write sequences of bytes in two ways:
 ```
 
 We use INT_N(val) to denote the network (big-endian) encoding of the
-unsigned integer "val" in N bytes. For example, INT_4(1337) is [00 00
-05 39]. Values are truncated like so: val % (2 ^ (N * 8)). For example,
+unsigned integer "val" in N bytes. For example, INT_4(1337) is \[00 00
+05 39\]. Values are truncated like so: val % (2 ^ (N * 8)). For example,
 INT_4(42) is 42 % 4294967296 (32 bit).
 
 <a id="rend-spec-v3.txt-0.3"></a>
@@ -133,21 +133,21 @@ This specification uses the following cryptographic building blocks:
         where k_len is htonll(len(k)).
 ```
 
- When we need a particular MAC key length below, we choose
- MAC_KEY_LEN=32 (256 bits).
+When we need a particular MAC key length below, we choose
+MAC_KEY_LEN=32 (256 bits).
 
 For legacy purposes, we specify compatibility with older versions of
 the Tor introduction point and rendezvous point protocols. These used
 RSA1024, DH1024, AES128, and SHA1, as discussed in
 rend-spec.txt.
 
-As in [proposal 220], all signatures are generated not over strings
+As in \[proposal 220\], all signatures are generated not over strings
 themselves, but over those strings prefixed with a distinguishing
 value.
 
 <a id="rend-spec-v3.txt-0.4"></a>
 
-## Protocol building blocks [BUILDING-BLOCKS]
+## Protocol building blocks \[BUILDING-BLOCKS\]
 
 In sections below, we need to transmit the locations and identities
 of Tor nodes. We do so in the link identification format used by
@@ -162,8 +162,8 @@ EXTEND2 cells in the Tor protocol.
 ```
 
 Link specifier types are as described in tor-spec.txt. Every set of
-link specifiers SHOULD include at minimum specifiers of type [00]
-(TLS-over-TCP, IPv4), [02] (legacy node identity) and [03] (ed25519
+link specifiers SHOULD include at minimum specifiers of type \[00\]
+(TLS-over-TCP, IPv4), \[02\] (legacy node identity) and \[03\] (ed25519
 identity key).  Sets of link specifiers without these three types
 SHOULD be rejected.
 
@@ -308,8 +308,8 @@ editing help from
       Tim Wilson-Brown ("teor"),
 ```
 
-[XXX  Acknowledge the huge bunch of people working on 8106.]
-[XXX  Acknowledge the huge bunch of people working on 8244.]
+\[XXX  Acknowledge the huge bunch of people working on 8106.\]
+\[XXX  Acknowledge the huge bunch of people working on 8244.\]
 
 Please forgive me if I've missed you; please forgive me if I've
 misunderstood your best ideas here too.
diff --git a/spec/rend-spec-v3/introduction-protocol-intro-protocol.md b/spec/rend-spec-v3/introduction-protocol-intro-protocol.md
index e1977fc..f4e6358 100644
--- a/spec/rend-spec-v3/introduction-protocol-intro-protocol.md
+++ b/spec/rend-spec-v3/introduction-protocol-intro-protocol.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-3"></a>
 
-# The introduction protocol [INTRO-PROTOCOL]
+# The introduction protocol \[INTRO-PROTOCOL\]
 
 The introduction protocol proceeds in three steps.
 
@@ -30,11 +30,11 @@ the introduction request to the client.
 
 <a id="rend-spec-v3.txt-3.1"></a>
 
-## Registering an introduction point [REG_INTRO_POINT]
+## Registering an introduction point \[REG_INTRO_POINT\]
 
 <a id="rend-spec-v3.txt-3.1.1"></a>
 
-### Extensible ESTABLISH_INTRO protocol. [EST_INTRO]
+### Extensible ESTABLISH_INTRO protocol. \[EST_INTRO\]
 
 When a hidden service is establishing a new introduction point, it
 sends an ESTABLISH_INTRO cell with the following contents:
@@ -115,7 +115,7 @@ later in INTRODUCE1 cells.
 
 <a id="rend-spec-v3.txt-3.1.1.1"></a>
 
-#### Denial-of-Service Defense Extension. [EST_INTRO_DOS_EXT]
+#### Denial-of-Service Defense Extension. \[EST_INTRO_DOS_EXT\]
 
 This extension can be used to send Denial-of-Service (DoS) parameters to
 the introduction point in order for it to apply them for the introduction
@@ -127,7 +127,7 @@ defined as follow:
 
 EXT_FIELD_TYPE:
 
-[01] -- Denial-of-Service Parameters.
+\[01\] -- Denial-of-Service Parameters.
 
 ```text
          If this flag is set, the extension should be used by the introduction
@@ -189,7 +189,7 @@ Introduced in tor-0.4.2.1-alpha.
 Tor nodes should also support an older version of the ESTABLISH_INTRO
 cell, first documented in rend-spec.txt. New hidden service hosts
 must use this format when establishing introduction points at older
-Tor nodes that do not support the format above in [EST_INTRO].
+Tor nodes that do not support the format above in \[EST_INTRO\].
 
 In this older protocol, an ESTABLISH_INTRO cell contains:
 
@@ -215,7 +215,7 @@ authentication keys.
 
 <a id="rend-spec-v3.txt-3.1.3"></a>
 
-### Acknowledging establishment of introduction point [INTRO_ESTABLISHED]
+### Acknowledging establishment of introduction point \[INTRO_ESTABLISHED\]
 
 After setting up an introduction circuit, the introduction point reports its
 status back to the hidden service host with an INTRO_ESTABLISHED cell.
@@ -232,15 +232,15 @@ The INTRO_ESTABLISHED cell has the following contents:
 
 Older versions of Tor send back an empty INTRO_ESTABLISHED cell instead.
 Services must accept an empty INTRO_ESTABLISHED cell from a legacy relay.
-[The above paragraph is obsolete and refers to a workaround for
-now-obsolete Tor relay versions. It is included for historical reasons.]
+\[The above paragraph is obsolete and refers to a workaround for
+now-obsolete Tor relay versions. It is included for historical reasons.\]
 
 The same rules for multiplicity, ordering, and handling unknown types
-apply to the extension fields here as described [EST_INTRO] above.
+apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.2"></a>
 
-## Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1]
+## Sending an INTRODUCE1 cell to the introduction point. \[SEND_INTRO1\]
 
 In order to participate in the introduction protocol, a client must
 know the following:
@@ -267,7 +267,7 @@ or that its request will not succeed.
 
 <a id="rend-spec-v3.txt-3.2.1"></a>
 
-### INTRODUCE1 cell format [FMT_INTRO1]
+### INTRODUCE1 cell format \[FMT_INTRO1\]
 
 When a client is connecting to an introduction point, INTRODUCE1 cells
 should be of the form:
@@ -285,8 +285,8 @@ should be of the form:
      ENCRYPTED        [Up to end of relay payload]
 ```
 
-AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of
-AUTH_KEY_TYPE for this cell is an Ed25519 public key [02].
+AUTH_KEY_TYPE is defined as in \[EST_INTRO\]. Currently, the only value of
+AUTH_KEY_TYPE for this cell is an Ed25519 public key \[02\].
 
 The LEGACY_KEY_ID field is used to distinguish between legacy and new style
 INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero
@@ -306,11 +306,11 @@ change the order or multiplicity of the extensions sent by the
 client.)
 
 The same rules for multiplicity, ordering, and handling unknown types
-apply to the extension fields here as described [EST_INTRO] above.
+apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.2.2"></a>
 
-### INTRODUCE_ACK cell format. [INTRO_ACK]
+### INTRODUCE_ACK cell format. \[INTRO_ACK\]
 
 An INTRODUCE_ACK cell has the following fields:
 
@@ -331,11 +331,11 @@ An INTRODUCE_ACK cell has the following fields:
 ```
 
 The same rules for multiplicity, ordering, and handling unknown types
-apply to the extension fields here as described [EST_INTRO] above.
+apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.3"></a>
 
-## Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2]
+## Processing an INTRODUCE2 cell at the hidden service. \[PROCESS_INTRO2\]
 
 Upon receiving an INTRODUCE2 cell, the hidden service host checks whether
 the AUTH_KEY or LEGACY_KEY_ID field matches the keys for this
@@ -353,8 +353,8 @@ contents of the cell as having been unmodified since they left the
 client. There may be multiple ways of decrypting the ENCRYPTED field,
 depending on the chosen type of the encryption key. Requirements for
 an introduction handshake protocol are described in
-[INTRO-HANDSHAKE-REQS]. We specify one below in section
-[NTOR-WITH-EXTRA-DATA].
+\[INTRO-HANDSHAKE-REQS\]. We specify one below in section
+\[NTOR-WITH-EXTRA-DATA\].
 
 The decrypted plaintext must have the form:
 
@@ -380,7 +380,7 @@ Upon processing this plaintext, the hidden service makes sure that
 any required authentication is present in the extension fields, and
 then extends a rendezvous circuit to the node described in the LSPEC
 fields, using the ONION_KEY to complete the extension. As mentioned
-in [BUILDING-BLOCKS], the "TLS-over-TCP, IPv4" and "Legacy node
+in \[BUILDING-BLOCKS\], the "TLS-over-TCP, IPv4" and "Legacy node
 identity" specifiers must be present.
 
 As of 0.4.1.1-alpha, clients include both IPv4 and IPv6 link specifiers
@@ -402,7 +402,7 @@ NOT modify it.
 
 The ONION_KEY_TYPE field is:
 
-[01] NTOR:          ONION_KEY is 32 bytes long.
+\[01\] NTOR:          ONION_KEY is 32 bytes long.
 
 The ONION_KEY field describes the onion key that must be used when
 extending to the rendezvous point. It must be of a type listed as
@@ -428,11 +428,11 @@ will have:
 ```
 
 The same rules for multiplicity, ordering, and handling unknown types
-apply to the extension fields here as described [EST_INTRO] above.
+apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.3.1"></a>
 
-### Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS]
+### Introduction handshake encryption requirements \[INTRO-HANDSHAKE-REQS\]
 
 When decoding the encrypted information in an INTRODUCE2 cell, a
 hidden service host must be able to:
@@ -504,7 +504,7 @@ and computes:
 ```
 
 Substituting those fields into the INTRODUCE1 cell body format
-described in [FMT_INTRO1] above, we have
+described in \[FMT_INTRO1\] above, we have
 
 ```text
             LEGACY_KEY_ID               [20 bytes]
@@ -522,7 +522,7 @@ described in [FMT_INTRO1] above, we have
                MAC                      [MAC_LEN bytes]
 ```
 
-(This format is as documented in [FMT_INTRO1] above, except that here
+(This format is as documented in \[FMT_INTRO1\] above, except that here
 we describe how to build the ENCRYPTED portion.)
 
 Here, the encryption key plays the role of B in the regular ntor
@@ -570,7 +570,7 @@ introduction point encryption key 'b' to compute:
 ```
 
 These fields will be sent to the client in a RENDEZVOUS1 cell using the
-HANDSHAKE_INFO element (see [JOIN_REND]).
+HANDSHAKE_INFO element (see \[JOIN_REND\]).
 
 The hidden service host now also knows the keys generated by the
 handshake, which it will use to encrypt and authenticate data
@@ -580,7 +580,7 @@ AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256.
 
 <a id="rend-spec-v3.txt-3.4"></a>
 
-## Authentication during the introduction phase. [INTRO-AUTH]
+## Authentication during the introduction phase. \[INTRO-AUTH\]
 
 Hidden services may restrict access only to authorized users.
 One mechanism to do so is the credential mechanism, where only users who
@@ -601,7 +601,7 @@ the number of keys a user needs to have.)
 
 To authenticate with an Ed25519 private key, the user must include an
 extension field in the encrypted part of the INTRODUCE1 cell with an
-EXT_FIELD_TYPE type of [02] and the contents:
+EXT_FIELD_TYPE type of \[02\] and the contents:
 
 ```text
         Nonce     [16 bytes]
@@ -610,8 +610,8 @@ EXT_FIELD_TYPE type of [02] and the contents:
 ```
 
 Nonce is a random value. Pubkey is the public key that will be used
-to authenticate. [TODO: should this be an identifier for the public
-key instead?]  Signature is the signature, using Ed25519, of:
+to authenticate. \[TODO: should this be an identifier for the public
+key instead?\]  Signature is the signature, using Ed25519, of:
 
 ```text
         "hidserv-userauth-ed25519"
diff --git a/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md b/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md
index 2051e86..1cffce4 100644
--- a/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md
+++ b/spec/rend-spec-v3/managing-authorized-client-data-client-auth-mgmt.md
@@ -1,11 +1,11 @@
 <a id="rend-spec-v3.txt-G"></a>
 
-# Appendix G: Managing authorized client data [CLIENT-AUTH-MGMT]
+# Appendix G: Managing authorized client data \[CLIENT-AUTH-MGMT\]
 
 Hidden services and clients can configure their authorized client data either
 using the torrc, or using the control port. This section presents a suggested
 scheme for configuring client authorization. Please see appendix
-[HIDSERVDIR-FORMAT] for more information about relevant hidden service files.
+\[HIDSERVDIR-FORMAT\] for more information about relevant hidden service files.
 
 (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)
 
diff --git a/spec/rend-spec-v3/numeric-values-reserved-this-document.md b/spec/rend-spec-v3/numeric-values-reserved-this-document.md
index 1e11c73..7a2f01f 100644
--- a/spec/rend-spec-v3/numeric-values-reserved-this-document.md
+++ b/spec/rend-spec-v3/numeric-values-reserved-this-document.md
@@ -2,4 +2,4 @@
 
 # Appendix D: Numeric values reserved in this document
 
-[TODO: collect all the lists of commands and values mentioned above]
+\[TODO: collect all the lists of commands and values mentioned above\]
diff --git a/spec/rend-spec-v3/open-questions.md b/spec/rend-spec-v3/open-questions.md
index 140b1f5..b95717a 100644
--- a/spec/rend-spec-v3/open-questions.md
+++ b/spec/rend-spec-v3/open-questions.md
@@ -3,18 +3,18 @@
 # Open Questions
 
 Scaling hidden services is hard. There are on-going discussions that
-you might be able to help with. See [SCALING-REFS].
+you might be able to help with. See \[SCALING-REFS\].
 
 How can we improve the HSDir unpredictability design proposed in
-[SHAREDRANDOM]? See [SHAREDRANDOM-REFS] for discussion.
+\[SHAREDRANDOM\]? See \[SHAREDRANDOM-REFS\] for discussion.
 
 How can hidden service addresses become memorable while retaining
 their self-authenticating and decentralized nature? See
-[HUMANE-HSADDRESSES-REFS] for some proposals; many more are possible.
+\[HUMANE-HSADDRESSES-REFS\] for some proposals; many more are possible.
 
 Hidden Services are pretty slow. Both because of the lengthy setup
 procedure and because the final circuit has 6 hops. How can we make
-the Hidden Service protocol faster? See [PERFORMANCE-REFS] for some
+the Hidden Service protocol faster? See \[PERFORMANCE-REFS\] for some
 suggestions.
 
 References:
diff --git a/spec/rend-spec-v3/protocol-overview.md b/spec/rend-spec-v3/protocol-overview.md
index 1c03e49..173240e 100644
--- a/spec/rend-spec-v3/protocol-overview.md
+++ b/spec/rend-spec-v3/protocol-overview.md
@@ -47,7 +47,7 @@ communicate data on those streams, and so forth.
 
 <a id="rend-spec-v3.txt-1.2"></a>
 
-## In more detail: naming hidden services [NAMING]
+## In more detail: naming hidden services \[NAMING\]
 
 A hidden service's name is its long term master identity key.  This is
 encoded as a hostname by encoding the entire key in Base 32, including a
@@ -73,7 +73,7 @@ their length. An older name might look like:
 
 <a id="rend-spec-v3.txt-1.3"></a>
 
-## In more detail: Access control [IMD:AC]
+## In more detail: Access control \[IMD:AC\]
 
 Access control for a hidden service is imposed at multiple points through
 the process above. Furthermore, there is also the option to impose
@@ -108,7 +108,7 @@ require the client to prove knowledge of a pre-shared private key.
 
 <a id="rend-spec-v3.txt-1.4"></a>
 
-## In more detail: Distributing hidden service descriptors. [IMD:DIST]
+## In more detail: Distributing hidden service descriptors. \[IMD:DIST\]
 
 Periodically, hidden service descriptors become stored at different
 locations to prevent a single directory or small set of directories
@@ -118,14 +118,14 @@ For each period, the Tor directory authorities agree upon a
 collaboratively generated random value. (See section 2.3 for a
 description of how to incorporate this value into the voting
 practice; generating the value is described in other proposals,
-including [SHAREDRANDOM-REFS].) That value, combined with hidden service
+including \[SHAREDRANDOM-REFS\].) That value, combined with hidden service
 directories' public identity keys, determines each HSDir's position
 in the hash ring for descriptors made in that period.
 
 Each hidden service's descriptors are placed into the ring in
 positions based on the key that was used to sign them. Note that
 hidden service descriptors are not signed with the services' public
-keys directly. Instead, we use a key-blinding system [KEYBLIND] to
+keys directly. Instead, we use a key-blinding system \[KEYBLIND\] to
 create a new key-of-the-day for each hidden service. Any client that
 knows the hidden service's public identity key can derive these blinded
 signing keys for a given period. It should be impossible to derive
@@ -159,7 +159,7 @@ This design is compatible with our current approaches for scaling hidden
 services. Specifically, hidden service operators can use onionbalance to
 achieve high availability between multiple nodes on the HSDir
 layer. Furthermore, operators can use proposal 255 to load balance their
-hidden services on the introduction layer. See [SCALING-REFS] for further
+hidden services on the introduction layer. See \[SCALING-REFS\] for further
 discussions on this topic and alternative designs.
 
 ```text
@@ -183,7 +183,7 @@ which are used to sign descriptor signing keys.
 
 In order to operate a hidden service, the operator can generate in
 advance a number of blinded signing keys and descriptor signing
-keys (and their credentials; see [DESC-OUTER] and [HS-DESC-ENC]
+keys (and their credentials; see \[DESC-OUTER\] and \[HS-DESC-ENC\]
 below), and their corresponding descriptor encryption keys, and
 export those to the hidden service hosts.
 
@@ -215,9 +215,9 @@ discussion.)
 
 ## In more detail: A menagerie of keys
 
-[In the text below, an "encryption keypair" is roughly "a keypair you
+\[In the text below, an "encryption keypair" is roughly "a keypair you
 can do Diffie-Hellman with" and a "signing keypair" is roughly "a
-keypair you can do ECDSA with."]
+keypair you can do ECDSA with."\]
 
 Public/private keypairs defined in this document:
 
@@ -292,7 +292,7 @@ Public/private keypairs defined in this document:
 
 <a id="rend-spec-v3.txt-1.9.1"></a>
 
-### In even more detail: Client authorization keys [CLIENT-AUTH]
+### In even more detail: Client authorization keys \[CLIENT-AUTH\]
 
 When client authorization is enabled, each authorized client of a hidden
 service has two more asymmetric keypairs which are shared with the hidden
@@ -320,9 +320,9 @@ The right way to exchange these keys is to have the client generate keys and
 send the corresponding public keys to the hidden service out-of-band. An
 easier but less secure way of doing this exchange would be to have the
 hidden service generate the keypairs and pass the corresponding private keys
-to its clients. See section [CLIENT-AUTH-MGMT] for more details on how these
+to its clients. See section \[CLIENT-AUTH-MGMT\] for more details on how these
 keys should be managed.
 
-[TODO: Also specify stealth client authorization.]
+\[TODO: Also specify stealth client authorization.\]
 
 (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)
diff --git a/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md b/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md
index dce072c..707c7da 100644
--- a/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md
+++ b/spec/rend-spec-v3/publishing-shared-random-values-pub-sharedrandom.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.3"></a>
 
-## Publishing shared random values [PUB-SHAREDRANDOM]
+## Publishing shared random values \[PUB-SHAREDRANDOM\]
 
 Our design for limiting the predictability of HSDir upload locations
 relies on a shared random value (SRV) that isn't predictable in advance or
@@ -8,7 +8,7 @@ too influenceable by an attacker. The authorities must run a protocol
 to generate such a value at least once per hsdir period. Here we
 describe how they publish these values; the procedure they use to
 generate them can change independently of the rest of this
-specification. For more information see [SHAREDRANDOM-REFS].
+specification. For more information see \[SHAREDRANDOM-REFS\].
 
 According to proposal 250, we add two new lines in consensuses:
 
@@ -31,7 +31,7 @@ SRV = H("shared-random-disaster" | INT_8(period_length) | INT_8(period_num))
 
 where period_length is the length of a time period in minutes,
 rounded down; period_num is calculated as specified in
-[TIME-PERIODS] for the wanted shared random value that could not be
+\[TIME-PERIODS\] for the wanted shared random value that could not be
 found originally.
 
 <a id="rend-spec-v3.txt-2.3.2"></a>
diff --git a/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md b/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md
index 3c7142b..f07d108 100644
--- a/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md
+++ b/spec/rend-spec-v3/recommendations-for-searching-for-vanity-onions.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-C"></a>
 
-# Appendix C: Recommendations for searching for vanity .onions [VANITY]
+# Appendix C: Recommendations for searching for vanity .onions \[VANITY\]
 
 EDITORIAL NOTE: The author thinks that it's silly to brute-force the
 keyspace for a key that, when base-32 encoded, spells out the name of
@@ -30,16 +30,16 @@ While pk does not satisfy X:
         Return sk, pk.
 ```
 
-We add 8 and 8*B, rather than 1 and B, so that sk is always a valid
+We add 8 and 8\*B, rather than 1 and B, so that sk is always a valid
 Curve25519 private key, with the lowest 3 bits equal to 0.
 
-This algorithm is safe [source: djb, personal communication] [TODO:
-Make sure I understood correctly!] so long as only the final (sk,pk)
+This algorithm is safe \[source: djb, personal communication\] \[TODO:
+Make sure I understood correctly!\] so long as only the final (sk,pk)
 pair is used, and all previous values are discarded.
 
 To parallelize this algorithm, start with an independent (sk,pk) pair
 generated for each independent thread, and let each search proceed
 independently.
 
-See [VANITY-REFS] for a reference implementation of this vanity .onion
+See \[VANITY-REFS\] for a reference implementation of this vanity .onion
 search scheme.
diff --git a/spec/rend-spec-v3/rendezvous-protocol.md b/spec/rend-spec-v3/rendezvous-protocol.md
index 316bcf2..683d9e4 100644
--- a/spec/rend-spec-v3/rendezvous-protocol.md
+++ b/spec/rend-spec-v3/rendezvous-protocol.md
@@ -21,12 +21,12 @@ but use an anonymous 3-hop circuit if:
 
 <a id="rend-spec-v3.txt-4.1"></a>
 
-## Establishing a rendezvous point [EST_REND_POINT]
+## Establishing a rendezvous point \[EST_REND_POINT\]
 
 The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS
 cell containing a 20-byte value.
 
-RENDEZVOUS_COOKIE         [20 bytes]
+RENDEZVOUS_COOKIE         \[20 bytes\]
 
 Rendezvous points MUST ignore any extra bytes in an
 ESTABLISH_RENDEZVOUS cell. (Older versions of Tor did not.)
@@ -50,7 +50,7 @@ connect to a hidden service.
 
 <a id="rend-spec-v3.txt-4.2"></a>
 
-## Joining to a rendezvous point [JOIN_REND]
+## Joining to a rendezvous point \[JOIN_REND\]
 
 To complete a rendezvous, the hidden service host builds a circuit to
 the rendezvous point and sends a RENDEZVOUS1 cell containing:
@@ -62,8 +62,8 @@ the rendezvous point and sends a RENDEZVOUS1 cell containing:
 ```
 
 where RENDEZVOUS_COOKIE is the cookie suggested by the client during the
-introduction (see [PROCESS_INTRO2]) and HANDSHAKE_INFO is defined in
-[NTOR-WITH-EXTRA-DATA].
+introduction (see \[PROCESS_INTRO2\]) and HANDSHAKE_INFO is defined in
+\[NTOR-WITH-EXTRA-DATA\].
 
 If the cookie matches the rendezvous cookie set on any
 not-yet-connected circuit on the rendezvous point, the rendezvous
@@ -73,7 +73,7 @@ client containing the HANDSHAKE_INFO field of the RENDEZVOUS1 cell.
 Upon receiving the RENDEZVOUS2 cell, the client verifies that HANDSHAKE_INFO
 correctly completes a handshake. To do so, the client parses SERVER_PK from
 HANDSHAKE_INFO and reverses the final operations of section
-[NTOR-WITH-EXTRA-DATA] as shown here:
+\[NTOR-WITH-EXTRA-DATA\] as shown here:
 
 ```text
       rend_secret_hs_input = EXP(Y,x) | EXP(B,x) | AUTH_KEY | B | X | Y | PROTOID
@@ -112,16 +112,16 @@ keys for the ORs in Alice's side of the circuit, then decrypts them with Kb,
 and checks integrity with Db.  Bob's OP does the same, with Kf and Kb
 interchanged.
 
-[TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2
+\[TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2
 contents? It's not necessary, but it could be wise. Similarly, we
-should make it extensible.]
+should make it extensible.\]
 
 <a id="rend-spec-v3.txt-4.3"></a>
 
 ## Using legacy hosts as rendezvous points
 
-[This section is obsolete and refers to a workaround for now-obsolete Tor
-relay versions. It is included for historical reasons.]
+\[This section is obsolete and refers to a workaround for now-obsolete Tor
+relay versions. It is included for historical reasons.\]
 
 The behavior of ESTABLISH_RENDEZVOUS is unchanged from older versions
 of this protocol, except that relays should now ignore unexpected
diff --git a/spec/rend-spec-v3/selecting-nodes-picknodes.md b/spec/rend-spec-v3/selecting-nodes-picknodes.md
index ef5edb4..8b0973c 100644
--- a/spec/rend-spec-v3/selecting-nodes-picknodes.md
+++ b/spec/rend-spec-v3/selecting-nodes-picknodes.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-B"></a>
 
-# Appendix B: Selecting nodes [PICKNODES]
+# Appendix B: Selecting nodes \[PICKNODES\]
 
 Picking introduction points
 Picking rendezvous points
diff --git a/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md b/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md
index d0393dd..8a7b1a2 100644
--- a/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md
+++ b/spec/rend-spec-v3/signature-scheme-with-key-blinding-keyblind.md
@@ -1,12 +1,12 @@
 <a id="rend-spec-v3.txt-A"></a>
 
-# Appendix A: Signature scheme with key blinding [KEYBLIND]
+# Appendix A: Signature scheme with key blinding \[KEYBLIND\]
 
 <a id="rend-spec-v3.txt-A.1"></a>
 
 ## Key derivation overview
 
-As described in [IMD:DIST] and [SUBCRED] above, we require a "key
+As described in \[IMD:DIST\] and \[SUBCRED\] above, we require a "key
 blinding" system that works (roughly) as follows:
 
 There is a master keypair (sk, pk).
@@ -43,10 +43,10 @@ We propose the following scheme for key blinding, based on Ed25519.
 
 (This is an ECC group, so remember that scalar multiplication is the
 trapdoor function, and it's defined in terms of iterated point
-addition. See the Ed25519 paper [Reference ED25519-REFS] for a fairly
+addition. See the Ed25519 paper \[Reference ED25519-REFS\] for a fairly
 clear writeup.)
 
-Let B be the ed25519 basepoint as found in section 5 of [ED25519-B-REF]:
+Let B be the ed25519 basepoint as found in section 5 of \[ED25519-B-REF\]:
 
 ```text
       B = (15112221349535400772501151409588531511454012693041857206046113283949847762202,
@@ -99,6 +99,6 @@ Verifying the signature: Check whether SB = R+hash(R,A',M)A'.
   This boils down to regular Ed25519 with key pair (a', A').
 ```
 
-See [KEYBLIND-REFS] for an extensive discussion on this scheme and
-possible alternatives. Also, see [KEYBLIND-PROOF] for a security
+See \[KEYBLIND-REFS\] for an extensive discussion on this scheme and
+possible alternatives. Also, see \[KEYBLIND-PROOF\] for a security
 proof of this scheme.
diff --git a/spec/socks-extensions.md b/spec/socks-extensions.md
index 6486215..d4d7010 100644
--- a/spec/socks-extensions.md
+++ b/spec/socks-extensions.md
@@ -22,8 +22,8 @@ to another address and port.  The SOCKS server establishes the connection,
 and reports success or failure to the client.  After the connection has
 been established, the client application uses the TCP stream as usual.
 
-Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and
-SOCKS5 as defined in [3] and [4].
+Tor supports SOCKS4 as defined in \[1\], SOCKS4A as defined in \[2\], and
+SOCKS5 as defined in \[3\] and \[4\].
 
 The stickiest issue for Tor in supporting clients, in practice, is forcing
 DNS lookups to occur at the OR side: if clients do their own DNS lookup,
@@ -75,7 +75,7 @@ manpage.)
 # Name lookup
 
 As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
-"RESOLVE" [F0].  When Tor receives a "RESOLVE" SOCKS command, it initiates
+"RESOLVE" \[F0\].  When Tor receives a "RESOLVE" SOCKS command, it initiates
 a remote lookup of the hostname provided as the target address in the SOCKS
 request.  The reply is either an error (if the address couldn't be
 resolved) or a success response.  In the case of success, the address is
@@ -84,7 +84,7 @@ stored in the portion of the SOCKS response reserved for remote IP address.
 (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)
 
 For SOCKS5 only, we support reverse resolution with a new command value,
-"RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with
+"RESOLVE_PTR" \[F1\]. In response to a "RESOLVE_PTR" SOCKS5 command with
 an IPv4 address as its target, Tor attempts to find the canonical
 hostname for that IPv4 record, and returns it in the "server bound
 address" portion of the reply.
@@ -94,7 +94,7 @@ address" portion of the reply.
 
 # Other command extensions
 
-Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2].
+Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" \[F2\].
 In this case, Tor will open an encrypted direct TCP connection to the
 directory port of the Tor server specified by address:port (the port
 specified should be the ORPort of the server). It uses a one-hop tunnel
diff --git a/spec/srv-spec/overview.md b/spec/srv-spec/overview.md
index 6da4599..a9f4c99 100644
--- a/spec/srv-spec/overview.md
+++ b/spec/srv-spec/overview.md
@@ -22,7 +22,7 @@ cryptographically hashes the random value and calls the output its
 The idea is that given a reveal value you can cryptographically confirm that
 it corresponds to a given commitment value (by hashing it). However given a
 commitment value you should not be able to derive the underlying reveal
-value. The construction of these values is specified in section [COMMITREVEAL].
+value. The construction of these values is specified in section \[COMMITREVEAL\].
 
 <a id="srv-spec.txt-2.1"></a>
 
@@ -62,7 +62,7 @@ Commit phase:
 
 <a id="srv-spec.txt-2.3"></a>
 
-## How we use the consensus [CONS]
+## How we use the consensus \[CONS\]
 
 The produced shared random values need to be readily available to
 clients. For this reason we include them in the consensus documents.
@@ -70,7 +70,7 @@ clients. For this reason we include them in the consensus documents.
 Every hour the consensus documents need to include the shared random value
 of the day, as well as the shared random value of the previous day. That's
 because either of these values might be needed at a given time for a Tor
-client to access a hidden service according to section [TIME-OVERLAP] of
+client to access a hidden service according to section \[TIME-OVERLAP\] of
 proposal 224. This means that both of these two values need to be included
 in votes as well.
 
@@ -124,7 +124,7 @@ reachability consequences for hidden service clients.
 
 <a id="srv-spec.txt-2.4"></a>
 
-## Persistent State of the Protocol [STATE]
+## Persistent State of the Protocol \[STATE\]
 
 A directory authority needs to keep a persistent state on disk of the on
 going protocol run. This allows an authority to join the protocol seamlessly
diff --git a/spec/srv-spec/protocol.md b/spec/srv-spec/protocol.md
index 7a17004..683b65e 100644
--- a/spec/srv-spec/protocol.md
+++ b/spec/srv-spec/protocol.md
@@ -4,13 +4,13 @@
 
 In this section we give a detailed specification of the protocol. We
 describe the protocol participants' logic and the messages they send. The
-encoding of the messages is specified in the next section ([SPEC]).
+encoding of the messages is specified in the next section (\[SPEC\]).
 
 Now we go through the phases of the protocol:
 
 <a id="srv-spec.txt-3.1"></a>
 
-## Commitment Phase [COMMITMENTPHASE]
+## Commitment Phase \[COMMITMENTPHASE\]
 
 The commit phase lasts from 00:00UTC to 12:00UTC.
 
@@ -43,7 +43,7 @@ authorities. Any subsequent commitments MUST be ignored.
 
 <a id="srv-spec.txt-3.1.2"></a>
 
-### Persistent State During Commitment Phase [STATECOMMIT]
+### Persistent State During Commitment Phase \[STATECOMMIT\]
 
 During the commitment phase, authorities save in their persistent state the
 authoritative commits they have received from each authority. Only one commit
@@ -77,12 +77,12 @@ the new commitment MUST be ignored.
 
 <a id="srv-spec.txt-3.2.2"></a>
 
-### Persistent State During Reveal Phase [STATEREVEAL]
+### Persistent State During Reveal Phase \[STATEREVEAL\]
 
 During the reveal phase, authorities keep the authoritative commits from the
 commit phase in their persistent state. They also save any received reveals
 that correspond to authoritative commits and are valid (as specified in
-[VALIDATEVALUES]).
+\[VALIDATEVALUES\]).
 
 An authority that just received a reveal value from another authority's vote,
 MUST wait till the next voting round before including that reveal value in
@@ -96,18 +96,18 @@ Finally, at 00:00UTC every day, authorities compute a fresh shared random
 value and this value must be added to the consensus so clients can use it.
 
 Authorities calculate the shared random value using the reveal values in
-their state as specified in subsection [SRCALC].
+their state as specified in subsection \[SRCALC\].
 
 Authorities at 00:00UTC start including this new shared random value in
 their votes, replacing the one from two protocol runs ago. Authorities also
 start including this new shared random value in the consensus as well.
 
 Apart from that, authorities at 00:00UTC proceed voting normally as they
-would in the first round of the commitment phase (section [COMMITMENTPHASE]).
+would in the first round of the commitment phase (section \[COMMITMENTPHASE\]).
 
 <a id="srv-spec.txt-3.3.1"></a>
 
-### Shared Randomness Calculation [SRCALC]
+### Shared Randomness Calculation \[SRCALC\]
 
 An authority that wants to derive the shared random value SRV, should use
 the appropriate reveal values for that time period and calculate SRV as
@@ -126,7 +126,7 @@ is the corresponding reveal value of that authority for the current period.
 Also, REVEAL_NUM is the number of revealed values in this construction,
 VERSION is the protocol version number and PREVIOUS_SRV is the previous
 shared random value. If no previous shared random value is known, then
-PREVIOUS_SRV is set to 32 NUL (\x00) bytes.
+PREVIOUS_SRV is set to 32 NUL (\\x00) bytes.
 
 To maintain consistent ordering in HASHED_REVEALS, all the ID_a | R_a pairs
 are ordered based on the R_a value in ascending order.
@@ -135,7 +135,7 @@ are ordered based on the R_a value in ascending order.
 
 ## Bootstrapping Procedure
 
-As described in [CONS], two shared random values are required for the HSDir
+As described in \[CONS\], two shared random values are required for the HSDir
 overlay periods to work properly as specified in proposal 224. Hence
 clients MUST NOT use the randomness of this system till it has bootstrapped
 completely; that is, until two shared random values are included in a
@@ -144,7 +144,7 @@ produced, which takes 48 hours.
 
 <a id="srv-spec.txt-3.5"></a>
 
-## Rebooting Directory Authorities [REBOOT]
+## Rebooting Directory Authorities \[REBOOT\]
 
 The shared randomness protocol must be able to support directory
 authorities who leave or join in the middle of the protocol execution.
@@ -162,4 +162,4 @@ the protocol SHOULD still carry commits and reveals of others in their vote.
 Finally, authorities MUST implement their persistent state in such a way that they
 will never commit two different values in the same protocol run, even if they
 have to reboot in the middle (assuming that their persistent state file is
-kept). A suggested way to structure the persistent state is found at [STATEFORMAT].
+kept). A suggested way to structure the persistent state is found at \[STATEFORMAT\].
diff --git a/spec/srv-spec/security-analysis.md b/spec/srv-spec/security-analysis.md
index 658c2f8..a1cc72d 100644
--- a/spec/srv-spec/security-analysis.md
+++ b/spec/srv-spec/security-analysis.md
@@ -19,12 +19,12 @@ for now.
 
 Here are some examples of possible future directions:
 
-- Schemes based on threshold signatures (e.g. see [HOPPER])
-- Unicorn scheme by Lenstra et al. [UNICORN]
-- Schemes based on Verifiable Delay Functions [VDFS]
+- Schemes based on threshold signatures (e.g. see \[HOPPER\])
+- Unicorn scheme by Lenstra et al. \[UNICORN\]
+- Schemes based on Verifiable Delay Functions \[VDFS\]
 
 For more alternative approaches on collaborative random number generation
-also see the discussion at [RNGMESSAGING].
+also see the discussion at \[RNGMESSAGING\].
 
 <a id="srv-spec.txt-5.2"></a>
 
diff --git a/spec/srv-spec/specification-spec.md b/spec/srv-spec/specification-spec.md
index 8a35d22..63ffaff 100644
--- a/spec/srv-spec/specification-spec.md
+++ b/spec/srv-spec/specification-spec.md
@@ -1,6 +1,6 @@
 <a id="srv-spec.txt-4"></a>
 
-# Specification [SPEC]
+# Specification \[SPEC\]
 
 <a id="srv-spec.txt-4.1"></a>
 
@@ -20,7 +20,7 @@ in their votes to announce that they take part in the protocol.
 
 <a id="srv-spec.txt-4.1.1"></a>
 
-### Computing commitments and reveals [COMMITREVEAL]
+### Computing commitments and reveals \[COMMITREVEAL\]
 
 A directory authority that wants to participate in this protocol needs to
 create a new pair of commitment/reveal values for every protocol
@@ -48,7 +48,7 @@ REVEAL = base64-encode( TIMESTAMP || H(RN) )
 
 <a id="srv-spec.txt-4.1.2"></a>
 
-### Validating commitments and reveals [VALIDATEVALUES]
+### Validating commitments and reveals \[VALIDATEVALUES\]
 
 Given a COMMIT message and a REVEAL message it should be possible to verify
 that they indeed correspond. To do so, the client extracts the random value
@@ -64,17 +64,17 @@ correspond to commit values published during the Commitment Phase.
 
 <a id="srv-spec.txt-4.1.4"></a>
 
-### Encoding commit/reveal values in votes [COMMITVOTE]
+### Encoding commit/reveal values in votes \[COMMITVOTE\]
 
 An authority puts in its vote the commitments and reveals it has produced and
 seen from the other authorities. To do so, it includes the following in its
 votes:
 
-"shared-rand-commit" SP VERSION SP ALGNAME SP IDENTITY SP COMMIT [SP REVEAL] NL
+"shared-rand-commit" SP VERSION SP ALGNAME SP IDENTITY SP COMMIT \[SP REVEAL\] NL
 
 where VERSION is the version of the protocol the commit was created with.
 IDENTITY is the authority's SHA1 identity fingerprint and COMMIT is the
-encoded commit [COMMITREVEAL].  Authorities during the reveal phase can
+encoded commit \[COMMITREVEAL\].  Authorities during the reveal phase can
 also optionally include an encoded reveal value REVEAL.  There MUST be only
 one line per authority else the vote is considered invalid. Finally, the
 ALGNAME is the hash algorithm that should be used to compute COMMIT and
@@ -82,7 +82,7 @@ REVEAL which is "sha3-256" for version 1.
 
 <a id="srv-spec.txt-4.1.5"></a>
 
-### Shared Random Value [SRVOTE]
+### Shared Random Value \[SRVOTE\]
 
 Authorities include a shared random value (SRV) in their votes using the
 following encoding for the previous and current value respectively:
@@ -93,7 +93,7 @@ following encoding for the previous and current value respectively:
 ```
 
 where VALUE is the actual shared random value encoded in hex (computed as
-specified in section [SRCALC]. NUM_REVEALS is the number of reveal values
+specified in section \[SRCALC\]. NUM_REVEALS is the number of reveal values
 used to generate this SRV.
 
 To maintain consistent ordering, the shared random values of the previous
@@ -101,14 +101,14 @@ period should be listed before the values of the current period.
 
 <a id="srv-spec.txt-4.2"></a>
 
-## Encoding Shared Random Values in the consensus [SRCONSENSUS]
+## Encoding Shared Random Values in the consensus \[SRCONSENSUS\]
 
 Authorities insert the two active shared random values in the consensus
-following the same encoding format as in [SRVOTE].
+following the same encoding format as in \[SRVOTE\].
 
 <a id="srv-spec.txt-4.3"></a>
 
-## Persistent state format [STATEFORMAT]
+## Persistent state format \[STATEFORMAT\]
 
 As a way to keep ground truth state in this protocol, an authority MUST
 keep a persistent state of the protocol. The next sub-section suggest a
@@ -122,13 +122,13 @@ the order given here:
 
 "Version" SP version NL
 
-[At start, exactly once.]
+\[At start, exactly once.\]
 
 A document format version. For this specification, version is "1".
 
 "ValidUntil" SP YYYY-MM-DD SP HH:MM:SS NL
 
-[Exactly once]
+\[Exactly once\]
 
 ```text
         After this time, this state is expired and shouldn't be used nor
@@ -139,11 +139,11 @@ A document format version. For this specification, version is "1".
 The following details the commitment and reveal section. They are encoded
 the same as in the vote. This makes it easier for implementation purposes.
 
-"Commit" SP version SP algname SP identity SP commit [SP reveal] NL
+"Commit" SP version SP algname SP identity SP commit \[SP reveal\] NL
 
-[Exactly once per authority]
+\[Exactly once per authority\]
 
-The values are the same as detailed in section [COMMITVOTE].
+The values are the same as detailed in section \[COMMITVOTE\].
 
 This line is also used by an authority to store its own value.
 
@@ -151,7 +151,7 @@ Finally is the shared random value section.
 
 "SharedRandPreviousValue" SP num_reveals SP value NL
 
-[At most once]
+\[At most once\]
 
 ```text
         This is the previous shared random value agreed on at the previous
diff --git a/spec/tor-spec/closing-streams.md b/spec/tor-spec/closing-streams.md
index 9ef1b98..5fa84a8 100644
--- a/spec/tor-spec/closing-streams.md
+++ b/spec/tor-spec/closing-streams.md
@@ -42,7 +42,7 @@ versions of Tor may provide more fine-grained reasons.
 
 For most reasons, the format of RELAY_END is:
 
-Reason                      [1 byte]
+Reason                      \[1 byte\]
 
 For REASON_EXITPOLICY, the format of RELAY_END is:
 
@@ -72,7 +72,7 @@ how many cells of which types (CONNECTED, SENDME, DATA) that it would have
 accepted on that stream, and SHOULD kill the circuit if it receives more
 than permitted.
 
---- [The rest of this section describes unimplemented functionality.]
+--- \[The rest of this section describes unimplemented functionality.\]
 
 Because TCP connections can be half-open, we follow an equivalent
 to TCP's FIN/FIN-ACK/ACK protocol to close streams.
diff --git a/spec/tor-spec/connections.md b/spec/tor-spec/connections.md
index a7ba661..9495fe4 100644
--- a/spec/tor-spec/connections.md
+++ b/spec/tor-spec/connections.md
@@ -133,8 +133,8 @@ malformed or missing certificates.  (However, an OR should not believe
 that an incoming connection is from another OR unless the certificates
 are present and well-formed.)
 
-[Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and
-OPs alike if their certificates were missing or malformed.]
+\[Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and
+OPs alike if their certificates were missing or malformed.\]
 
 Once a TLS connection is established, the two sides send cells
 (specified below) to one another.  Cells are sent serially.  Standard
diff --git a/spec/tor-spec/create-created-cells.md b/spec/tor-spec/create-created-cells.md
index 56134e4..4574f03 100644
--- a/spec/tor-spec/create-created-cells.md
+++ b/spec/tor-spec/create-created-cells.md
@@ -52,7 +52,7 @@ ntor -- 'ntorNTORntorNTOR'
 
 The format of a CREATED cell is:
 
-HDATA     (Server Handshake Data)     [TAP_S_HANDSHAKE_LEN bytes]
+HDATA     (Server Handshake Data)     \[TAP_S_HANDSHAKE_LEN bytes\]
 
 (It's equivalent to a CREATED2 cell with length of TAP_S_HANDSHAKE_LEN.)
 
@@ -67,7 +67,7 @@ Servers always reply to a successful CREATE with a CREATED, and to a
 successful CREATE2 with a CREATED2.  On failure, a server sends a
 DESTROY cell to tear down the circuit.
 
-[CREATE2 is handled by Tor 0.2.4.7-alpha and later.]
+\[CREATE2 is handled by Tor 0.2.4.7-alpha and later.\]
 
 <a id="tor-spec.txt-5.1.1"></a>
 
@@ -144,8 +144,8 @@ instances of specifiers other than 'legacy identity' and
 that include multiple instances of either one of those specifiers.)
 
 For purposes of indistinguishability, implementations SHOULD send
-these link specifiers, if using them, in this order: [00], [02], [03],
-[01].
+these link specifiers, if using them, in this order: \[00\], \[02\], \[03\],
+\[01\].
 
 The relay payload for an EXTEND relay cell consists of:
 
@@ -190,7 +190,7 @@ CREATED cell.
 The payload of an EXTENDED2 cell is the same as the payload of a
 CREATED2 cell.
 
-[Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.]
+\[Support for EXTEND2/EXTENDED2 was added in Tor 0.2.4.8-alpha.\]
 
 Clients SHOULD use the EXTEND format whenever sending a TAP
 handshake, and MUST use it whenever the EXTEND cell will be handled
@@ -269,7 +269,7 @@ original handshake (or with nobody at all).  Here we use the
 "curve25519" group and representation as specified in "Curve25519:
 new Diffie-Hellman speed records" by D. J. Bernstein.
 
-[The ntor handshake was added in Tor 0.2.4.8-alpha.]
+\[The ntor handshake was added in Tor 0.2.4.8-alpha.\]
 
 In this section, define:
 
@@ -330,8 +330,8 @@ private key 'b' to compute:
 ```
 
 Both parties check that none of the EXP() operations produced the
-point at infinity. [NOTE: This is an adequate replacement for
-checking Y for group membership, if the group is curve25519.]
+point at infinity. \[NOTE: This is an adequate replacement for
+checking Y for group membership, if the group is curve25519.\]
 
 Both parties now have a shared value for KEY_SEED.  They expand this
 into the keys needed for the Tor relay protocol, using the KDF
@@ -507,7 +507,7 @@ created.
 
 A CREATE_FAST cell contains:
 
-Key material (X)    [HASH_LEN bytes]
+Key material (X)    \[HASH_LEN bytes\]
 
 A CREATED_FAST cell contains:
 
@@ -525,7 +525,7 @@ The CREATE_FAST handshake is currently deprecated whenever it is not
 necessary; the migration is controlled by the "usecreatefast"
 networkstatus parameter as described in dir-spec.txt.
 
-[Tor 0.3.1.1-alpha and later disable CREATE_FAST by default.]
+\[Tor 0.3.1.1-alpha and later disable CREATE_FAST by default.\]
 
 <a id="tor-spec.txt-5.1.6"></a>
 
diff --git a/spec/tor-spec/flow-control.md b/spec/tor-spec/flow-control.md
index 960bd21..e007529 100644
--- a/spec/tor-spec/flow-control.md
+++ b/spec/tor-spec/flow-control.md
@@ -146,7 +146,7 @@ DATA_LEN and how to handle it. The recognized values are:
 
 0x01: Authenticated SENDME. The DATA section MUST contain:
 
-DIGEST   [20 bytes]
+DIGEST   \[20 bytes\]
 
 ```text
          If the DATA_LEN value is less than 20 bytes, the cell should be
@@ -176,7 +176,7 @@ control for individual connections across circuits. Similarly to
 circuit-level flow control, edge nodes begin with a window of cells
 (500) per stream, and increment the window by a fixed value (50)
 upon receiving a RELAY_SENDME cell. Edge nodes initiate RELAY_SENDME
-cells when both a) the window is <= 450, and b) there are less than
+cells when both a) the window is \<= 450, and b) there are less than
 ten cell payloads remaining to be flushed at that edge.
 
 Stream-level RELAY_SENDME cells are distinguished by having nonzero
diff --git a/spec/tor-spec/handling-relay_early-cells.md b/spec/tor-spec/handling-relay_early-cells.md
index 9adbced..2517dcc 100644
--- a/spec/tor-spec/handling-relay_early-cells.md
+++ b/spec/tor-spec/handling-relay_early-cells.md
@@ -16,5 +16,5 @@ EXTEND/EXTEND2 cells inside RELAY_EARLY cells.  Clients SHOULD send the first
 ~8 RELAY cells that are not targeted at the first hop of any circuit as
 RELAY_EARLY cells too, in order to partially conceal the circuit length.
 
-[Starting with Tor 0.2.3.11-alpha, relays should reject any
-EXTEND/EXTEND2 cell not received in a RELAY_EARLY cell.]
+\[Starting with Tor 0.2.3.11-alpha, relays should reject any
+EXTEND/EXTEND2 cell not received in a RELAY_EARLY cell.\]
diff --git a/spec/tor-spec/negotiating-initializing-connections.md b/spec/tor-spec/negotiating-initializing-connections.md
index dd9be1d..2b8ebd6 100644
--- a/spec/tor-spec/negotiating-initializing-connections.md
+++ b/spec/tor-spec/negotiating-initializing-connections.md
@@ -31,9 +31,9 @@ those specified, except for VPADDING cells.
 The AUTHORIZE cell type is reserved for future use by scanning-resistance
 designs.
 
-[Tor versions before 0.2.3.11-alpha did not recognize the AUTHORIZE cell,
+\[Tor versions before 0.2.3.11-alpha did not recognize the AUTHORIZE cell,
 and did not permit any command other than VERSIONS as the first cell of
-the in-protocol handshake.]
+the in-protocol handshake.\]
 
 <a id="tor-spec.txt-4.1"></a>
 
diff --git a/spec/tor-spec/opening-streams-transferring-data.md b/spec/tor-spec/opening-streams-transferring-data.md
index 8300ace..956e2c8 100644
--- a/spec/tor-spec/opening-streams-transferring-data.md
+++ b/spec/tor-spec/opening-streams-transferring-data.md
@@ -60,10 +60,10 @@ payload is in one of the following formats:
        A number of seconds (TTL) for which the address may be cached [4 octets]
 ```
 
-[Tor exit nodes before 0.1.2.0 set the TTL field to a fixed value.  Later
+\[Tor exit nodes before 0.1.2.0 set the TTL field to a fixed value.  Later
 versions set the TTL to the last value seen from a DNS server, and expire
 their own cached entries after a fixed interval.  This prevents certain
-attacks.]
+attacks.\]
 
 Once a connection has been established, the OP and exit node
 package stream data in RELAY_DATA cells, and upon receiving such
@@ -99,10 +99,10 @@ policy, since the stream is local to the Tor process.
 
 Directory servers may be:
 
-* authoritative directories (RELAY_BEGIN_DIR, usually non-anonymous),
-* bridge authoritative directories (RELAY_BEGIN_DIR, anonymous),
-* directory mirrors (RELAY_BEGIN_DIR, usually non-anonymous),
-* onion service directories (RELAY_BEGIN_DIR, anonymous).
+- authoritative directories (RELAY_BEGIN_DIR, usually non-anonymous),
+- bridge authoritative directories (RELAY_BEGIN_DIR, anonymous),
+- directory mirrors (RELAY_BEGIN_DIR, usually non-anonymous),
+- onion service directories (RELAY_BEGIN_DIR, anonymous).
 
 If the Tor relay is not running a directory service, it should respond
 with a REASON_NOTDIRECTORY RELAY_END cell.
@@ -115,5 +115,5 @@ RELAY_CONNECTED cell on success, or a RELAY_END cell on failure. They
 MUST send a RELAY_CONNECTED cell all-zero payload, and clients MUST ignore
 the payload.
 
-[RELAY_BEGIN_DIR was not supported before Tor 0.1.2.2-alpha; clients
-SHOULD NOT send it to routers running earlier versions of Tor.]
+\[RELAY_BEGIN_DIR was not supported before Tor 0.1.2.2-alpha; clients
+SHOULD NOT send it to routers running earlier versions of Tor.\]
diff --git a/spec/tor-spec/preliminaries.md b/spec/tor-spec/preliminaries.md
index c97e774..7967fcd 100644
--- a/spec/tor-spec/preliminaries.md
+++ b/spec/tor-spec/preliminaries.md
@@ -23,7 +23,7 @@
    a|b -- concatenation of 'a' and 'b'.
 ```
 
-[A0 B1 C2] -- a three-byte sequence, containing the bytes with
+\[A0 B1 C2\] -- a three-byte sequence, containing the bytes with
 hexadecimal values A0, B1, and C2, in that order.
 
 H(m) -- a cryptographic hash of m.
@@ -104,10 +104,10 @@ rfc2409 section 6.2 whose hex representation is:
 As an optimization, implementations SHOULD choose DH private keys (x) of
 320 bits.  Implementations that do this MUST never use any DH key more
 than once.
-[May other implementations reuse their DH keys?? -RD]
-[Probably not. Conceivably, you could get away with changing DH keys once
+\[May other implementations reuse their DH keys?? -RD\]
+\[Probably not. Conceivably, you could get away with changing DH keys once
 per second, but there are too many oddball attacks for me to be
-comfortable that this is safe. -NM]
+comfortable that this is safe. -NM\]
 
 For a hash function, unless otherwise specified, we use SHA-1.
 
diff --git a/spec/tor-spec/relay-cells.md b/spec/tor-spec/relay-cells.md
index 68e0391..364d2d2 100644
--- a/spec/tor-spec/relay-cells.md
+++ b/spec/tor-spec/relay-cells.md
@@ -9,9 +9,9 @@ by either edge; streams are initiated by the OP.
 
 End nodes that accept streams may be:
 
-* exit relays (RELAY_BEGIN, anonymous),
-* directory servers (RELAY_BEGIN_DIR, anonymous or non-anonymous),
-* onion services (RELAY_BEGIN, anonymous via a rendezvous point).
+- exit relays (RELAY_BEGIN, anonymous),
+- directory servers (RELAY_BEGIN_DIR, anonymous or non-anonymous),
+- onion services (RELAY_BEGIN, anonymous via a rendezvous point).
 
 The payload of each unencrypted RELAY cell consists of:
 
@@ -91,7 +91,7 @@ All RELAY cells pertaining to the same tunneled stream have the same
 stream ID.  StreamIDs are chosen arbitrarily by the OP.  No stream
 may have a StreamID of zero. Rather, RELAY cells that affect the
 entire circuit rather than a particular stream use a StreamID of zero
--- they are marked in the table above as "[control]" style
+-- they are marked in the table above as "\[control\]" style
 cells. (Sendme cells are marked as "sometimes control" because they
 can include a StreamID or not depending on their purpose -- see
 Section 7.)
diff --git a/spec/tor-spec/setting-circuit-keys.md b/spec/tor-spec/setting-circuit-keys.md
index b49f75d..f299f81 100644
--- a/spec/tor-spec/setting-circuit-keys.md
+++ b/spec/tor-spec/setting-circuit-keys.md
@@ -20,7 +20,7 @@ K0=X|Y.
 From the base key material K0, they compute KEY_LEN*2+HASH_LEN*3 bytes of
 derivative key data as
 
-K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ...
+K = H(K0 | \[00\]) | H(K0 | \[01\]) | H(K0 | \[02\]) | ...
 
 The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward
 digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next
diff --git a/spec/tor-spec/system-overview.md b/spec/tor-spec/system-overview.md
index 8577928..f05b893 100644
--- a/spec/tor-spec/system-overview.md
+++ b/spec/tor-spec/system-overview.md
@@ -5,10 +5,7 @@
 Tor is a distributed overlay network designed to anonymize
 low-latency TCP-based applications such as web browsing, secure shell,
 and instant messaging. Clients choose a path through the network and
-build a ``circuit'', in which each node (or``onion router'' or ``OR'')
-in the path knows its predecessor and successor, but no other nodes in
-the circuit.  Traffic flowing down the circuit is sent in fixed-size
-``cells'', which are unwrapped by a symmetric key at each node (like
+build a `circuit'', in which each node (or`onion router'' or `OR'') in the path knows its predecessor and successor, but no other nodes in the circuit.  Traffic flowing down the circuit is sent in fixed-size `cells'', which are unwrapped by a symmetric key at each node (like
 the layers of an onion) and relayed downstream.
 
 <a id="tor-spec.txt-1.1"></a>
@@ -60,7 +57,7 @@ These are 1024-bit RSA keys:
       KP_link_ed, KS_link_ed.
 ```
 
-KP_relayid_* together identify a router uniquely.  Once a router
+KP_relayid\_\* together identify a router uniquely.  Once a router
 has used a KP_relayid_ed (an Ed25519 master identity key)
 together with a given KP_relayid_rsa (RSA identity key), neither of
 those keys may ever be used with a different key.
diff --git a/spec/tor-spec/tearing-down-circuits.md b/spec/tor-spec/tearing-down-circuits.md
index 3008c05..f06b231 100644
--- a/spec/tor-spec/tearing-down-circuits.md
+++ b/spec/tor-spec/tearing-down-circuits.md
@@ -8,10 +8,10 @@ circuit's intended lifetime is over.
 
 ORs SHOULD also tear down circuits which attempt to create:
 
-* streams with RELAY_BEGIN, or
-* rendezvous points with ESTABLISH_RENDEZVOUS,
-ending at the first hop. Letting Tor be used as a single hop proxy makes
-exit and rendezvous nodes a more attractive target for compromise.
+- streams with RELAY_BEGIN, or
+- rendezvous points with ESTABLISH_RENDEZVOUS,
+  ending at the first hop. Letting Tor be used as a single hop proxy makes
+  exit and rendezvous nodes a more attractive target for compromise.
 
 ORs MAY use multiple methods to check if they are the first hop:
 
@@ -45,13 +45,13 @@ signaling a given OR (Stream ID zero).  That OR sends a DESTROY
 cell to the next node in the circuit, and replies to the OP with a
 RELAY_TRUNCATED cell.
 
-[Note: If an OR receives a TRUNCATE cell and it has any RELAY cells
+\[Note: If an OR receives a TRUNCATE cell and it has any RELAY cells
 still queued on the circuit for the next node it will drop them
 without sending them.  This is not considered conformant behavior,
 but it probably won't get fixed until a later version of Tor.  Thus,
 clients SHOULD NOT send a TRUNCATE cell to a node running any current
 version of Tor if a) they have sent relay cells through that node,
-and b) they aren't sure whether those cells have been sent on yet.]
+and b) they aren't sure whether those cells have been sent on yet.\]
 
 ```text
    When an unrecoverable error occurs along one a circuit, the nodes
@@ -79,7 +79,7 @@ towards the client, not RELAY_TRUNCATED.
 
 The payload of a DESTROY and RELAY_TRUNCATED cell contains a single
 octet, describing the reason that the circuit was
-closed. RELAY_TRUNCATED cells, and DESTROY cells sent _towards the
+closed. RELAY_TRUNCATED cells, and DESTROY cells sent \_towards the
 client, should contain the actual reason from the list of error codes
 below.  Reasons in DESTROY cell SHOULD NOT be propagated downward or
 upward, due to potential side channel risk: An OR receiving a DESTROY
author	Nick Mathewson <nickm@torproject.org>	2023-10-14 14:07:40 -0400
committer	Nick Mathewson <nickm@torproject.org>	2023-10-14 14:07:40 -0400
commit	4ba45dfd9afd08edeb46243127a480f1d23b9640 (patch)
tree	4dcdb3b4ac378b255d8292693ef234100bf67ac5
parent	d4b9bcc71565e1c3b7b74ddfcd44730697c10c6b (diff)
download	torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.tar.gz torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.zip