Merge 31fa493afb into 5273fc9c99

Bump actions/checkout from 4.1.1 to 4.1.2

.github/actions/render-protocol-pdf/Dockerfile

@@ -1 +0,0 @@
-../../../Dockerfile

.github/actions/render-protocol-pdf/action.yml

@@ -1,7 +0,0 @@
-name: Render Zcash Protocol Specification
-description: GitHub Action to compile Zcash Protocol Specification LaTeX documents
-author: Deirdre Connolly
-runs:
-  using: docker
-  # Runs `make all` or something like it
-  image: Dockerfile

.github/actions/render/action.yml

@@ -0,0 +1,7 @@
+name: Render ZIPs and Zcash Protocol Specification
+description: GitHub Action to compile ZIPs and Zcash Protocol Specification LaTeX documents
+author: Deirdre Connolly
+runs:
+  using: docker
+  # Runs `make all` or something like it
+  image: ../../../Dockerfile

.github/workflows/render.yml

@@ -1,19 +1,23 @@
-name: Render pdfs
+name: Build tex and rst
 
-on: workflow_dispatch
+on: 
+  workflow_dispatch:
+  push:
+    branches:
+    - main
 
 jobs:
 
   render:
     runs-on: ubuntu-latest
     steps:
-      - name: Set up Git repository
-        uses: actions/checkout@v4.1.1
+      - name: Checkout repository
+        uses: actions/checkout@v4.1.2
 
-      - name: Compile Zcash Protocol Specification
-        uses: ./.github/actions/render-protocol-pdf
+      - name: Compile ZIPs and Zcash Protocol Specification
+        uses: ./.github/actions/render
 
       - uses: EndBug/add-and-commit@v9.1.3
         with:
-          add: '**/*.pdf'
+          add: 'protocol/*.pdf *.html'
           default_author: github_actions

Dockerfile

@@ -1,7 +1,7 @@
 FROM debian:latest
 
-RUN apt-get update \
-        && apt-get install -y \
+RUN apt-get update
+RUN apt-get install -y \
         gawk \
         perl \
         sed \
@@ -17,7 +17,10 @@ RUN apt-get update \
         texlive-plain-generic \
         texlive-bibtex-extra
 
-RUN pip3 install rst2html5
+RUN rm /usr/lib/python3.11/EXTERNALLY-MANAGED
+RUN pip install rst2html5
+
+ENV PATH=${PATH}:/root/.local/bin
 
 WORKDIR "/zips"
 ENTRYPOINT ["make", "all"]

zip-0316.html

@@ -174,6 +174,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
                     <li><em>prefix</em> || “<code>view</code>” for Unified Full Viewing Keys on Mainnet;</li>
                     <li><em>prefix</em> || “<code>viewtest</code>” for Unified Full Viewing Keys on Testnet.</li>
                 </ul>
+                <p>While support for Revision 1 UAs/UVKs is still being rolled out across the Zcash ecosystem, a Producer can maximize interoperability by generating a Revision 0 UA/UVK in cases where the conditions on its use are met (i.e. there are no MUST-understand Metadata Items, and at least one shielded item). At some point when Revision 1 UA/UVKs are widely supported, this will be unnecessary and it will be sufficient to always produce Revision 1 UA/UVKs.</p>
             </section>
             <section id="encoding-of-unified-addresses"><h3><span class="section-heading">Encoding of Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#encoding-of-unified-addresses"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
                 <p>Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future.</p>
@@ -666,16 +667,40 @@ c^{n+m}}{q}.\)</span>
                     <p>In order to prevent the generic attack against nonmalleability, there needs to be some redundancy in the encoding. Therefore, the Producer of a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with zero bytes, to the raw encoding, then applies
                         <span class="math">\(\mathsf{F4Jumble}\)</span>
                      before encoding the result with Bech32m.</p>
-                    <p>The Consumer rejects any Bech32m-decoded byte sequence that is less than 48 bytes or greater than
+                    <p>The Consumer rejects any Bech32m-decoded byte sequence that is less than 40 bytes or greater than
                         <span class="math">\(\ell^\mathsf{MAX}_M\)</span>
                      bytes; otherwise it applies
                         <span class="math">\(\mathsf{F4Jumble}^{-1}.\)</span>
                      It rejects any result that does not end in the expected 16-byte padding, before stripping these 16 bytes and parsing the result.</p>
-                    <p>(48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item encoding to be 32 bytes, taking into account 16 bytes of padding. Although there is currently no shielded Item encoding that short, it is plausible that one might be added in future.
+                </section>
+                <section id="rationale-for-length-restrictions"><h4><span class="section-heading">Rationale for length restrictions</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-length-restrictions"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
+                    <p>A minimum input length to
+                        <span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
+                     of 40 bytes allows for the minimum size of a UA/UVK Item encoding to be 24 bytes including the typecode and length, taking into account 16 bytes of padding. This allows for a UA containing only a Transparent P2PKH Receiver and any Metadata Item:</p>
+                    <ul>
+                        <li>Transparent P2PKH Receiver Item:
+                            <ul>
+                                <li>1-byte typecode</li>
+                                <li>1-byte encoding of length</li>
+                                <li>20-byte transparent address hash</li>
+                            </ul>
+                        </li>
+                        <li>Metadata Item:
+                            <ul>
+                                <li>1-byte typecode</li>
+                                <li>1-byte encoding of length</li>
+                                <li>metadata encoding, potentially 0-length for future Metadata Items</li>
+                            </ul>
+                        </li>
+                    </ul>
+                    <p>
                         <span class="math">\(\ell^\mathsf{MAX}_M\)</span>
                      bytes is the largest input/output size supported by
                         <span class="math">\(\mathsf{F4Jumble}.\)</span>
-                    )</p>
+                    </p>
+                    <p>Note that Revision 0 of this ZIP specified a minimum input length to
+                        <span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
+                     of 48 bytes. Since there were no sets of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence of length between 40 and 47 bytes inclusive could be parsed, the difference between the 40 and 48-byte restrictions is not observable, other than potentially affecting which error is reported. A Consumer supporting Revision 1 of this specification MAY therefore apply either the 48-byte or 40-byte minimum to Revision 0 UA/UVKs.</p>
                 </section>
                 <section id="heuristic-analysis"><h4><span class="section-heading">Heuristic analysis</span><span class="section-anchor"> <a rel="bookmark" href="#heuristic-analysis"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
                     <p>A 3-round unkeyed Feistel, as shown, is not sufficient:</p>
@@ -751,7 +776,7 @@ c^{n+m}}{q}.\)</span>
                             <span class="math">\(y' \neq y,\)</span>
                          all four pieces are randomized.</li>
                     </ul>
-                    <p>Note that the size of each piece is at least 24 bytes.</p>
+                    <p>Note that the size of each piece is at least 20 bytes.</p>
                     <p>It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.</p>
                     <p>The padding contains the HRP so that the HRP has the same protection against malleation as the rest of the address. This may help against cross-network attacks, or attacks that confuse addresses with viewing keys.</p>
                 </section>

zip-0316.rst

@@ -338,6 +338,14 @@ The Human-Readable Parts of Unified Viewing Keys are defined as:
 * *prefix* || “``view``” for Unified Full Viewing Keys on Mainnet;
 * *prefix* || “``viewtest``” for Unified Full Viewing Keys on Testnet.
 
+While support for Revision 1 UAs/UVKs is still being rolled out across
+the Zcash ecosystem, a Producer can maximize interoperability by
+generating a Revision 0 UA/UVK in cases where the conditions on its
+use are met (i.e. there are no MUST-understand Metadata Items, and at
+least one shielded item). At some point when Revision 1 UA/UVKs are
+widely supported, this will be unnecessary and it will be sufficient
+to always produce Revision 1 UA/UVKs.
+
 
 Encoding of Unified Addresses
 -----------------------------
@@ -1098,16 +1106,43 @@ zero bytes, to the raw encoding, then applies :math:`\mathsf{F4Jumble}`
 before encoding the result with Bech32m.
 
 The Consumer rejects any Bech32m-decoded byte sequence that is less than
-48 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it
+40 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it
 applies :math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does
 not end in the expected 16-byte padding, before stripping these 16 bytes
 and parsing the result.
 
-(48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item
-encoding to be 32 bytes, taking into account 16 bytes of padding. Although
-there is currently no shielded Item encoding that short, it is plausible
-that one might be added in future. :math:`\ell^\mathsf{MAX}_M` bytes is
-the largest input/output size supported by :math:`\mathsf{F4Jumble}.`)
+Rationale for length restrictions
+'''''''''''''''''''''''''''''''''
+
+A minimum input length to :math:`\mathsf{F4Jumble}^{-1}` of 40 bytes
+allows for the minimum size of a UA/UVK Item encoding to be 24 bytes
+including the typecode and length, taking into account 16 bytes of padding.
+This allows for a UA containing only a Transparent P2PKH Receiver and any
+Metadata Item:
+
+* Transparent P2PKH Receiver Item:
+
+  * 1-byte typecode
+  * 1-byte encoding of length
+  * 20-byte transparent address hash
+
+* Metadata Item:
+
+  * 1-byte typecode
+  * 1-byte encoding of length
+  * metadata encoding, potentially 0-length for future Metadata Items
+
+:math:`\ell^\mathsf{MAX}_M` bytes is the largest input/output size
+supported by :math:`\mathsf{F4Jumble}.`
+
+Note that Revision 0 of this ZIP specified a minimum input length to
+:math:`\mathsf{F4Jumble}^{-1}` of 48 bytes. Since there were no sets
+of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence
+of length between 40 and 47 bytes inclusive could be parsed, the
+difference between the 40 and 48-byte restrictions is not observable,
+other than potentially affecting which error is reported. A Consumer
+supporting Revision 1 of this specification MAY therefore apply either
+the 48-byte or 40-byte minimum to Revision 0 UA/UVKs.
 
 Heuristic analysis
 ''''''''''''''''''
@@ -1149,7 +1184,7 @@ A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and
 * if :math:`x' \neq x` and :math:`y' \neq y,` all four pieces are
   randomized.
 
-Note that the size of each piece is at least 24 bytes.
+Note that the size of each piece is at least 20 bytes.
 
 It would be possible to make an attack more expensive by making the work
 done by a Producer more expensive. (This wouldn't necessarily have to