ZIP 200: rename "auto-senescence" to "End-of-Service halt".

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

zip-0200.html

@@ -34,7 +34,7 @@ License: MIT</pre>
         </section>
         <section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
             <p>Zcash is a <em>consensual currency</em>: nobody is ever going to force someone to use a specific software implementation or a specific consensus branch of Zcash. <a id="id2" class="footnote_reference" href="#consensual-currency">2</a> As such, different sub-communities will always have the freedom to choose different variants or branches which offer different design trade-offs.</p>
-            <p>The current Zcash software includes an <em>auto-senescence</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="id3" class="footnote_reference" href="#release-lifecycle">3</a></p>
+            <p>The current Zcash software includes an <em>End-of-Service halt</em> feature, causing nodes running a particular version to automatically shut down approximately 16 weeks after that version was released (specifically, at the block height <code>DEPRECATION_HEIGHT</code> defined in the source code for that version). This was implemented for several reasons: <a id="id3" class="footnote_reference" href="#release-lifecycle">3</a></p>
             <ul>
                 <li>It gives the same systemic advantage of removing old software as auto-upgrade behavior.</li>
                 <li>It requires users to individually choose one of the following options:
@@ -62,7 +62,7 @@ License: MIT</pre>
                     <p>For removal of ambiguity, the block at height <code>ACTIVATION_HEIGHT - 1</code> is subject to the pre-upgrade consensus rules, and would be the last common block in the event of a persistent pre-upgrade consensus branch.</p>
                     <p>It MUST be greater than the value of <code>DEPRECATION_HEIGHT</code> in the last software version that will not contain support for the network upgrade. It SHOULD be chosen to be reached approximately three months after the first software version containing support for the network upgrade is released, for the following reason:</p>
                     <ul>
-                        <li>As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo auto-senescence 16 weeks after release. Thus, if version <code>X</code> contains support for a network upgrade, version <code>X-1</code> will be deprecated 10 weeks after the release of version <code>X</code>, which is about 2.3 months. A three-month window provides ample time for users to upgrade their nodes after auto-senescence, and re-integrate into the network prior to activation of the network upgrade.</li>
+                        <li>As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo End-of-Service halt 16 weeks after release. Thus, if version <code>X</code> contains support for a network upgrade, version <code>X-1</code> will be deprecated 10 weeks after the release of version <code>X</code>, which is about 2.3 months. A three-month window provides ample time for users to upgrade their nodes after End-of-Service halt, and re-integrate into the network prior to activation of the network upgrade.</li>
                     </ul>
                 </dd>
             </dl>

zip-0200.rst

@@ -54,7 +54,7 @@ implementation or a specific consensus branch of Zcash. [#consensual-currency]_
 sub-communities will always have the freedom to choose different variants or branches which offer different
 design trade-offs.
 
-The current Zcash software includes an *auto-senescence* feature, causing nodes running a particular version
+The current Zcash software includes an *End-of-Service halt* feature, causing nodes running a particular version
 to automatically shut down approximately 16 weeks after that version was released (specifically, at the block
 height ``DEPRECATION_HEIGHT`` defined in the source code for that version). This was implemented for several
 reasons: [#release-lifecycle]_
@@ -102,9 +102,9 @@ ACTIVATION_HEIGHT
   the first software version containing support for the network upgrade is released, for the following reason:
 
   - As of the time of writing (the 1.0.15 release), the release cycle is six weeks long, and nodes undergo
-    auto-senescence 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade,
+    End-of-Service halt 16 weeks after release. Thus, if version ``X`` contains support for a network upgrade,
     version ``X-1`` will be deprecated 10 weeks after the release of version ``X``, which is about 2.3 months.
-    A three-month window provides ample time for users to upgrade their nodes after auto-senescence, and
+    A three-month window provides ample time for users to upgrade their nodes after End-of-Service halt, and
     re-integrate into the network prior to activation of the network upgrade.
 
 The relationship between ``CONSENSUS_BRANCH_ID`` and ``ACTIVATION_HEIGHT`` is many-to-one: it is possible