zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 200: clarify that following a pre-upgrade branch can normally only happen if EoS halt is bypassed. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-04-14 09:19:28 +01:00
parent 79b932e841
commit ae834f371e
2 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
zip-0200.html
View File

@ -91,7 +91,7 @@ License: MIT</pre>
<p>It is possible for a reorganization to occur that rolls back from after the activation height, to before that height. This can handled in the same way as any regular chain orphaning or reorganization, as long as the new chain is valid.</p>
</section>
<section id="post-activation-upgrading"><h4><span class="section-heading">Post-activation upgrading</span><span class="section-anchor"> <a href="#post-activation-upgrading"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>If a user does not upgrade their node to a compatible software version before <code>ACTIVATION_HEIGHT</code> is reached, their node will follow any pre-upgrade consensus branch that persists, and may download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently upgrades their node to a compatible software version, the node will consider these blocks to be invalid, and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.</p>
<p>If a user does not upgrade their node to a compatible software version before <code>ACTIVATION_HEIGHT</code> is reached, their node will follow any pre-upgrade consensus branch that persists. This could normally only occur if the End-of-Service halt were bypassed. In this case it may download blocks that are incompatible with the post-upgrade consensus branch. If the user subsequently upgrades their node to a compatible software version, the node will consider these blocks to be invalid, and if there are a significant number of invalid blocks it SHOULD shut down and alert the user of the issue.</p>
</section>
</section>
<section id="memory-pool"><h3><span class="section-heading">Memory pool</span><span class="section-anchor"> <a href="#memory-pool"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>

9
zip-0200.rst
View File

@ -157,10 +157,11 @@ chain is valid.
Post-activation upgrading
`````````````````````````
If a user does not upgrade their node to a compatible software version before ``ACTIVATION_HEIGHT`` is
reached, their node will follow any pre-upgrade consensus branch that persists, and may download blocks that
are incompatible with the post-upgrade consensus branch. If the user subsequently upgrades their node to a
compatible software version, the node will consider these blocks to be invalid, and if there are a
significant number of invalid blocks it SHOULD shut down and alert the user of the issue.
reached, their node will follow any pre-upgrade consensus branch that persists. This could normally only
occur if the End-of-Service halt were bypassed. In this case it may download blocks that are incompatible
with the post-upgrade consensus branch. If the user subsequently upgrades their node to a compatible software
version, the node will consider these blocks to be invalid, and if there are a significant number of invalid
blocks it SHOULD shut down and alert the user of the issue.
Memory pool
-----------