"branch" -> "consensus branch"

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-03-16 19:52:48 +00:00
parent 0bd85486fe
commit 1f77e08d4f
4 changed files with 7 additions and 7 deletions

View File

@ -17,7 +17,7 @@ License: MIT</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.9 and 7.7 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol-subsidyconcepts">3</a> <a id="id3" class="footnote_reference" href="#protocol-subsidies">5</a></p>
<p>The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">8</a></p>
<p>The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. <a id="id4" class="footnote_reference" href="#zip-0200">8</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>${NU4}</dt>
@ -341,7 +341,7 @@ Address(height) = FundingStream[FUND].Addresses[FundingStream[FUND].AddressIndex
<p>This proposal is intended to be deployed with ${NU4}. <a id="id20" class="footnote_reference" href="#zip-0251">12</a></p>
</section>
<section id="backward-compatibility"><h2><span class="section-heading">Backward compatibility</span><span class="section-anchor"> <a href="#backward-compatibility"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade branch that persists.</p>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBC</p>

View File

@ -20,8 +20,8 @@ The terms "block subsidy" and "halving" in this document are to be interpreted
as described in sections 3.9 and 7.7 of the Zcash Protocol Specification.
[#protocol-subsidyconcepts]_ [#protocol-subsidies]_
The terms "branch" and "network upgrade" in this document are to be interpreted as
described in ZIP 200. [#zip-0200]_
The terms "consensus branch" and "network upgrade" in this document are to be
interpreted as described in ZIP 200. [#zip-0200]_
The terms below are to be interpreted as follows:
@ -365,7 +365,7 @@ This proposal intentionally creates what is known as a "bilateral consensus
rule change". Use of this mechanism requires that all network participants
upgrade their software to a compatible version within the upgrade window.
Older software will treat post-upgrade blocks as invalid, and will follow any
pre-upgrade branch that persists.
pre-upgrade consensus branch that persists.
Reference Implementation

View File

@ -43,7 +43,7 @@ License: MIT</pre>
<p>The network handshake and peer management mechanisms defined in ZIP 201 <a id="id10" class="footnote_reference" href="#zip-0201">4</a> also apply to this upgrade.</p>
<p>The following network upgrade constants <a id="id11" class="footnote_reference" href="#zip-0200">3</a> are defined for the ${NU4} upgrade:</p>
<dl>
<dt>BRANCH_ID</dt>
<dt>CONSENSUS_BRANCH_ID</dt>
<dd><code>0xTODO</code></dd>
<dt>ACTIVATION_HEIGHT (${NU4})</dt>
<dd>

View File

@ -56,7 +56,7 @@ also apply to this upgrade.
The following network upgrade constants [#zip-0200]_ are defined for the ${NU4}
upgrade:
BRANCH_ID
CONSENSUS_BRANCH_ID
``0xTODO``