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

Tighten up validation requirements. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-04-22 22:10:41 +01:00
parent fbdbead6d5
commit 95f596ea16
2 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
zip-0316.html
View File

@ -186,7 +186,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
(this can also reject if the input is not in the correct range of lengths).</li>
<li>If the result ends in 16 zero bytes, remove them; otherwise reject.</li>
<li>Parse the result as a raw encoding as described above, rejecting any address that does not parse correctly.</li>
<li>Parse the result as a raw encoding as described above, rejecting the entire Unified Address if it does not parse correctly.</li>
</ul>
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id11" class="footnote_reference" href="#bip-0350">8</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
<p>Notes:</p>
@ -200,6 +200,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <a id="id12" class="footnote_reference" href="#zip-0211">5</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
<li>Senders MUST ignore constituent Addresses with Typecodes they do not recognize.</li>
<li>Senders MUST reject Unified Addresses in which the same Typecode appears more than once, or that include both P2SH and P2PKH Transparent Addresses, or that contain only a Transparent Address.</li>
<li>Senders MUST reject Unified Addresses in which <em>any</em> constituent address does not meet the validation requirements of its Receiver Encoding, as specified in the Zcash Protocol Specification <a id="id13" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
<li>Producers SHOULD order the constituent Addresses in the same order as in the Priority List above. However, Senders MUST NOT assume this ordering, and it does not affect which Address should be used by a Sender.</li>
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
<li>A wallet MAY allow its user(s) to configure which Receiver Types it can send to. It MUST NOT allow the user(s) to change the order of the Priority List used to choose the Receiver Type.</li>

9
zip-0316.rst
View File

@ -329,8 +329,8 @@ procedure:
* Apply :math:`\mathsf{F4Jumble}^{-1}` (this can also reject if the input
is not in the correct range of lengths).
* If the result ends in 16 zero bytes, remove them; otherwise reject.
* Parse the result as a raw encoding as described above, rejecting any
address that does not parse correctly.
* Parse the result as a raw encoding as described above, rejecting the
entire Unified Address if it does not parse correctly.
For Unified Addresses on Mainnet, the Human-Readable Part (as defined
in [#bip-0350]_) is “``u``”. For Unified Addresses on Testnet, the
@ -357,6 +357,11 @@ Notes:
appears more than once, or that include both P2SH and P2PKH
Transparent Addresses, or that contain only a Transparent Address.
* Senders MUST reject Unified Addresses in which *any* constituent
address does not meet the validation requirements of its
Receiver Encoding, as specified in the Zcash Protocol Specification
[#protocol-nu5]_.
* Producers SHOULD order the constituent Addresses in the same order
as in the Priority List above. However, Senders MUST NOT assume
this ordering, and it does not affect which Address should be used