diff --git a/zip-0316.html b/zip-0316.html
index 31323f82..e78df9f0 100644
--- a/zip-0316.html
+++ b/zip-0316.html
@@ -174,6 +174,7 @@ Discussions-To: <https://g
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. 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. 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
\(\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
+ The Consumer rejects any Bech32m-decoded byte sequence that is less than 40 bytes or greater than
\(\ell^\mathsf{MAX}_M\)
bytes; otherwise it applies
\(\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.
+ A minimum input length to
+ \(\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:
\(\ell^\mathsf{MAX}_M\)
bytes is the largest input/output size supported by
\(\mathsf{F4Jumble}.\)
- )view
” for Unified Full Viewing Keys on Mainnet;viewtest
” for Unified Full Viewing Keys on Testnet.Encoding of Unified Addresses
Rationale for length restrictions
+
+
+
+
+
+
+
Note that Revision 0 of this ZIP specified a minimum input length to + \(\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.
A 3-round unkeyed Feistel, as shown, is not sufficient:
@@ -751,7 +776,7 @@ c^{n+m}}{q}.\) \(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 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.
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.