ZIP 202: fix link.

This should also republish GitHub Pages after renaming the `master` branch to `main`.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-09-09 15:29:09 +01:00
parent 2630966bc4
commit f4cb2806a7
2 changed files with 7 additions and 11 deletions

View File

@ -218,11 +218,7 @@ License: MIT</pre>
<li>begins with little-endian byte sequence [0x01, 0x00, 0x00, 0x00];</li>
<li>deserialized as 32-bit signed integer with decimal value of 1.</li>
</ul>
<p>Version 2 transaction (txid <a id="id9" class="problematic" href="#id8">`</a>4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b &lt;<a href="https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b">https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b</a>&gt;)</p>
<div id="id8">
<h1>System Message: WARNING/2 (zip-0202.rst line 110) <a href="#id9">id9</a></h1>
<p>Inline interpreted text or phrase reference start-string without end-string.</p>
</div>
<p>Version 2 transaction (txid <a href="https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b">4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b</a>)</p>
<ul>
<li>begins with little-endian byte sequence [0x02, 0x00, 0x00, 0x00];</li>
<li>deserialized as 32-bit signed integer with decimal value of 2.</li>
@ -272,7 +268,7 @@ License: MIT</pre>
<p>However, if a new transaction version can be correctly parsed according to the format of a preceding version (that is, it only restricts the format, or defines fields that were previously reserved and which old parsers can safely ignore), then the same version group ID MAY be re-used.</p>
</section>
<section id="expiry-height"><h3><span class="section-heading">Expiry Height</span><span class="section-anchor"> <a rel="bookmark" href="#expiry-height"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="id10" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
<p>The expiry height field, as defined in the Transaction Expiry ZIP <a id="id8" class="footnote_reference" href="#zip-0203">5</a>, stores the block height after which a transaction can no longer be mined.</p>
</section>
<section id="transaction-validation"><h3><span class="section-heading">Transaction Validation</span><span class="section-anchor"> <a rel="bookmark" href="#transaction-validation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A valid Overwinter transaction intended for Zcash MUST have:</p>
@ -287,7 +283,7 @@ License: MIT</pre>
<li>the version group ID is unknown; or</li>
<li>the version number is unknown.</li>
</ul>
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id11" class="footnote_reference" href="#zip-0143">2</a>.</p>
<p>Validation of version 3 transactions MUST use the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id9" class="footnote_reference" href="#zip-0143">2</a>.</p>
</section>
</section>
<section id="implementation"><h2><span class="section-heading">Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
@ -321,14 +317,14 @@ License: MIT</pre>
}</pre>
<p>It is expected that this test involving <code>nVersionGroupId</code> is only required when a transaction is being constructed or deserialized e.g. when an external transaction enters the system.</p>
<p>However, it's possible that a clone of Zcash is using the same version group ID and passes the conditional.</p>
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id12" class="footnote_reference" href="#zip-0143">2</a>.</p>
<p>Ultimately, a client can determine if a transaction is truly intended for the client's chain or not by following the signature validation process detailed in the Transaction Signature Validation for Overwinter ZIP <a id="id10" class="footnote_reference" href="#zip-0143">2</a>.</p>
</section>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="id13" class="footnote_reference" href="#zip-0201">4</a>.</p>
<p>This proposal will be deployed with the Overwinter network upgrade. The activation block height proposal is in <a id="id11" class="footnote_reference" href="#zip-0201">4</a>.</p>
</section>
<section id="backwards-compatibility"><h2><span class="section-heading">Backwards compatibility</span><span class="section-anchor"> <a rel="bookmark" href="#backwards-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" <a id="id14" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
<p>This proposal intentionally creates what is known as a "bilateral consensus rule change" <a id="id12" class="footnote_reference" href="#zip-0200">3</a> between pre-Overwinter software and Overwinter-compatible software. Use of this new transaction format requires that all network participants upgrade their software to a compatible version within the upgrade window. Pre-Overwinter software will treat Overwinter transactions as invalid.</p>
<p>Once Overwinter has activated, Overwinter-compatible software will reject version 1 and version 2 transactions, and will only accept transactions based upon supported transaction version numbers and recognized version group IDs.</p>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>

View File

@ -107,7 +107,7 @@ Version 1 transaction (txid `5c6ba844e1ca1c8083cd53e29971bd82f1f9eea1f86c1763a22
* begins with little-endian byte sequence [0x01, 0x00, 0x00, 0x00];
* deserialized as 32-bit signed integer with decimal value of 1.
Version 2 transaction (txid `4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b <https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b>)
Version 2 transaction (txid `4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b <https://blockchair.com/zcash/transaction/4435bf8064e74f01262cb1725fd9b53e600fa285950163fd961bed3a64260d8b>`_)
* begins with little-endian byte sequence [0x02, 0x00, 0x00, 0x00];
* deserialized as 32-bit signed integer with decimal value of 2.