Fix typos and misspellings

Author: nkryuchkov

atx.md

@@ -2,7 +2,7 @@
 
 Miners become eligible to mine in Spacemesh by publishing an Activation Transaction (ATX). The ATX is a Spacemesh-specific data structure that contains a [NIPoST](04-nipost.md), a publicly verifiable, self-contained proof that the miner committed some space-time resources to the protocol.
 
-The previous documents in this section describe the _theory_ behind a set of independent protocols (PoST, PoET, NIPoST) that form the foundation of the Spacemesh mining construction. With ths background in place, we are now ready to see how these building block fit together _in practice_ to enable the Spacemesh mining construction in the production network. In particular, we'll see how the NIPoST (which itself contains the PoST and PoET) is wrapped, with accompanying metadata, into an ATX and used in the Spacemesh protocol.
+The previous documents in this section describe the _theory_ behind a set of independent protocols (PoST, PoET, NIPoST) that form the foundation of the Spacemesh mining construction. With this background in place, we are now ready to see how these building blocks fit together _in practice_ to enable the Spacemesh mining construction in the production network. In particular, we'll see how the NIPoST (which itself contains the PoST and PoET) is wrapped, with accompanying metadata, into an ATX and used in the Spacemesh protocol.
 
 
 ## Epochs and eligibility

consensus_deepdive.md

@@ -44,7 +44,7 @@ Blockchains based on Nakamoto consensus, such as Bitcoin, also have this "self-h
 
 In a PBFT-style system, such as those based on HotStuff BFT, losing consensus in this manner might mean that different participants have a different view on which transactions are confirmed. Self-healing ensures that this cannot happen in Spacemesh.
 
-Another important difference between the Tortoise and a BFT-style protocol is that the Tortoise is capable of a more robust form of consensus: even if assumptions fail for a while, things that have been in consensus for a while remain in consensus. Contrast this wih a BFT-style protocol, where you cannot rely on history in such a scenario, since it can be reversed.
+Another important difference between the Tortoise and a BFT-style protocol is that the Tortoise is capable of a more robust form of consensus: even if assumptions fail for a while, things that have been in consensus for a while remain in consensus. Contrast this with a BFT-style protocol, where you cannot rely on history in such a scenario, since it can be reversed.
 
 ## Hare
 
@@ -69,7 +69,7 @@ In the case of a network partition or attack, the Hare protocol may cease to wor
 
 ### Compared to HotStuff and Tendermint
 
-- [HotStuff](https://arxiv.org/pdf/1803.05069.pdf) requires a known set of participants (i.e., it does not support player replaceability), cannot be made permissionless, doesn't scale to thousands of participants, and does not easily convert to set agreement (i.e., agreement on a set of valus rather than on a single bit value). The requirement to have a known set of participants opens a DoS attack vector on known future participants.
+- [HotStuff](https://arxiv.org/pdf/1803.05069.pdf) requires a known set of participants (i.e., it does not support player replaceability), cannot be made permissionless, doesn't scale to thousands of participants, and does not easily convert to set agreement (i.e., agreement on a set of values rather than on a single bit value). The requirement to have a known set of participants opens a DoS attack vector on known future participants.
 - HotStuff and Tendermint make different assumptions about network synchrony: they both assume a _partially-synchronous network_ (i.e., there exists a "global stabilization time" after which all messages may be assumed to have been delivered, but you don't know exactly when this time is). The Hare, on the other hand, assumes a _fully-synchronous network,_ i.e., that all messages are delivered within a known period of time (which is specified as a protocol parameter, and affects layer time). As a result, HotStuff and Tendermint can make progress faster than Hare, but at the cost of having a lower corruption threshold: HotStuff and Tendermint both require a 2/3 honest majority, whereas the Hare requires only a simple honest majority.
 - HotStuff and Tendermint achieve a form of consensus known as _state machine replication_ (SMR): this is a classical form of PBFT consensus where participants in the protocol agree upon an ordered sequence of transactions. The Hare protocol plays a different role in Spacemesh, and thus its goal is not to achieve SMR-style consensus. Rather, every time the Hare runs, its goal is to run for a finite number of rounds and achieve a "one-time agreement" on the set of valid blocks in the current layer, then terminate. Terminating an SMR-style consensus protocol is more difficult since it's unclear how to ensure that all participants have achieved precisely the same state—indeed, these protocols are designed to run through an indefinite number of rounds.
 

consensus_overview.md

@@ -120,7 +120,7 @@ When the node proposes a block in the future, it uses the output of the Hare, an
 
 At the beginning of each round (rounds 0-4, as described in the following section), a miner draws a role that tells it whether it's _active_ (i.e., participating) or _passive_ (i.e., just observing) in this round. In order to draw a role, each miner uses a [Verifiable Random Function (VRF)](https://en.wikipedia.org/wiki/Verifiable_random_function) and if the output passes some threshold (which depends on the number of total active miners) then it is active; otherwise the miner is passive for that round.
 
-Miners change roles from round to round in order to prevent denial-of-service attacks against the Hare. If a miner kept the same role thoughout all of the rounds, then, after revealing their role in an earlier round, they could be targeted by an attack in subsequent rounds.
+Miners change roles from round to round in order to prevent denial-of-service attacks against the Hare. If a miner kept the same role throughout all of the rounds, then, after revealing their role in an earlier round, they could be targeted by an attack in subsequent rounds.
 
 In round two (proposal round), a leader (with the ability to broadcast a proposal) is chosen. This also happens using a VRF, but as opposed to the assignment of active/passive roles as described above, even if a miner passes the required threshold before this round and subsequently sends a proposal, that miner is still not certain that it's the actual leader (since another miner may have drawn a lower number). There is, actually, just one leader, the one with the smallest VRF output, but this isn't known with certainty until the _end_ of the round.
 

hare_FAQ.md

@@ -36,7 +36,7 @@ Q:  Round 2: is the `notify message` sent to the whole network via gossip?
 
 Q: Round 2: what is `equivocation` - it is not previously defined. Please define.. what does it mean to detect and equivocation?
 
-A: Equivocation, generally means that someone tried to present more than one truth. Specifically itis used to describe a malicious leader that sends more than one proposal to the network - that is called leader equivocation or proposal equivocation. This behavior can be broaden to other message types, for example pre-round messages.
+A: Equivocation, generally means that someone tried to present more than one truth. Specifically it is used to describe a malicious leader that sends more than one proposal to the network - that is called leader equivocation or proposal equivocation. This behavior can be broaden to other message types, for example pre-round messages.
 
 ---
 

hare_README.md

@@ -7,7 +7,7 @@ The general problem is the [Byzantine Agreement Problem](https://en.wikipedia.or
 
 It is known in advance when an agreement process should start for each layer. On the other hand, the time it takes to achieve agreement can vary, depending on the number of faulty/malicious participants in the consensus. Hence, multiple consensus instances may be run concurrently.  
 
-On this page we will discuss the core protocol concepts and clarify it. Please note we do not intend to talk about the implementation itself, we might mention practical ways that overlap with it.
+On this page we will discuss the core protocol concepts and clarify them. Please note we do not intend to talk about the implementation itself, we might mention practical ways that overlap with it.
 
 ## Definitions
 `N` - The number of active participants
@@ -54,7 +54,7 @@ Type B - assumes an honest has already committed. From this moment, we know ther
 **Pre-Round**
 The protocol begins with one `pre-round`. This round is executed only once and its goal is to remove values which shouldn't be considered at all according to `Validity 2`
 - At the beginning of the pre-round each active party sends his set of values ISi
-- At the end of the pre-round, each value that hasn't received f+1 witnesses is removed. This ensures that we are left only with values that has at least one honest witness and therefore satisfying `validity 2`
+- At the end of the pre-round, each value that hasn't received f+1 witnesses is removed. This ensures that we are left only with values that have at least one honest witness and therefore satisfying `validity 2`
 
 The protocol repeatedly iterates through up to 4 rounds until a consensus is reached.
 
@@ -76,18 +76,18 @@ Note: we say candidate (opposed to accepted) since it is possible that the sende
 Note: accepted proposals must have been received no later than the end of the proposal round. Hence, any accepted proposal will arrive to all honest participants no later than this commit round and that is why we are ensured to detect equivocation.
 
 **Notify Round**
-- An (active) participant that were able to form a certificate at the end of the commit round, broadcasts a notify message which includes (S, k, ki, C(S, k))
+- An (active) participant that was able to form a certificate at the end of the commit round, broadcasts a notify message which includes (S, k, ki, C(S, k))
 - Upon receiving a valid notify message the participant updates his internal state according to the attached set
 
 **Termination**
 If at any point of the protocol, a participant P receives f+1 notify messages on the same set S, it commits to S and terminates.
-Note: it is hereby follows that all honest participants will receive f+1 notifications no later than the following round and hence will terminate also.
+Note: it hereby follows that all honest participants will receive f+1 notifications no later than the following round and hence will terminate also.
 
 ## Eligibility Oracle
 
 Eligibility to participate in a round (being active) is determined by the oracle mechanism.
 The oracle is required to provide three main properties:
-A. Eligibility is under consensus - meaning all honest participant who receive a message will either classify it as active or as passive.
+A. Eligibility is under consensus - meaning all honest participants who receive a message will either classify it as active or as passive.
 B. The eligibility can be calculated in advance only up to some configurable limit of time before it can be used to participate.
 C. Eligibility is determined for each round in a layer separately and at random.
 
@@ -104,7 +104,7 @@ The reason we use a VRF signature is that we want to make sure the signing proce
 **Validation**
 In order to validate the vrf message the receiver should:
 1. Reconstruct the matching VRF message and check the signature against that message.
-2. Validate the the hash of signature of the VRF message passes the threshold.
+2. Validate the hash of signature of the VRF message passes the threshold.
 
 **Leadership**
 The leader eligibility is derived by the same process described above. The only difference is that the expected number of actives is set to 1. Since eligibility is random, it is possible that more than one leader will exist in the same (proposal) round. To handle this, we agree on a way to order the signatures in order to decide who is the real accepted leader. For example, this can be done by comparing bytes and accepting lowest ranked leader.
@@ -144,7 +144,7 @@ Validations:
 * validate all messages are of type status
 * validate all (status) messages state the same iteration number
 * uniqueness of sender across all commit messages
-* for each status messsages(S, K , Ki):
+* for each status messages (S, K , Ki):
     - if ki > 0 look for a certificate on (S,K)
     - if ki = -1 prove by preround messages
 * Validate SVP type:

mining_overview.md

@@ -13,7 +13,7 @@ Several strategies have been suggested for defending against such an attack (oft
 
 Any bounded resource can be used as a “payment” for the eligibility to mine. This “payment” isn’t paid to anyone, it is simply wasted or “burnt.” Its purpose is to prevent Sybil attacks, and thus to make the honest majority security assumption viable. That majority can be used by nodes on the network to reach consensus regarding the canonical list of transactions. It thus[ solves](https://satoshi.nakamotoinstitute.org/emails/cryptography/11/#selection-47.45-47.72) a classic problem in distributed computing called the [Byzantine Generals Problem](https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf), even among a permissionless, changing set of actors, and was first introduced by Satoshi Nakamoto with the inception of Bitcoin.
 
-In order to incentivise miners to spend that resource, essential to the security of the network, miners are rewarded with newly minted tokens. This kills two birds with one stone: the initial distribution of tokens into circulation, and the incentive for nodes to support the security of the network.
+In order to incentivize miners to spend that resource, essential to the security of the network, miners are rewarded with newly minted tokens. This kills two birds with one stone: the initial distribution of tokens into circulation, and the incentive for nodes to support the security of the network.
 
 ## Proof of Work
 

p2p_overview.md

@@ -85,7 +85,7 @@ As [described above](#discovery), a peer performs an initial discovery process,
 The following flow describes how a node requests a list of peers from another node:
 
 1. The initiator must first send ping message, to verify that node is alive. The ping contains the node ID (public key), the sender's IP and port.
-1. The recipient responds to the ping with a pong message, of the same format as the ping, to validate this information. (In other words, the recipient ensures the intiator is indeed listening at the IP and port they advertised. This prevents reflective DoS attacks.)
+1. The recipient responds to the ping with a pong message, of the same format as the ping, to validate this information. (In other words, the recipient ensures the initiator is indeed listening at the IP and port they advertised. This prevents reflective DoS attacks.)
 1. The initiator then sends a `getAddresses` message, requesting a list of peers.
 1. The recipient responds with a list of additional peers: their node IDs, IP addresses, and ports.
 
@@ -95,4 +95,4 @@ Each node maintains an "address book" of known nodes. When it first starts up, o
 
 When two nodes connect for the first time, a secure P2P session needs to be established (using a TCP socket). To establish the session the initiator node first generates a handshake message containing its client version and the network ID it's trying to connect to. It then encrypts the message using a [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) shared secret key constructed using its own private key and the recipient's public key. It sends the message, and its public key, to the recipient.
 
-The recipient reconstucts the shared secret key, using its private key and the initator's public key, uses it to decrypt the handshake message, and checks the initiator's client version and network ID. If everything checks out, it responds to the handshake message and a session is established; if not, the TCP connection is closed and no further information is exchanged.
+The recipient reconstructs the shared secret key, using its private key and the initiator's public key, uses it to decrypt the handshake message, and checks the initiator's client version and network ID. If everything checks out, it responds to the handshake message and a session is established; if not, the TCP connection is closed and no further information is exchanged.