Prop 327: fix minor typos

1 files changed, 15 insertions, 15 deletions

diff --git a/proposals/327-pow-over-intro.txt b/proposals/327-pow-over-intro.txt
index 6ce610e..3765b8b 100644
--- a/proposals/327-pow-over-intro.txt
+++ b/proposals/327-pow-over-intro.txt
@@ -40,7 +40,7 @@ Status: Draft
 
   This proposal is written to thwart specific attackers. A simple PoW proposal
   cannot defend against all and every DoS attack on the Internet, but there are
-  adverary models we can defend against.
+  adversary models we can defend against.
 
   Let's start with some adversary profiles:
 
@@ -48,21 +48,21 @@ Status: Draft
 
     The script-kiddie has a single computer and pushes it to its
     limits. Perhaps it also has a VPS and a pwned server. We are talking about
-    an attacker with total access to 10 Ghz of CPU and 10 GBs of RAM. We
+    an attacker with total access to 10 GHz of CPU and 10 GB of RAM. We
     consider the total cost for this attacker to be zero $.
 
   "The small botnet"
 
     The small botnet is a bunch of computers lined up to do an introduction
     flooding attack. Assuming 500 medium-range computers, we are talking about
-    an attacker with total access to 10 Thz of CPU and 10 TB of RAM. We
+    an attacker with total access to 10 THz of CPU and 10 TB of RAM. We
     consider the upfront cost for this attacker to be about $400.
 
   "The large botnet"
 
     The large botnet is a serious operation with many thousands of computers
     organized to do this attack. Assuming 100k medium-range computers, we are
-    talking about an attacker with total access to 200 Thz of CPU and 200 TB of
+    talking about an attacker with total access to 200 THz of CPU and 200 TB of
     RAM. The upfront cost for this attacker is about $36k.
 
   We hope that this proposal can help us defend against the script-kiddie
@@ -78,7 +78,7 @@ Status: Draft
     This is a standard laptop/desktop user who is trying to browse the
     web. They don't know how these defences work and they don't care to
     configure or tweak them. If the site doesn't load, they are gonna close
-    their browser and be sad at Tor. They run a 2Ghz computer with 4GB of RAM.
+    their browser and be sad at Tor. They run a 2GHz computer with 4GB of RAM.
 
   "The motivated user"
 
@@ -156,9 +156,9 @@ Status: Draft
 2.2.1. Algorithm overview
 
   For our proof-of-work function we will use the Equi-X scheme by tevador
-  [REF_EQUIX].  Equi-X is an assymetric PoW function based on Equihash<60,3>,
+  [REF_EQUIX].  Equi-X is an asymmetric PoW function based on Equihash<60,3>,
   using HashX as the underlying layer. It features lightning fast verification
-  speed, and also aims to minimize the assymetry between CPU and GPU.
+  speed, and also aims to minimize the asymmetry between CPU and GPU.
   Furthermore, it's designed for this particular use-case and hence
   cryptocurrency miners are not incentivized to make optimized ASICs for it.
 
@@ -178,7 +178,7 @@ Status: Draft
   4) The PoW protocol itself builds on this Equi-X function with a particular
      construction of the challenge input and particular constraints on the
      allowed blake2b hash of the solution. This layer provides a linearly
-     adjustible effort that we can verify.
+     adjustable effort that we can verify.
   5) Above the level of individual PoW handshakes, the client and service
      form a closed-loop system that adjusts the effort of future handshakes.
 
@@ -302,7 +302,7 @@ Status: Draft
   that will cause unacceptably long PoW computation.
 
   The client uses a "personalization string" P equal to the following
-  nul-terminated ascii string: "Tor hs intro v1\0".
+  nul-terminated ASCII string: "Tor hs intro v1\0".
 
   The client looks up `ID`, the current 32-byte blinded public ID
   (KP_hs_blind_id) for the onion service.
@@ -682,7 +682,7 @@ Status: Draft
 5.1.4. Gaming the effort estimation logic [ATTACK_EFFORT]
 
   Another way to beat this system is for the attacker to game the effort
-  estimation logic (see [EFFORT_ESTIMATION]). Essentialy, there are two attacks
+  estimation logic (see [EFFORT_ESTIMATION]). Essentially, there are two attacks
   that we are trying to avoid:
 
   - Attacker sets descriptor suggested-effort to a very high value effectively
@@ -734,7 +734,7 @@ Status: Draft
   Verifying a PoW token is the first thing that a service does when it receives
   an INTRODUCE2 cell and it's detailed in section [POW_VERIFY]. This
   verification happens during the "top half" part of the process. Every
-  milisecond spent verifying PoW adds overhead to the already existing "top
+  millisecond spent verifying PoW adds overhead to the already existing "top
   half" part of handling an introduction cell. Hence we should be careful to
   add minimal overhead here so that we don't enable attacks like [ATTACK_TOP_HALF].
 
@@ -796,7 +796,7 @@ Status: Draft
 
   The difficulty setting of our PoW basically dictates how difficult it should
   be to get a success in our PoW system. An attacker who can get many successes
-  per second can pull a successfull [ATTACK_BOTTOM_HALF] attack against our
+  per second can pull a successful [ATTACK_BOTTOM_HALF] attack against our
   system.
 
   In classic PoW systems, "success" is defined as getting a hash output below
@@ -936,7 +936,7 @@ Status: Draft
     This proposal suffers from various UX issues because there is no end-to-end
     mechanism for an onion service to inform the client about its introduction
     request. If we had end-to-end introduction ACKs many of the problems from
-    [CLIENT_BEHAVIOR] would be aleviated. The problem here is that end-to-end
+    [CLIENT_BEHAVIOR] would be alleviated. The problem here is that end-to-end
     ACKs require modifications on the introduction point code and a network
     update which is a lengthy process.
 
@@ -949,7 +949,7 @@ Status: Draft
 7.2.2. Future designs [FUTURE_DESIGNS]
 
   This is just the beginning in DoS defences for Tor and there are various
-  futured designs and schemes that we can investigate. Here is a brief summary
+  future designs and schemes that we can investigate. Here is a brief summary
   of these:
 
   "More advanced PoW schemes" -- We could use more advanced memory-hard PoW
@@ -1176,7 +1176,7 @@ A.4.1 Tor measurements [TOR_MEASUREMENTS]
 
      There is an average of 2.42 INTRODUCE2 cells per mainloop event and so we
      divide that by the full mainloop event mean time to get the time for one
-     cell. From that we substract the "bottom half" mean time to get how much
+     cell. From that we subtract the "bottom half" mean time to get how much
      the "top half" takes:
 
         => 13.43 / (7931 / 3279) = 5.55