Merge pull request #948 from daira/rendering-nits

Rendering nits and minor clarifications

rendered/zip-0231.html

@@ -18,7 +18,8 @@
 Status: Draft
 Category: Consensus / Wallet
 Created: 2024-04-26
-License: MIT</code></pre>
+License: MIT
+Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/627">https://github.com/zcash/zips/issues/627</a>&gt;</code></pre>
 <h1 id="terminology">Terminology</h1>
 <p>The key words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” in this
 document are to be interpreted as described in BCP 14 <a href="#fn1"
@@ -119,7 +120,7 @@ <h2 id="changes-to-the-zcash-protocol-specification">Changes to the
 class="math inline"><strong>n</strong><strong>p</strong></span>)
 consists of</p>
 <p><span
-class="math inline">   (leadByte⦂𝔹<sup>𝕐</sup>,d⦂𝔹<sup>[ℓ<sub>d</sub>]</sup>,rseed⦂𝔹<sup>𝕐[𝟛𝟚]</sup>,memo⦂𝔹<sup>𝕐[𝟝𝟙𝟚]</sup>)</span></p>
+class="math inline">   (leadByte ⦂ 𝔹<sup>𝕐</sup>, d ⦂ 𝔹<sup>[ℓ<sub>d</sub>]</sup>, rseed ⦂ 𝔹<sup>𝕐[𝟛𝟚]</sup>, memo ⦂ 𝔹<sup>𝕐[𝟝𝟙𝟚]</sup>)</span></p>
 </blockquote>
 <p>to</p>
 <blockquote>
@@ -130,12 +131,12 @@ <h2 id="changes-to-the-zcash-protocol-specification">Changes to the
 class="math inline"><strong>n</strong><strong>p</strong></span>)
 consists of</p>
 <p><span
-class="math inline">   (leadByte⦂𝔹<sup>𝕐</sup>,d⦂𝔹<sup>[ℓ<sub>d</sub>]</sup>,rseed⦂𝔹<sup>𝕐[𝟛𝟚]</sup>,memo⦂𝔹<sup>𝕐[𝟝𝟙𝟚]</sup>)</span></p>
+class="math inline">   (leadByte ⦂ 𝔹<sup>𝕐</sup>, d ⦂ 𝔹<sup>[ℓ<sub>d</sub>]</sup>, rseed ⦂ 𝔹<sup>𝕐[𝟛𝟚]</sup>, memo ⦂ 𝔹<sup>𝕐[𝟝𝟙𝟚]</sup>)</span></p>
 <p>Each v6-onward Sapling or Orchard note plaintext (denoted <span
 class="math inline"><strong>n</strong><strong>p</strong></span>)
 consists of</p>
 <p><span
-class="math inline">   (leadByte⦂𝔹<sup>𝕐</sup>,d⦂𝔹<sup>[ℓ<sub>d</sub>]</sup>,rseed⦂𝔹<sup>𝕐[𝟛𝟚]</sup>,K<sup>memo</sup>⦂𝔹<sup>𝕐[𝟛𝟚]</sup>)</span></p>
+class="math inline">   (leadByte ⦂ 𝔹<sup>𝕐</sup>, d ⦂ 𝔹<sup>[ℓ<sub>d</sub>]</sup>, rseed ⦂ 𝔹<sup>𝕐[𝟛𝟚]</sup>, K<sup>memo</sup> ⦂ 𝔹<sup>𝕐[𝟛𝟚]</sup>)</span></p>
 </blockquote></li>
 </ul>
 <p>In § 5.5 ‘Encodings of Note Plaintexts and Memo Fields’ <a
@@ -194,7 +195,7 @@ <h2 id="changes-to-the-zcash-protocol-specification">Changes to the
 <li><p>Change</p>
 <blockquote>
 <p>Let <span
-class="math inline"><strong>n</strong><strong>p</strong> = (leadByte,d,v,rseed,memo) </span>.</p>
+class="math inline"><strong>n</strong><strong>p</strong> = (leadByte, d, v, rseed, memo) </span>.</p>
 </blockquote>
 <p>to</p>
 <blockquote>
@@ -217,7 +218,7 @@ <h2 id="changes-to-the-zcash-protocol-specification">Changes to the
 <li><p>Change</p>
 <blockquote>
 <p>Let <span
-class="math inline"><strong>n</strong><strong>p</strong> = (leadByte,d,v,rseed,memo)</span>
+class="math inline"><strong>n</strong><strong>p</strong> = (leadByte, d, v, rseed, memo)</span>
 be the Sapling or Orchard note plaintext. <span
 class="math inline"><strong>n</strong><strong>p</strong></span> is
 encoded as defined in § 5.5 ‘Encodings of Note Plaintexts and Memo
@@ -304,14 +305,15 @@ <h2 id="memo-encryption">Memo encryption</h2>
 alternatively MAY omit this check.</p>
 <p>Each memo is padded to a multiple of 256 bytes with zeroes, and split
 into 256-byte chunks. Each memo chunk is encrypted with ChaCha20Poly1305
-[^rfc-8439] as follows:</p>
+<a href="#fn12" class="footnote-ref" id="fnref12"
+role="doc-noteref"><sup>12</sup></a> as follows:</p>
 <p><span
-class="math inline">   IETF_AEAD_CHACHA20_POLY1305(encryption_key,nonce,memo_chunk)</span></p>
+class="math inline">   IETF_AEAD_CHACHA20_POLY1305(encryption_key, nonce, memo_chunk)</span></p>
 <p>where <span
 class="math inline">nonce = I2BEOSP<sub>88</sub>(counter)||[final_chunk] </span>.</p>
-<p>This is a variant of the STREAM construction <a href="#fn12"
-class="footnote-ref" id="fnref12"
-role="doc-noteref"><sup>12</sup></a>.</p>
+<p>This is a variant of the STREAM construction <a href="#fn13"
+class="footnote-ref" id="fnref13"
+role="doc-noteref"><sup>13</sup></a>.</p>
 <ul>
 <li><span class="math inline">counter</span> is a big-endian chunk
 counter starting at zero and incrementing by one for each subsequent
@@ -449,9 +451,9 @@ <h2 id="transaction-fees">Transaction fees</h2>
 <p>(This section will become a modification to ZIP 317.)</p>
 <p>A memo bundle may contain two free chunks if there are any shielded
 outputs in the transaction. Otherwise, each memo chunk requires
-<code>marginal_fee</code> as defined in ZIP 317 <a href="#fn13"
-class="footnote-ref" id="fnref13"
-role="doc-noteref"><sup>13</sup></a>.</p>
+<code>marginal_fee</code> as defined in ZIP 317 <a href="#fn14"
+class="footnote-ref" id="fnref14"
+role="doc-noteref"><sup>14</sup></a>.</p>
 <h2 id="network-protocol">Network protocol</h2>
 <p>Nodes must reject <code>GetData</code> responses having an
 <code>fAllPruned</code> value that is nonzero, or any byte of
@@ -571,8 +573,8 @@ <h2 id="memo-key-size">Memo key size</h2>
 <p>The decrease in overhead is relatively modest in most cases, but more
 noticeable for small memos with a 256-byte memo chunk.</p>
 <p>However, 128-bit keys don’t meet Zcash’s target security level of 125
-bits, as argued in <a href="#fn14" class="footnote-ref" id="fnref14"
-role="doc-noteref"><sup>14</sup></a>.</p>
+bits, as argued in <a href="#fn15" class="footnote-ref" id="fnref15"
+role="doc-noteref"><sup>15</sup></a>.</p>
 <p>The benefits of 256-bit keys are:</p>
 <ul>
 <li>They incur only a small transaction size overhead above the minimum
@@ -599,8 +601,8 @@ <h2 id="encryption-format">Encryption format</h2>
 <ul>
 <li>It would force the transaction builder to fully define all shielded
 outputs before encrypting the memos, which might prevent potential use
-cases of PCZTs <a href="#fn15" class="footnote-ref" id="fnref15"
-role="doc-noteref"><sup>15</sup></a>.</li>
+cases of PCZTs <a href="#fn16" class="footnote-ref" id="fnref16"
+role="doc-noteref"><sup>16</sup></a>.</li>
 <li>We don’t want to unnecessarily prevent the ability to create a
 transaction with a memo bundle and no shielded outputs, as there may be
 use cases for, e.g. a fully-transparent transaction with encrypted memo,
@@ -652,79 +654,73 @@ <h2 id="transaction-fees-1">Transaction fees</h2>
 <h1 id="reference-implementation">Reference implementation</h1>
 <p>TBD</p>
 <h1 id="references">References</h1>
-<p>[^rfc-8439] <a href="https://www.rfc-editor.org/rfc/rfc8439.html">RFC
-8439: ChaCha20 and Poly1305 for IETF Protocols</a></p>
-<section class="footnotes footnotes-end-of-document"
+<section id="footnotes" class="footnotes footnotes-end-of-document"
 role="doc-endnotes">
 <hr />
 <ol>
-<li id="fn1" role="doc-endnote"><p><a
+<li id="fn1"><p><a
 href="https://www.rfc-editor.org/info/bcp14">Information on BCP 14 —
 “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels” and
 “RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
 Words”</a><a href="#fnref1" class="footnote-back"
 role="doc-backlink">↩︎</a></p></li>
-<li id="fn2" role="doc-endnote"><p><a href="protocol/protocol.pdf">Zcash
-Protocol Specification, Version 2024.5.1 [NU6] or later</a><a
-href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn3" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#noteptconcept">Zcash Protocol Specification,
-Version 2024.5.1 [NU6]. Section 3.2.1: Note Plaintexts and Memo
-Fields</a><a href="#fnref3" class="footnote-back"
+<li id="fn2"><p><a href="protocol/protocol.pdf">Zcash Protocol
+Specification, Version 2024.5.1 [NU6] or later</a><a href="#fnref2"
+class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn3"><p><a href="protocol/protocol.pdf#noteptconcept">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2.1: Note
+Plaintexts and Memo Fields</a><a href="#fnref3" class="footnote-back"
+role="doc-backlink">↩︎</a></p></li>
+<li id="fn4"><p><a href="zip-0307">ZIP 307: Light Client Protocol
+for Payment Detection</a><a href="#fnref4" class="footnote-back"
 role="doc-backlink">↩︎</a></p></li>
-<li id="fn4" role="doc-endnote"><p><a href="zip-0307">ZIP 307: Light
-Client Protocol for Payment Detection</a><a href="#fnref4"
+<li id="fn5"><p><a href="protocol/protocol.pdf#noteptencoding">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 5.5: Encodings
+of Note Plaintexts and Memo Fields</a><a href="#fnref5"
 class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn5" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#noteptencoding">Zcash Protocol
-Specification, Version 2024.5.1 [NU6]. Section 5.5: Encodings of Note
-Plaintexts and Memo Fields</a><a href="#fnref5" class="footnote-back"
+<li id="fn6"><p><a href="protocol/protocol.pdf#saplingsend">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 4.7.2: Sending
+Notes (Sapling)</a><a href="#fnref6" class="footnote-back"
+role="doc-backlink">↩︎</a></p></li>
+<li id="fn7"><p><a href="protocol/protocol.pdf#orchardsend">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 4.7.3: Sending
+Notes (Orchard)</a><a href="#fnref7" class="footnote-back"
 role="doc-backlink">↩︎</a></p></li>
-<li id="fn6" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#saplingsend">Zcash Protocol Specification,
-Version 2024.5.1 [NU6]. Section 4.7.2: Sending Notes (Sapling)</a><a
-href="#fnref6" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn7" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#orchardsend">Zcash Protocol Specification,
-Version 2024.5.1 [NU6]. Section 4.7.3: Sending Notes (Orchard)</a><a
-href="#fnref7" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn8" role="doc-endnote"><p><a
+<li id="fn8"><p><a
 href="protocol/protocol.pdf#saplingandorchardinband">Zcash Protocol
 Specification, Version 2024.5.1 [NU6]. Section 4.20.1: Encryption
 (Sapling and Orchard)</a><a href="#fnref8" class="footnote-back"
 role="doc-backlink">↩︎</a></p></li>
-<li id="fn9" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#decryptivk">Zcash Protocol Specification,
-Version 2024.5.1 [NU6]. Section 4.20.2: Decryption using an Incoming
-Viewing Key (Sapling and Orchard)</a><a href="#fnref9"
-class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn10" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#decryptovk">Zcash Protocol Specification,
-Version 2024.5.1 [NU6]. Section 4.20.3: Decryption using a Full Viewing
-Key (Sapling and Orchard)</a><a href="#fnref10" class="footnote-back"
-role="doc-backlink">↩︎</a></p></li>
-<li id="fn11" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#abstractprfs">Zcash Protocol Specification,
-Version 2024.5.1 [NU6]. Section 4.1.2: Pseudo Random Functions</a><a
-href="#fnref11" class="footnote-back"
+<li id="fn9"><p><a href="protocol/protocol.pdf#decryptivk">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 4.20.2:
+Decryption using an Incoming Viewing Key (Sapling and Orchard)</a><a
+href="#fnref9" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn10"><p><a href="protocol/protocol.pdf#decryptovk">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 4.20.3:
+Decryption using a Full Viewing Key (Sapling and Orchard)</a><a
+href="#fnref10" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn11"><p><a href="protocol/protocol.pdf#abstractprfs">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.2: Pseudo
+Random Functions</a><a href="#fnref11" class="footnote-back"
 role="doc-backlink">↩︎</a></p></li>
-<li id="fn12" role="doc-endnote"><p><a
-href="https://eprint.iacr.org/2015/189">Online Authenticated-Encryption
-and its Nonce-Reuse Misuse-Resistance</a><a href="#fnref12"
+<li id="fn12"><p><a
+href="https://www.rfc-editor.org/rfc/rfc8439.html">RFC 8439: ChaCha20
+and Poly1305 for IETF Protocols</a><a href="#fnref12"
 class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn13" role="doc-endnote"><p><a href="zip-0317">ZIP 317:
-Proportional Transfer Fee Mechanism</a><a href="#fnref13"
-class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn14" role="doc-endnote"><p><a
-href="protocol/protocol.pdf#inbandrationale">Zcash Protocol
-Specification, Version 2024.5.1 [NU6]. Section 8.7: In-band secret
-distribution</a><a href="#fnref14" class="footnote-back"
+<li id="fn13"><p><a href="https://eprint.iacr.org/2015/189">Online
+Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance</a><a
+href="#fnref13" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn14"><p><a href="zip-0317">ZIP 317: Proportional Transfer
+Fee Mechanism</a><a href="#fnref14" class="footnote-back"
+role="doc-backlink">↩︎</a></p></li>
+<li id="fn15"><p><a href="protocol/protocol.pdf#inbandrationale">Zcash
+Protocol Specification, Version 2024.5.1 [NU6]. Section 8.7: In-band
+secret distribution</a><a href="#fnref15" class="footnote-back"
 role="doc-backlink">↩︎</a></p></li>
-<li id="fn15" role="doc-endnote"><p><a
+<li id="fn16"><p><a
 href="https://github.com/zcash/zips/issues/693">zcash/zips issue #693:
 Standardize a protocol for creating shielded transactions offline</a><a
-href="#fnref15" class="footnote-back"
-role="doc-backlink">↩︎</a></p></li>
+href="#fnref16" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
 </ol>
 </section>
 </body>

rendered/zip-0233.html

@@ -19,7 +19,8 @@
 Status: Draft
 Category: Consensus / Ecosystem
 Created: 2023-08-16
-License: BSD-2-Clause</code></pre>
+License: BSD-2-Clause
+Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/922">https://github.com/zcash/zips/issues/922</a>&gt;</code></pre>
 <h1 id="terminology">Terminology</h1>
 <p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”,
 “OPTIONAL”, and “REQUIRED” in this document are to be interpreted as
@@ -70,12 +71,12 @@ <h1 id="specification">Specification</h1>
 </ol>
 <h2 id="transaction-format">Transaction Format</h2>
 <p>The following field is added to the v6 transaction format [3]:</p>
-<table>
+<table style="width:98%;">
 <colgroup>
 <col style="width: 8%" />
-<col style="width: 18%" />
+<col style="width: 17%" />
 <col style="width: 13%" />
-<col style="width: 59%" />
+<col style="width: 57%" />
 </colgroup>
 <thead>
 <tr class="header">

rendered/zip-0235.html

@@ -19,7 +19,8 @@
 Status: Draft
 Category: Ecosystem
 Created: 2023-09-21
-License: BSD-2-Clause</code></pre>
+License: BSD-2-Clause
+Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/924">https://github.com/zcash/zips/issues/924</a>&gt;</code></pre>
 <h1 id="terminology">Terminology</h1>
 <p>The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”,
 “OPTIONAL”, and “REQUIRED” in this document are to be interpreted as

rendered/zip-0316.html

@@ -836,8 +836,15 @@
             </section>
         </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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
-            <p>Revision 0: * <a href="https://github.com/zcash/librustzcash/pull/352">https://github.com/zcash/librustzcash/pull/352</a> * <a href="https://github.com/zcash/librustzcash/pull/416">https://github.com/zcash/librustzcash/pull/416</a></p>
-            <p>Revision 1: * <a href="https://github.com/zcash/librustzcash/pull/1135">https://github.com/zcash/librustzcash/pull/1135</a></p>
+            <p>Revision 0:</p>
+            <ul>
+                <li><a href="https://github.com/zcash/librustzcash/pull/352">https://github.com/zcash/librustzcash/pull/352</a></li>
+                <li><a href="https://github.com/zcash/librustzcash/pull/416">https://github.com/zcash/librustzcash/pull/416</a></li>
+            </ul>
+            <p>Revision 1:</p>
+            <ul>
+                <li><a href="https://github.com/zcash/librustzcash/pull/1135">https://github.com/zcash/librustzcash/pull/1135</a></li>
+            </ul>
         </section>
         <section id="acknowledgements"><h2><span class="section-heading">Acknowledgements</span><span class="section-anchor"> <a rel="bookmark" href="#acknowledgements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
             <p>The authors would like to thank Benjamin Winston, Zooko Wilcox, Francisco Gindre, Marshall Gaucher, Joseph Van Geffen, Brad Miller, Deirdre Connolly, Teor, Eran Tromer, Conrado Gouvêa, and Marek Bielik for discussions on the subject of Unified Addresses and Unified Viewing Keys.</p>