Minor text revisions (typos, etc).

docs/Comparison.md

@@ -9,7 +9,7 @@
 
 ### Certificate Transparency
 
-Google's Certificate Transparency proposal wants certificate authorities (CAs) to publicly log all of the certificates that they issue. [It does not protect against NSA spying and MITM attacks](https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/). Website owners are then asked to monitor these logs to see if their clients were hacked. Everyone online still forced to trust the bad apple (the least trustworthy CA).
+Google's Certificate Transparency proposal wants certificate authorities (CAs) to publicly log all of the certificates that they issue. [It does not protect against NSA spying and MITM attacks](https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/). Website owners are then asked to monitor these logs to see if their clients were hacked. Everyone online is still forced to trust the bad apple (the least trustworthy CA).
 
 - __*Best case* scenario: mis-issuance detected _after_ damage has been done. The CA blames hackers.__
 
@@ -30,7 +30,7 @@ In our words: Convergence is similar to having a `known_hosts` ssh key file for
 
 - It is not very user friendly. Users are asked to manage a list of notaries. This list of notaries is stored locally on the computer, or even the browser. Managing this list is not feasible for most users.
 - It's not clear how well it protects (or can protect) if some notaries haven't yet cached the latest SSL certificate for a particular website.
-- It does not provide MITM protection on first-visit.
+- It does not provide MITM protection on first visit.
 - Waiting for group consensus means all connections have higher latency (slower page loads).
 - Both Convergence and Perspectives (see below) results in you sharing every website you visit with random third-parties. With DNSChain, if privacy is a concern, you can run your own server and only rely on it: it will provide both better performance and superior security.
 

docs/How-do-I-run-my-own.md

@@ -21,7 +21,7 @@ Get yourself a Linux server (they come as cheap as $2/month), and then make sure
 
 ##### Verify it runs
 
-Test DNSChain by simply running `dnschain` from the command line (developers [see here](#Working)). Have a look at the configuration section below, and when you're ready, run it in the background as a daemon. As a convenience, DNSChain [comes with a `systemd` unit file](<../scripts/dnschain.service>) that you can use to run it.
+Test DNSChain by simply running `dnschain` from the command line (developers [see here](Developers.md#Working)). Have a look at the configuration section below, and when you're ready, run it in the background as a daemon. As a convenience, DNSChain [comes with a `systemd` unit file](<../scripts/dnschain.service>) that you can use to run it.
 
 By default, it will start listening for DNS requests on port `53` if you run it as `root`, and `5333` otherwise. You can test `.bit` resolution with `dig`:
 

docs/Security-Model.md

@@ -19,7 +19,7 @@ _Note: From here on "proxy" and "DNSChain" are interchangeable._
 
 #### DNSChain's Revised Security Model
 
-DNSChain's original security model involved a trusted-proxy with a MITM-proof channel established via public key pinning.
+DNSChain's original security model involved a trusted proxy with a MITM-proof channel established via public key pinning.
 
 This technique offers significant improvement over today's HTTPS security model that relies on [X.509](https://en.wikipedia.org/wiki/X.509). However, scaling a trusted-proxy model to all Internet users is challenging since not everyone may have a trustworthy DNSChain server to connect to.
 
@@ -244,7 +244,7 @@ Same as *Mitigation* for *Stealing identifiers*.
 
 *Significance*
 
-Depends on how important it is to you where someone knows who you are communicating with and what websites you are visiting.
+Depends on how important it is to you whether someone knows who you are communicating with and what websites you are visiting.
 
 *Difficulty*
 
@@ -254,15 +254,15 @@ Low. Anyone who can act as a MITM between you and the rest of the world can see
 
 Both SPV and PoT leak information about the identifiers you are looking up.
 
-Even if you were to run a full node and conduct lookups *purely locally* a MITM could still figure out who you are communicating with and what websites you are visiting simply be monitoring the IP addresses you connect to.
+Even if you were to run a full node and conduct lookups *purely locally* a MITM could still figure out who you are communicating with and what websites you are visiting simply by monitoring the IP addresses you connect to.
 
 *Mitigation*
 
-If privacy of significant concern to you, there is no substitute for anonymizing networks like Tor. If privacy is of small but non-significant concern to you, run your own full node on a server and point you SPV/PoT thin client at it.
+If privacy is of significant concern to you, there is no substitute for anonymizing networks like Tor. If privacy is of small but non-significant concern to you, run your own full node on a server and point you SPV/PoT thin client at it.
 
 **Replay Attacks**
 
-A replay attack where outdated/expired identifier values (that actually exist in the blockchain) are sent back to the thin client.
+A replay attack is where outdated/expired identifier values (that actually exist in the blockchain) are sent back to the thin client.
 
 *Methods*
 
@@ -281,7 +281,7 @@ Small to severe, depending on nature of attack.
 *Thin Client Protocol Analysis*
 
 - SPV: Traditional SPV techniques are succeptible to this attack. New SPV modes (like those that store the UTXO set in the blockchain headers) can prevent this attack from happening but may require special support by the blockchain.
-- PoT: Clients use a [Bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) per cached **root** to efficiently memorize all of the transactions they've seen, therefore this technique is immune to relay attacks. See *Censorship* attacks for a "replay" attack that could be done through censorship (applies to SPV as well).
+- PoT: Clients use a [Bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) per cached **root** to efficiently memorize all of the transactions they've seen; therefore this technique is immune to relay attacks. See *Censorship* attacks for a "replay" attack that could be done through censorship (applies to SPV as well).
 
 *Mitigation:* Use PoT or UTXO-based SPV instead of traditional SPV.
 

docs/What-is-it.md

@@ -39,7 +39,7 @@ key becomes MITM-proof.
 - The latest and most correct key is sent to clients over the secure
 channel between DNSChain and its clients. They are then able to establish further MITM-proof connections with the owner(s) of those key(s).
 
-It's bears emphasizing that the DNSChain server itself could be malicious, and therefore users should only query the server (or _servers_) that they have good reason to trust. If they don't have access to a trustworthy DNSChain server, they should query several independently run servers and verify that the responses match.
+It bears emphasizing that the DNSChain server itself could be malicious, and therefore users should only query the server (or _servers_) that they have good reason to trust. If they don't have access to a trustworthy DNSChain server, they should query several independently run servers and verify that the responses match.
 
 __:tv: Watch: [Securing online communications with the blockchain](https://www.youtube.com/watch?v=Qy1x3Ud8LCI)__