Edited ch10.asciidoc with Atlas code editor

ch10.asciidoc

@@ -908,7 +908,7 @@ While the consensus rules are invariable in the short term and must be consisten
 
 [[hard_forks]]
 ==== Hard Forks
-((("forks", "changing consesnsus rules", id="forks10a")))((("forks", "changing consesnsus rules", "hard forks")))In <<forks>> we looked at how the bitcoin network may briefly diverge, with two parts of the network following two different branches of the blockchain for a short time. We saw how this process occurs naturally, as part of the normal operation of the network and how the network reconverges on a common blockchain after one or more blocks are mined.
+((("forks", "changing consensus rules", id="forks10a")))((("forks", "changing consesnsus rules", "hard forks")))In <<forks>> we looked at how the bitcoin network may briefly diverge, with two parts of the network following two different branches of the blockchain for a short time. We saw how this process occurs naturally, as part of the normal operation of the network and how the network reconverges on a common blockchain after one or more blocks are mined.
 
 There is another scenario in which the network may diverge into following two chains: a change in the consensus rules. This type of fork is called a _hard fork_, because after the fork the network does not reconverge onto a single chain. Instead, the two chains evolve independently. Hard forks occur when part of the network is operating under a different set of consensus rules than the rest of the network. This may occur because of a bug or because of a deliberate change in the implementation of the consensus rules.
 
@@ -968,7 +968,7 @@ Already we have seen the emergence of new methodologies to address the risks of
 
 ==== Soft Forks
 
-((("forks", "changing consensus rules", "soft forks")))Not all consensus rule changes cause a hard fork. Only consensus changes that are forward-incompatible cause a fork. If the change is implemented in such a way that an unmodified client still sees the transaction or block as valid under the previous rules, the change can happen without a fork.
+((("forks", "changing consensus rules", "soft forks")))((("soft forks", "defined")))Not all consensus rule changes cause a hard fork. Only consensus changes that are forward-incompatible cause a fork. If the change is implemented in such a way that an unmodified client still sees the transaction or block as valid under the previous rules, the change can happen without a fork.
 
 The term _soft fork_ was introduced to distinguish this upgrade method from a "hard fork." In practice, a soft fork is not a fork at all. A soft fork is a forward compatible change to the consensus rules that allows un-upgraded clients to continue to operate in consensus with the new rules.