torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2024-11-23 09:49:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix some easy typos in proposals

Browse Source
This commit is contained in:
Roger Dingledine 2022-07-27 01:25:09 -04:00
parent 6f9ec72e27
commit b5e2002983
3 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
proposals/326-tor-relay-well-known-uri-rfc8615.md
View File

@ -12,7 +12,7 @@ This is a specification for a well-known [registry](https://www.iana.org/assignm
This resource identifier can be used for serving and finding proofs related to [Tor](https://www.torproject.org/) relay and bridge contact information.
It can also be used for autodiscovery of Tor relays run by a given entity, if the entity's domain is known.
It solves the issue that Tor relay/bridge contact information is an unidirectional and unverified claim by nature.
It solves the issue that Tor relay/bridge contact information is a unidirectional and unverified claim by nature.
This well-known URI aims to allow the verification of the unidirectional claim.
It aims to reduce the risk of impersonation attacks, where a Tor relay/bridge claims to be operated by a certain entity, but actually isn't.
The automated verification will also support the [visualization of relay/bridge groups](https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001).

4
proposals/327-pow-over-intro.txt
View File

@ -339,7 +339,7 @@ Status: Draft
tuple. For this reason a replay protection mechanism must be employed.
The simplest way is to use a simple hash table to check whether a (seed,
nonce) tuple has been used before for the actiev duration of a
nonce) tuple has been used before for the active duration of a
seed. Depending on how long a seed stays active this might be a viable
solution with reasonable memory/time overhead.
@ -439,7 +439,7 @@ Status: Draft
Every HS_UPDATE_PERIOD seconds the service should upload a new descriptor
with a new suggested-effort value.
The service should avoid uploading descriptors too often to avoid overwheming
The service should avoid uploading descriptors too often to avoid overwhelming
the HSDirs. The service SHOULD NOT upload descriptors more often than
HS_UPDATE_PERIOD. The service SHOULD NOT upload a new descriptor if the
suggested-effort value changes by less than 15%.

6
proposals/341-better-oos.md
View File

@ -56,7 +56,7 @@ other words, when you see "A - B" below, read it as "MAX(A-B, 0)".
## Phase 1: Deciding how many connections to close
When we are find that we are low on sockets, we pick a number of sockets
When we find that we are low on sockets, we pick a number of sockets
that we want to close according to our existing algorithm. (That is, we
try to close 1/4 of our maximum sockets if we have reached our upper
limit, or 1/10 of our maximum sockets if we have encountered a failure
@ -133,8 +133,8 @@ until we have closed at least our target number of exit connections.
> This approach probabilistically favors closing circuits with a large
> number of sockets open, regardless of how long those sockets have been
> open. This defeats the easiest way of opening a large number of exit
> streams ("open them all on once circuit") without making the
> counter-approach ("open each exit stream on a its own circuit") much
> streams ("open them all on one circuit") without making the
> counter-approach ("open each exit stream on its own circuit") much
> more attractive.
## Phase 3: Closing OR connections.