aboutsummaryrefslogtreecommitdiff
path: root/spec/path-spec
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2023-10-14 14:07:40 -0400
committerNick Mathewson <nickm@torproject.org>2023-10-14 14:07:40 -0400
commit4ba45dfd9afd08edeb46243127a480f1d23b9640 (patch)
tree4dcdb3b4ac378b255d8292693ef234100bf67ac5 /spec/path-spec
parentd4b9bcc71565e1c3b7b74ddfcd44730697c10c6b (diff)
downloadtorspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.tar.gz
torspec-4ba45dfd9afd08edeb46243127a480f1d23b9640.zip
Run mdformat on the spec files.
Diffstat (limited to 'spec/path-spec')
-rw-r--r--spec/path-spec/attaching-streams-to-circuits.md4
-rw-r--r--spec/path-spec/general-operation.md2
-rw-r--r--spec/path-spec/learning-when-to-give-up-timeout-on-circuit-construction.md6
-rw-r--r--spec/path-spec/old-notes.md10
4 files changed, 11 insertions, 11 deletions
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\]